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.

September 2, 2026 ·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, a locked keychain, a stale profile. A Mac that starts clean, receives exactly the certificate and profiles it needs, and is deleted afterwards cannot drift. That is how signing works on a NoMac Mac: every session starts with the account's distribution certificate in a keychain, set_up_signing makes and installs the App Store profiles the project needs, and stopping deletes the VM with its keychain. 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 the portal side at all, set_up_signing (CLI: nomac sign) on a NoMac Mac registers the bundle IDs, makes profiles that match the certificate, and returns the build settings and export options to build with. What actually needs a Mac covers the rest of the boundary.

Give your agent a Mac in a minute.