Code signing failures are the most common Fastlane problem. Here is how to diagnose and fix mismatched profiles, missing certificates, and CI keychain issues.
Code signing is a very common source of Fastlane failures, and almost always the root cause is a mismatch. The certificate, provisioning profile, bundle identifier, and export method all have to agree, and if any one is wrong, the build fails.
Typical error messages include "No matching provisioning profiles found," "Code signing is required for product type," or "No signing certificate found." These read as cryptic but nearly always point back to a mismatch or a missing asset.
The good news is that signing errors are deterministic.
Once you identify which piece is wrong, the fix is usually clear. Signing rarely fails randomly, so a methodical check of each component almost always finds the culprit.
The four things that must line up are the certificate, the provisioning profile, the bundle identifier, and the export method. Keep that short checklist in mind as you work through the steps below, because nearly every error maps back to one of them.
Fastlane surfaces the underlying xcodebuild error. Scroll up past the Fastlane summary to find the actual signing message, which names the bundle identifier and the signing type it could not satisfy.
That message tells you exactly what Xcode was looking for. If it says it needs an App Store profile for a specific bundle ID, you know precisely which asset is missing or wrong.
Resist the urge to change random settings.
The real error text almost always names the specific gap, and fixing that gap directly is faster than guessing. Guessing tends to introduce new mismatches on top of the original one.
Running the failing lane with more verbose output can help surface the underlying xcodebuild invocation. Seeing the exact command and its arguments often makes the mismatch obvious at a glance.
A frequent cause is a bundle identifier mismatch between your Xcode target, your provisioning profile, and what you passed to Match or build_app. Even a small discrepancy breaks signing.
Confirm the bundle ID in your Xcode target settings, then confirm the same ID is what Match generated a profile for. If you have multiple targets, such as an app plus an extension, each needs its own matching profile.
Aligning bundle identifiers across the target, the profile, and your Fastlane configuration resolves a large share of signing failures.
App extensions are an especially common trap, since it is easy to forget that each one requires its own dedicated provisioning profile.
If you use Match, run the relevant match command to ensure the correct signing assets are installed on the machine before the build. For a distribution build, that means the appstore type.
On a local machine, check Keychain Access to confirm the signing certificate and its private key are both present. A certificate without its private key cannot sign, and this is a common trap when a certificate was imported incompletely.
If the profile or certificate is genuinely missing, fetching it through Match, or regenerating it if it expired, restores signing.
The missing private key case is worth checking early, because the certificate can appear to be installed while still being unusable for signing.
With Match, you generally should not import certificates by hand at all. Letting Match install the assets avoids exactly the partial-import problems that leave a certificate present but unable to sign.
Mixing signing styles causes trouble. If your project is set to automatic signing but your lane provides an explicit provisioning profile and manual export options, they can conflict.
For CI and Match-based workflows, manual signing is generally more predictable, because you control exactly which profile and certificate are used. Set your export options and build_app configuration to manual and specify the profile Match provides.
Pick one approach consistently.
The most reliable Fastlane setups disable Xcode's automatic signing for release builds and rely on Match-provided assets, which removes the ambiguity about which profile Xcode will choose.
On CI, signing often fails because the certificate is not accessible in the runner's keychain, or the keychain is locked. Ephemeral CI machines start clean, so the certificate must be imported and the keychain unlocked each run.
Match handles importing signing assets, but on some CI setups you also need to create and unlock a temporary keychain and set it as the default. Fastlane provides keychain-related actions to help, and many CI providers document the exact steps.
If your local build signs fine but CI fails, the keychain is a prime suspect.
Confirm the runner actually has the certificate imported and the keychain unlocked before build_app runs. This single check resolves a large share of CI-only signing failures.
Many CI providers publish a reference configuration for macOS signing that handles the temporary keychain setup for you. Starting from their documented example is usually faster than assembling the keychain steps from scratch.
Certificates expire, and someone may have revoked one in the Apple Developer portal. When that happens, every machine using that certificate suddenly fails to sign.
Check the certificate's validity in your Apple Developer account. If it is expired or revoked, regenerate it. With Match, a team member with write access runs the nuke or regenerate flow to replace the assets, then re-pushes them so everyone fetches the new versions.
Be cautious with Match's nuke operation, which revokes and recreates assets for the whole team.
Coordinate it deliberately, since it affects every developer and CI pipeline at once. An unannounced nuke can break every teammate's build simultaneously.
The most effective prevention is standardizing on Match with manual signing for all release builds. This eliminates per-machine drift, which is the underlying cause of most signing surprises.
Use read-only Match access on CI so pipelines cannot accidentally regenerate assets, and set calendar reminders for certificate expiry so renewals happen on your schedule rather than mid-release.
Finally, keep local and CI Fastlane versions in sync via Bundler.
Some signing behavior changes across versions, and version drift can turn a working setup into a failing one. Pinning versions removes that variable entirely.
Taken together, these habits turn signing from a recurring fire drill into a background detail. A team that standardizes on Match, manual signing, read-only CI access, and pinned versions rarely thinks about signing at all, which is exactly the goal.
Usually a mismatch between the bundle identifier, the signing type, and the profiles available on the machine, or a missing profile. Ensure Match has fetched the correct profile for the exact bundle ID and export method.
The most common reason is the CI keychain: the certificate is not imported or the keychain is locked. Ensure Match runs and the runner's keychain is set up and unlocked before build_app.
For CI and Match-based release workflows, manual signing is more predictable because you control exactly which certificate and profile are used. Mixing the two styles is a frequent cause of errors.
Regenerate it in your Apple Developer account or, with Match, have a maintainer regenerate and re-push the assets. Coordinate this, since it affects everyone using those signing assets.