No matching profiles found on Codemagic: what it means, what to check
· 5 min read
iOS code signing is the most asked about Codemagic topic. When we looked through the Stack Overflow tag "codemagic" through the Stack Exchange API on November 5, 2026, it held 233 questions, and most of the top ones were about signing: "Signing for Runner requires a development team", "Runner.app requires a provisioning profile", "APP_STORE_CONNECT_PRIVATE_KEY Provided value is not valid". Codemagic has a help center article on "No matching profiles found" for the same reason. This guide explains what the error means, the causes we see most, and how to check a profile yourself.
What the error means
A provisioning profile ties together four things: an App ID (the bundle id, or a wildcard), a distribution type (App Store, ad hoc, development or enterprise), one or more signing certificates, and for ad hoc and development a list of device UDIDs. Codemagic's ios_signing block asks for a profile of a given type for a given bundle id, and xcode-project use-profiles applies it to the project.
"No matching profiles found" means the search came up empty: no profile matched all of what was asked for. The profile might exist but not match one of those parts.
The usual causes
| Cause | What to check |
|---|---|
| Bundle id does not match | The bundle_identifier in ios_signing against PRODUCT_BUNDLE_IDENTIFIER of the Runner target, per configuration and flavor |
| Wrong distribution type | distribution_type against the profile type; an App Store profile does not match an ad hoc request |
| Certificate not in the profile | The profile lists the certificates it accepts; a new or other certificate does not match an old profile |
| Expired or invalid profile | The profile's expiry date; a profile also turns invalid when its certificate is revoked |
| Extension without a profile | Widgets, share and notification extensions each have their own bundle id and need their own profile |
| Flavors | A flavor with a suffix such as .dev is a different bundle id |
| API key access | The App Store Connect API key must have a role that can read and make profiles and certificates |
A check order that finds most of them
- Read the full log line. It usually names the bundle id and the type it looked for. Compare it with what you expected.
- Check the bundle id in Xcode. Open
ios/Runner.xcodeproj, select each target, and read the bundle identifier for the Release configuration. Flutter flavors often change it. - Look at the profiles in your Apple account. In Certificates, Identifiers and Profiles, filter by the bundle id and see which types exist and whether they are active.
- Download the profile and read it. A .mobileprovision is a signed property list. The free provisioning profile inspector reads it in your browser, without uploading it, and shows type, App ID and wildcard, team, certificates with expiry and SHA-1, entitlements, UDIDs with search, and the expiry date.
- Check the certificate. Compare the certificate SHA-1 in the profile with the certificate Codemagic uses. If you let Codemagic make certificates and also make them in Xcode, you can end up with several, and a profile only accepts the ones it lists.
- Run again with the fix. If the profile is wrong, let Codemagic make a new one or make it on Apple, then run the workflow.
When the build works but the iPhone will not install
A different problem with a similar root: the .ipa built and signed, but a tester's iPhone refuses it. Drop the .mobileprovision and the .ipa into the inspector together. It lists why a device would refuse the install: the profile expired, the build is App Store signed, the UDID is not in the profile, the bundle id is not covered, the app asks for entitlements the profile does not grant, or a wildcard App ID is used with push or associated domains. The inspector reads and explains; it does not fix, sign or re-sign anything.
The common case is the UDID. A tester's device was registered after the profile was made, so the build does not include it. Register the device, get a new profile, build again. Our guide to Codemagic iOS ad hoc builds for Flutter covers that flow.
Other signing errors that look related
"Signing for Runner requires a development team"
Xcode has no team set for the target. On Codemagic this usually means use-profiles did not run or did not match, so the project fell back to its own settings. Fix the profile match first.
"Runner.app requires a provisioning profile"
The export step did not find a profile for the app. With Flutter on Codemagic, check that you export with --export-options-plist=/Users/builder/export_options.plist and not with --export-method, which skips the file Codemagic wrote.
"Provided value is not valid" for the private key
The App Store Connect API key content is not in the format the tool expects. Paste the full .p8 file content, including the BEGIN and END lines, and check that no line breaks were lost.
Prevent it next time
- Keep one source of certificates. Either Codemagic makes and keeps them, or you upload yours; mixing both creates profiles that accept only some certificates.
- Write down every bundle id the app ships, including extensions and flavors.
- Check profile expiry before a release week. Profiles last up to a year.
- Read the profile of each test build before you send it. The IPA inspector shows the embedded profile, type and UDIDs.
If you share test builds through AppForShare, the store readiness check on each uploaded build also flags an expiring profile. More general causes are in iOS code signing errors on test builds.
Common questions
Does the inspector upload my profile?
No. It reads the file in your browser and nothing is sent to a server.
Can AppForShare sign my build?
No. AppForShare does not sign or re-sign .ipa files. Codemagic or Xcode signs; AppForShare shares the signed build. With an App Store Connect connection on Pro and Team, an Admin can register devices and remake an ad hoc profile on Apple, and you still build again.
Is this a Codemagic bug?
Usually not. The same mismatch fails in Xcode on a Mac. Codemagic only makes it visible earlier.
Once the build signs, the next step is getting it to testers. Share a Codemagic build with testers shows a publishing script, and a free account lets you upload a test build and check it.
