Code signing can be confusing even when it is working correctly, but what if things go wrong? Locally you may be able to resolve issues in a few clicks, but debugging code signing on CircleCI can sometimes be challenging.
This guide walks through some of the common issues that can occur and how you can resolve them. If you work through this guide and find you are still struggling, please feel free to reach out to support (paid customers) or start a new thread right here in Discuss!
Please note: At CircleCI we only offer support for Fastlane Match! Other code signing methods are available, but your mileage may vary and we cannot guarantee assistance for these.
The Red Herring Warning
In almost all iOS lanes, you will see the following type of output when calling match:
[14:28:38]: Cloning remote git repo... [14:28:38]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match. [14:28:38]: 🔓 Successfully decrypted certificates repo [14:28:38]: Installing certificate... security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain. [14:28:39]: There are no local code signing identities found. You can run `security find-identity -v -p codesigning fastlane_tmp_keychain` to get this output. This Stack Overflow thread has more information: https://stackoverflow.com/q/35390072/774. (Check in Keychain Access for an expired WWDR certificate: https://stackoverflow.com/a/35409835/774 has more info.)
Usually this is highlighted in red… but don’t worry! This output occurs even in successful jobs. You will likely not see the same output locally as it is being caused by the keychain being empty initially (which is expected behaviour in a CI environment).
Even if your build is failing, do not read too much into this error to start with. When debugging Fastlane issues it is always best to debug backwards - from the last error message back to the first!
“Too long with no output”
In a headless CI environment, we must configure not only the projects, but also the environment itself, to behave correctly without human intervention. This is especially true with various parts of macOS which may not be very command line friendly!
Even though we are calling Fastlane, and by proxy Xcodebuild, from the command line, if there are any keychain access issues, macOS will show a password prompt in the UI - not very helpful for our needs As this UI pop-up halts execution while waiting for input, the job on CircleCI will eventually time out as it cannot proceed.
These kind of issues usually appear near the end of the compilation of the app.
With this in mind, it is important that the keychain is configured correctly before every lane. This can be done by adding the following to the top of your Fastfile:
# fastlane/Fastfile ... platform :ios do before_all do setup_circle_ci end ... end ...
If your build continues to hang then timeout even after adding this, it may be running out of memory. Please reach out to support for further assistance.
“No profile for team”
Another common issue is as follows:
❌ error: No profile for team '31U82WUKS4' matching 'match AppStore com.circleci.HelloCircle' found: Xcode couldn't find any provisioning profiles matching '31U82WUKS4/match AppStore com.circleci.HelloCircle'. Install the profile (by dragging and dropping it onto Xcode's dock item) or select a different one in the Signing & Capabilities tab of the target editor. (in target 'HelloCircle' from project 'HelloCircle') ** ARCHIVE FAILED ** Exit status: 65
This error message generally isn’t very helpful and can seem daunting at first, but it is actually fairly simple to resolve!
To check this out, you will need to open your Xcode project locally.
Firstly, make a note of the profile mentioned in the error message. Using the example error message above we can see the profile is
match AppStore com.circleci.HelloCircle. With this, we can see this is a release configuration (AppStore and Adhoc are both release configurations).
With this in mind, head over to the code signing settings of your target in Xcode. It should look something like this if configured correctly:
The main areas to note are:
- “Automatically manage signing” is unchecked - The build will not work with automatic code signing due to the way the keychain is configured
- The provisioning profile is manually set to
match AppStore my.bundle.id- This should be set to the appropriate “match” profile depending on the type of build (
match Developmentfor debug and
Match Adhocfor release)
If all else fails…
If you are going round in circles () with codesigning errors, it could be that your certificates and profiles are the problem. In this case it is easier to:
The match nuke command revokes all certificates and profiles for the specified environment. For example,
match nuke distribution will revoke all certs and profiles used for AppStore and Adhoc builds.
Note: Apps that are already live in the App Store willbe unaffected, but any Adhoc releases (such as those distributed by a service like VS App Center) will be unable to launch, so the customer will need to push a fresh build out.
Once you have run the nuke command, you will need to run fastlane match again to generate new certificates and profiles. E.g.,
fastlane match appstore
After this, ensure the correct profile is selected as per the previous section of this guide.