In this article
For an iOS CI signing failure, compare the signing identity, application identity, profile and export configuration before regenerating credentials. A certificate visible on a developer's Mac does not establish that the CI runner has the private key or that the chosen profile permits the intended app.
Apple's TN3125 provisioning-profile explanation describes how profiles connect signing authorization, app identity, permitted execution and entitlements. Checked October 8, 2026; profile internals are diagnostic evidence, not a stable API to build your own signing system around.
Locate the first failing operation#
Separate compile, archive signing, export and upload validation. Preserve the first actionable error and the selected scheme/configuration. A later generic “archive failed” line often hides the earlier identity mismatch.
If compilation fails, investigate the compiler or dependency error. Signing changes will not repair a missing Swift symbol. If archiving succeeds but export fails, compare export inputs with the archive rather than immediately replacing the archive's certificate.
Check whether the runner has a usable identity#
On the authorized runner, a read-only inventory can start with:
security find-identity -v -p codesigningUse an internal log and redact identifying details before sharing it publicly. Inspect the expected keychain and import result through your established signing setup. A certificate without its matching private key is not equivalent to a usable signing identity.
If the keychain cannot be accessed non-interactively, investigate that specific setup step. Do not disable broad security protections or expose a password in a command-line transcript as a workaround.
Match the app and profile#
Compare the expected bundle identifier and team with the resolved Archive configuration. Then inspect the selected profile's app identity, signing authorization, validity and relevant capabilities using Apple's supported diagnostic guidance.
A main app and an extension can need separate profiles. An error naming an extension should be traced to that target, not fixed by modifying only the main app's profile.
Keep an internal mismatch record:
Failing target:
Resolved bundle ID/team:
Selected signing identity:
Selected profile:
Expected distribution method:
Observed mismatch:
Smallest corrective change:Do not assume that similarly named profiles are interchangeable. Verify the actual file or resolved profile selected in the failing run.
Compare archive and export settings#
Confirm the export method is the one your release process intends and that profile mappings cover the archived targets. Manual and automatic signing paths have different configuration responsibilities; use the path your project actually supports.
If the wrong scheme supplied the wrong bundle ID, fix that mapping before rotating credentials. If a profile lacks a required capability, correct the authorized profile configuration instead of silently removing the capability from the app.
Validate without causing a second incident#
Apply the smallest correction and repeat the failing operation using an authorized test workflow. Record the archive identity and the next result. Retain the old configuration until you have verified the replacement and understand which other workflows depend on it.
Avoid revoking shared certificates merely to see whether a build changes; other apps or pipelines may depend on them. Apple's code-signing resources provide further official diagnostic paths.
A generated patch should explain which mismatch it resolves. Use our AI code review guide when a suggested fix changes unrelated entitlements, bundle identifiers or security settings.