Resolve 'no profile matching' and capability-mismatch provisioning profile failures in Codemagic iOS builds with a clear, cause-by-cause troubleshooting guide.
This failure appears when Codemagic reaches the archive or export step and cannot find or apply a provisioning profile that satisfies your app. Typical log messages include 'No profile matching bundle identifier was found', 'Provisioning profile doesn't include the entitlement', 'requires a provisioning profile with the capability', or 'doesn't support the capability'. Compilation itself usually succeeds, which is why this is confusing — the code is fine, but the identity Apple demands to package and distribute it is not correctly assembled. A provisioning profile ties together three things: your app's App ID (bundle identifier), a signing certificate, and a set of entitlements corresponding to enabled capabilities. When any of these does not line up with what your app declares, Apple's tooling refuses to produce a distributable archive. On a local Mac, Xcode's automatic signing hides much of this by silently registering and regenerating profiles as you toggle capabilities. In the cloud there is no interactive session to do that quietly, so mismatches that never surfaced locally suddenly break the build. Start by reading the exact message to learn whether the problem is a missing profile or a capability mismatch. The distinction matters because a missing profile points you toward App ID registration and distribution type, while a capability error points you toward entitlements and the portal's capability toggles.
The most direct cause of 'no profile matching' is that no provisioning profile exists for the exact bundle identifier your build is signing, of the distribution type it needs. With automatic signing via an App Store Connect API key, Codemagic tries to fetch or create such a profile, but it can only do so if the App ID is registered in the Apple Developer portal. If the App ID does not exist, or your workflow references a slightly different identifier than the one registered — a common problem with per-environment identifiers like com.example.app versus com.example.app.staging — no match can be found. Fix this by confirming the exact Product Bundle Identifier of the target and build configuration used in CI, verifying that identifier is registered as an App ID in the developer portal, and ensuring your Codemagic configuration references the same string. For App Store and TestFlight builds, also confirm the distribution type in your workflow is app_store, because a request for the wrong type will not match an App Store profile. When the identifier and type both align with a registered App ID, automatic signing can locate or create the profile. If you use an explicit wildcard App ID rather than an explicit one, be aware that some capabilities cannot be used with wildcards, which can force you to register an explicit App ID for the exact identifier instead.
Capability mismatches are the second major cause and produce errors stating the profile lacks a required entitlement or does not support a capability. Every capability your app uses — Push Notifications, App Groups, iCloud, Sign in with Apple, HealthKit, associated domains, and others — must be enabled on the App ID in the Apple Developer portal so that generated profiles include the corresponding entitlement. The classic trap is enabling a capability in Xcode's Signing and Capabilities tab, which works locally because automatic signing registers it against your session, then pushing to Codemagic where the clean build finds the App ID lacks that capability and fails. To fix it, sign in to the developer portal, open the App ID for your bundle identifier under Identifiers, and enable exactly the capabilities your app requires. Some capabilities need additional configuration, such as an App Group identifier or an iCloud container, which must also be created and associated. After updating the App ID, regenerate the profile or let Codemagic recreate it so the new entitlements are included, and confirm your entitlements file matches what you enabled. Keep in mind that a few capabilities, like associated domains or certain background modes, also require server-side or Info.plist configuration to actually function, even though the signing side only needs the App ID entitlement to pass.
Even when the App ID has the right capabilities, a mismatch between your app's entitlements file and the profile causes failures. The entitlements file declares what your app claims to use; the provisioning profile grants what Apple has authorized. If your entitlements file requests an entitlement the profile does not carry, the export fails validation. This often happens after someone edits capabilities directly in the .entitlements file, or when a capability is removed from the App ID but still declared in the app, or vice versa. To resolve it, open your target's entitlements file and compare each key against the capabilities enabled on the App ID in the developer portal. They must correspond: an aps-environment entitlement requires Push Notifications on the App ID, an application-groups entitlement requires registered App Groups, and so on. Remove entitlements your app no longer uses and add App ID capabilities for entitlements you genuinely need. Keeping the entitlements file, the Xcode Signing and Capabilities configuration, and the portal App ID in strict agreement is the durable fix; correcting only one of the three tends to relocate the error rather than eliminate it. Be especially careful with the aps-environment value, which should be production for App Store and TestFlight distribution builds, as a development value here can cause validation to reject an otherwise correct archive.
iOS apps that ship extensions — widgets, notification service extensions, share extensions, Siri intents, or a paired watchOS app — have multiple targets, each with its own bundle identifier and each requiring its own provisioning profile. A build can fail on provisioning even when the main app is perfectly configured, simply because an extension's identifier is not registered or its profile is missing or lacks a needed capability. The error may name the extension's bundle identifier, which is a strong clue. To fix it, enumerate every target in your project that ships inside the archive, note each bundle identifier, and confirm each has a registered App ID with the correct capabilities and an available distribution profile. App Groups are a frequent source of trouble here, because the main app and its extension usually share an App Group that must be registered and enabled on both App IDs with an identical group identifier. With automatic signing, Codemagic can generate profiles for each target given properly registered App IDs, but it cannot invent App IDs that do not exist. Handle every embedded target, not just the primary app. A watchOS companion app is especially easy to overlook because it may itself contain a watch extension, meaning a single product can require three or more coordinated App IDs and profiles.
If you use manual signing and upload your own provisioning profiles to Codemagic, a stale profile is a common cause of sudden failures. Provisioning profiles become invalid when the underlying certificate expires, when you add or remove registered devices for development or ad hoc distribution, or when you change the capabilities on the App ID. The uploaded profile in Codemagic does not update itself; it remains whatever you last provided, so a change made in the portal silently invalidates it and every build fails until you refresh it. Fix this by regenerating the affected profile in the Apple Developer portal so it reflects the current certificate and capabilities, downloading it, and re-uploading it to Codemagic to replace the outdated asset. This is one of the reasons many teams prefer automatic signing with an API key, where Codemagic keeps the profile current instead of relying on you to remember. If you must use manual profiles, document their expiration dates and set a reminder to renew them before a release, so an expired profile does not block you at the worst possible moment. It also helps to name uploaded profiles clearly with their target and type so that, months later, whoever refreshes them can tell at a glance which asset corresponds to which App ID.
After applying a fix, re-run the build and read the signing and export log lines closely. You should see Codemagic resolve a provisioning profile for each target, install it, and archive without a profile error. If it still fails, confirm you changed the right thing by re-checking the exact bundle identifier in the failing message against your portal registration. To prevent recurrence, prefer automatic signing with an App Store Connect API key so profiles stay current, pin the distribution type explicitly to app_store for App Store and TestFlight builds, and keep a single source of truth for capabilities. Treat the developer portal App ID, the Xcode Signing and Capabilities tab, and the entitlements file as three views of one configuration that must always agree, and update all three together whenever you add a capability. For multi-target apps, maintain a short checklist of every bundle identifier and its required capabilities so nothing is forgotten when you onboard a new extension. These habits turn provisioning failures from recurring surprises into a rare, quickly diagnosed event on your Codemagic pipeline. A brief note in your repository documenting the app's identifiers, capabilities, and signing approach pays for itself the first time a new teammate has to touch the release pipeline.
No provisioning profile exists for the exact bundle identifier and distribution type your build is signing. Either the App ID is not registered in the developer portal, the identifier in Codemagic differs from the registered one, or the requested distribution type does not match an available profile.
Enabling a capability in Xcode's Signing and Capabilities tab works locally because automatic signing registers it against your session. A clean cloud build needs that capability enabled on the App ID in the Apple Developer portal so generated profiles include the entitlement.
Yes. Each extension or embedded target has its own bundle identifier and needs its own registered App ID and provisioning profile with matching capabilities. A missing extension profile fails the whole archive even when the main app is configured correctly.
Uploaded manual profiles do not update themselves. They become invalid when the certificate expires, devices change, or App ID capabilities change. Regenerate the profile in the developer portal and re-upload it to Codemagic. Automatic signing avoids this by keeping profiles current.
Treat the developer portal App ID, the Xcode Signing and Capabilities tab, and the entitlements file as three views of one configuration that must always agree. Whenever you add or remove a capability, update all three together to prevent mismatch errors.