Provisioning profile errors in Xcode, and how to fix them

Short answer: a provisioning profile ties together an App ID, the certificates allowed to sign, the entitlements and, for development and Ad Hoc builds, the devices. Almost every profile error means one of those four no longer matches your build. Find which one, regenerate the profile, and sign again.

Profiles are the part of iOS signing people touch least often and understand least — until a build refuses to sign the night before a demo. If you need the basics first, read iOS code signing, explained. Below: the errors themselves.

First, look inside the profile

Guessing is slower than reading. A .mobileprovision file is a signed property list, and macOS can decode it^[1]:

security cms -D -i Profile.mobileprovision -o payload.plist
plutil -extract ExpirationDate raw -o - payload.plist
plutil -extract ProvisionedDevices xml1 -o - payload.plist
plutil -extract Entitlements xml1 -o - payload.plist

To see what the built app actually claims: codesign --display --entitlements - --xml App.app. Most errors below become obvious once you compare these outputs.

“Provisioning profile … doesn’t include signing certificate …”

What it checks: the certificate Xcode is trying to sign with isn’t in the profile’s list of allowed certificates^[1].

Common causes: a certificate was renewed or recreated after the profile was generated; the profile is a distribution profile but you selected a development certificate (or the reverse); the private key for the certificate isn’t on this Mac; an expired duplicate in Keychain is picked instead of the current one.

Fix:

1. In Keychain Access, remove expired or duplicate signing certificates and make sure the current one has its private key.
2. In your Apple Developer account, edit the profile, select the current certificate and generate it again.
3. Download the new profile (or let automatic signing fetch it) and build again.

“Provisioning profile … doesn’t include the currently selected device …”

What it checks: the device you are running on isn’t in the profile’s device list.

Fix: with automatic signing, click Register Device under Signing — Xcode registers the device and adds it to the profile^[3]. With manual profiles, register the UDID under Devices in your developer account, then edit the profile, tick the new device and generate it again. Adding a device doesn’t update existing profiles by itself.

Remember the budget: 100 devices per device type per membership year, and removed devices don’t free their slot until renewal^[4].

“… doesn’t match the entitlements file’s value for the … entitlement”

Also seen as “doesn’t support the Push Notifications capability” or “doesn’t include the aps-environment entitlement”.

What it checks: every entitlement your app claims must be allowed by its profile^[1]. You added a capability in Xcode — push notifications, app groups, associated domains, network extensions — but the App ID or the profile predates it.

Fix: enable the capability on the App ID in your developer account, regenerate the profile (Apple’s docs say to regenerate when a profile became invalid after enabling app services^[5]), and compare the profile’s Entitlements with your target’s entitlements file. In multi-target apps, check each extension separately — each has its own profile.

“No profiles for ‘com.example.app’ were found”

Full text usually reads “Xcode couldn’t find any iOS App Development provisioning profiles matching …”, and on CI often adds “Automatic signing is disabled and unable to generate a profile. To enable automatic signing, pass -allowProvisioningUpdates to xcodebuild.”

Fix: locally, sign in to your developer Apple Account in Xcode settings, select the right team and let automatic signing create the profile. On CI, either pass -allowProvisioningUpdates with valid credentials, or install a manually created profile whose bundle ID matches exactly.

“Your team has no devices from which to generate a provisioning profile”

Development and Ad Hoc profiles need at least one registered device^[6]. Connect and pair a device, or add a UDID manually under Devices in Certificates, Identifiers & Profiles.

“Failed to register bundle identifier”

The message continues: “The app identifier … cannot be registered to your development team because it is not available.” The bundle ID already belongs to another team — often your company’s team while you’re signed in with a personal one. Switch to the team that owns the App ID, or choose a unique bundle ID^[7].

Expired or invalid profiles

Every profile has an expiration date, typically no more than a year; signing certificates are typically valid for a year too^[1][8]. Profiles are also marked invalid when a certificate they include is revoked or an App ID changes.

Fix: in Profiles, select the profile, click Edit, generate it again, then re-sign the app and reinstall it on devices^[5]. Builds already installed with the old profile will stop launching once it expires — plan renewals before a long test cycle, not during it.

On the device side, the same problems show up as “Unable to Install” or “integrity could not be verified” — see how to install an IPA file on iPhone for what testers see.

Automatic or manual signing?

What AppSign takes off your plate — and what stays with you

These errors multiply with every tester and every build. AppSign takes over the cryptographic side of distribution: signing each new build of each app for every registered tester, so profiles and device lists stop being something your team edits by hand.

Some steps stay with you, because Apple requires them from the account owner:

• Enroll in the Apple Developer Program yourself.
• Create your certificate and upload it to AppSign.
• Create an App Store Connect API key so AppSign can work with your account faster.
• Enable capabilities your app needs — push notifications, app groups and so on — on the App ID.
• Collect UDIDs from testers — our UDID guide is written for them.

Once that’s in place, new testers and new builds don’t mean new profile errors.