iOS code signing errors, decoded
"No profiles for X were found", certificate/profile mismatches, expired everything. What each error actually means, in the order they happen, and the fix for each.
· 8 min read
iOS code signing has a reputation for being cryptic, and it is earned — but the surface is smaller than it looks. Four objects have to agree: a certificate, a private key, a provisioning profile, and a bundle identifier. Almost every error is two of them disagreeing, and the message names the symptom rather than the disagreement.
Here they are in the order you meet them, with what each one actually means.
“No profiles for ‘com.example.app’ were found”
Xcode looked for a provisioning profile matching that exact bundle ID and found none. In order of likelihood:
- ·The bundle ID does not match.It is case-sensitive, and a trailing character from a copy-paste counts. Compare the target's value against the identifier in the developer portal character by character.
- ·No profile exists yet. Common on a first build: the app record exists, the identifier exists, nobody generated a profile.
- ·The profile exists but not on this machine. Local Xcode downloads profiles for you; a CI runner does not. Nothing is wrong with your account — the file is simply not there.
“Provisioning profile doesn't include signing certificate”
A profile contains a list of certificates allowed to use it. Yours is not on the list. This is the classic result of regenerating a certificate and not regenerating the profiles built on it — the profile still references the certificate you replaced.
Regenerate the profile after any certificate change. If you use automatic signing locally and manual signing in CI, expect this one regularly, because the two paths create different certificates.
“Provisioning profile doesn't include the currently selected device”
You are building with a development or ad hoc profile, which enumerate specific device UDIDs, and this device is not in the list. Add it to the portal and regenerate.
If you are trying to ship, this error is a signal you are on the wrong profile type entirely: App Store distribution profiles have no device list, because the App Store is not a device. That is the profile a release build wants.
“Code signing is required for product type Application”
The build produced something that must be signed and no identity was configured at all — typically an unattended build where signing settings were never set, or a Team ID that is empty. Check that the target has a development team and that the CI environment actually has the certificate imported into a keychain it can read.
“errSecInternalComponent”
The most opaque message in the set, and almost always the same cause on CI: the keychain holding your private key is locked, or the codesign process has no access to it. On a headless machine there is no one to type the keychain password, so the build inherits a locked keychain and fails in a way that mentions none of that.
security create-keychain -p "$PASS" build.keychain security default-keychain -s build.keychain security unlock-keychain -p "$PASS" build.keychain security set-keychain-settings -lut 21600 build.keychain # don't relock mid-build
Expired anything
- ·Certificates last one to three years depending on type.
- ·Provisioning profiles last one year, and expire independently of the certificate inside them.
- ·Apple's intermediate certificates expire too, and when the WWDR certificate rolls over, machines with the old one fail in ways that look like your problem and are not.
The expiry failure has a signature: a build that worked on Friday fails on Monday with no change to the code. Check dates before you debug anything else.
The CI-specific ones
It works locally and fails on the runner
Your Mac has years of accumulated state — certificates in the login keychain, profiles Xcode quietly downloaded, an Apple ID already signed in. A fresh runner has none of that. The build is not different; the environment is.
Automatic signing on a machine with no account
Automatic signing works by asking Apple for what it needs, which requires an authenticated session. On CI, either provide an App Store Connect API key so the tooling can authenticate, or switch to manual signing and supply the profile explicitly. The half-way state — automatic signing, no credentials — produces the least informative errors of all.
The structural fix. Every one of these is a state problem: the wrong certificate on the machine, an unlocked keychain, a stale profile. A build that starts from a fresh VM, fetches exactly the certificate and profile it needs, builds, and then destroys the machine cannot drift — there is no state to drift. That is how NoMac runs builds: one ephemeral macOS VM per build, keychain and secrets destroyed with it. The class of error above mostly stops existing rather than getting handled.
A debugging order that works
- ·Read the bundle ID in the error and compare it to the portal, character by character.
- ·Check expiry dates on the certificate and the profile.
- ·Confirm the profile type matches the job: development, ad hoc, or App Store.
- ·Confirm the certificate is listed inside that profile.
- ·On CI, confirm the keychain is created, unlocked, and set not to relock.
- ·Only then start changing build settings.
If you would rather not own this at all, what actually needs a Mac covers what a managed pipeline takes over — signing being the first thing.