Please note that currently only Git repositories are supported. Any third party version control repositories need to be transferred to a proper Git repository on either Github or Bitbucket.
You will need to go to your Github, Bitbucket or GitLab account and revoke access to Appcircle and then reconnect your account from Appcircle.
Please check if you have owner/admin access in the specific organization from which the repositories will be connected. Appcircle does not allow connections to the repositories with a member-level access.
AWS CodeCommit requires the creation of a dedicated user for repository connections through SSH (i.e. the root user cannot be used for this purpose).
Please refer to this guide for creating a user for SSH connections.
First, create a user in AWS IAM and assign the following permissions to the user:
Go to IAM -> Users -> User -> Security credentials and select "Upload SSH key".
Take a note of the SSH key ID generated by AWS as follows:
Once you login with the newly generated user and copy the repository URL in SSH format, you will receive URL as follows:
For the SSH connection to be initialized, you need to add the public key to your URL to have it in the following format, which then can be entered in Appcircle to be used in SSH connections.
For the SSH connections, a key pair in PEM format is required. The public key is entered/stored in the Git provider while the private key is entered in Appcircle.
Please refer to this guide for the commands to generate a compatible key pair for SSH connections.
The only available option for connecting to the internal/on-premise repositories is to use SSH and whitelist Appcircle resources if the repositories are not accessible from the public internet.
Please refer to this guide for connecting to the repositories in internal networks.
There may be a bunch of reasons for a build to fail.
Best way to learn the reason is to check the build logs. See Working With Build Logs section for details on this.
Build logs will display everything happened in each workflow step in details and let you examine what went wrong during the build.
If you are unable to determine the exact cause, feel free to get in touch with Appcircle using the in-app messaging for additional support.
Most build failures are related with the following build steps. If you encounter any errors, please remove or edit the following steps and get a build to help isolate the cause of the issue.
iOS Sign Errors: If the selected provisioning profile does not match with the selected bundle ID or if the certificate is not valid, you may have an issue in the iOS signing step. In this case, you may try getting an unsigned build
Xcode Build for Simulator step: This step is required to use the Preview on Device feature and it requires the app to be built for the x86 architecture. In some projects, there may be dependencies that are not compatible with x86. In this case, please remove this step from the workflow or remove the conflicting dependencies to get a successful build.
Android Sign Errors: If you encounter errors while signing your Android app, you can remove this step to get an unsigned build or you can configure the app signing within your project.
With every build, a brand new virtual machine is started to perform your workflow and build your application.
Some applications may have 3rd party dependencies which need to be installed before the build is performed. With every new build, these dependencies need to be re-installed.
One way to speed up the build time may be to manage your dependencies in your project. This will speed up your builds significantly if your application has excess amount of dependencies to be installed.
If you still think that your build is taking significantly longer than it should, please feel free to get in touch with Appcircle for additional support.
Your iOS application project needs to have a shared scheme in order to be built outside Xcode. Xcode doesn't share schemes by default so you will have to do it manually.
On Xcode, select Product > Scheme > Manage Schemes
Select Shared for your
Scheme container needs to be set to the corresponding Xcode project or workspace
Please do not forget to add your
.xcscheme file to version control so it will be uploaded to your Git repository
For details on iOS builds please refer to Building iOS Applications
If you receive a pod error similar to the following, this usually indicates that although pods are used, the build is done with an xcodeproj file:
error: .../_appcircle_temp/Repository/Obj-C/Pods/Target Support Files/Pods-AEPSampleAppObjC/Pods-AEPSampleAppObjC.release.xcconfig: unable to open file (in target "AEPSampleAppObjC" in project "AEPSampleAppObjC") (in target 'AEPSampleAppObjC' from project 'AEPSampleAppObjC')
If a pod is used, the xcodeworkspace must be pushed to the repository and it must be selected in the build configuration for a successful build.
If you receive a provisioning profile error similar to the following, it usually indicates a mismatch between the bundle ID selected in the build configuration and the provisioning profile.
error: "MyProject" requires a provisioning profile. Select a provisioning profile in the Signing & Capabilities editor. (in target MyProject from project MyProject)
In such an error, please check if the correct bundle ID is selected for the build. This is especially the case if you are using different bundle IDs for different release types such as debug or release.
If you receive an error similar to the following, the selected Xcode version in the build configuration may be incompatible with the selected Swift version in the project settings.
SWIFT_VERSION '3.0' is unsupported, supported versions are: ...
In this case, you need to upgrade the Swift version in the project settings in Xcode and once the build is confirmed to be working locally in the specific Xcode version, it can be retried in Appcircle with the same Xcode version.
Then, you can add a custom script step before the Android build step and move the file to the expected path during the build with a code like the following (where the secret environment variable is named as
cd $AC_REPOSITORY_DIR/mv $GOOGLE_SERVICES_JSON $AC_REPOSITORY_DIR/app
You may want to build unsigned Android applications. Most common mistake done with this is Appcircle users usually forget to disable Sign Application step in the workflow.
If you do not select a keystore in the build configuration, you need to disable the Sign Application step or your build will fail.
You may get this error message when the provided password doesn't match the keystore file.
If you are using a debug keystore, simply re-generate it. Otherwise, please make sure you have the correct keystore/password combination.
A successful distribution depends on a correctly signed binary. Please check if the signing configuration is correct.
You can also check the list of the generated build artifacts to confirm the output. In Android, you can also check the
ac_post_process_output.json file in the build artifacts to see if the APKs are signed or not.
In Android, please also check if gradle sign is being used for the selected build variant. If gradle sign works alongside with Appcircle signing, you will receive multiple APKs.