How to Fix "No Signing Certificate Found" and Provisioning Errors in Xcode

Your app runs in the Simulator. Then you pick a real iPhone, or choose Product > Archive, and Xcode stops with No signing certificate "iOS Distribution" found or a red block under Signing & Capabilities. If the app came out of Cursor, Claude Code, Rork, Bolt or Expo, this may be the first time you have looked at that tab at all.

Signing errors look random because Xcode reports the symptom. The cause is almost always one missing link between your account, your Mac and your project, and each link can be checked on its own. This guide starts with what signing needs, then goes through the common errors one at a time, with the exact place to look for each. The Simulator doesn't need your team's certificates or a registered device, which is why the app could look finished before any of this came up.

What Xcode needs before it can sign

Apple's technote TN3125 says a provisioning profile ties together five questions. Every error in this article is a failed answer to one of them.

Question	What answers it	Typical failure
Who can sign?	Certificates listed in the profile	Your certificate isn't in the profile, or isn't on this Mac
Which app?	App ID: team prefix plus bundle ID	Bundle ID belongs to another team
Where can it run?	Registered devices	No devices on the team
Until when?	Expiration date	Profile or certificate expired
With what permissions?	Entitlements allowed by the profile	App claims a capability the profile lacks

There is one more piece that causes a lot of confusion. A certificate only holds a public key, so it can't sign anything alone. TN3161 explains that you need the certificate plus its matching private key, a pair Apple calls a code-signing identity. Xcode says "signing certificate" when it means this pair. When Xcode creates a certificate for you, the private key goes into the login keychain of that Mac, and it does not follow you to a new machine.

Match your error to a section

What you see	Likely cause	Go to
`No signing certificate "iOS Development" found` or the "iOS Distribution" version	No usable identity for that build type	Step 2
You have a certificate but signing still fails on this Mac	Private key is on another Mac	Step 3
`Failed to register bundle identifier`	Bundle ID is taken	Step 4
`Your team has no devices from which to generate a provisioning profile`	No registered device	Step 5
A profile "doesn't include" a certificate or an entitlement	Profile is older than your project's needs	Step 6
`errSecInternalComponent`	Certificate isn't trusted on this Mac	Step 7

Step 1: Check the account before touching the project

Do this first, even if the error seems to be about something else. It's quick and rules out problems that no project setting can fix.

Open Xcode > Settings, click Accounts in the toolbar, and confirm your Apple Account is listed with the right team. If a sign-in error appears, sign in again. An Apple engineer on the forums notes that this session expires, so you may need to re-authenticate from time to time.
Log in at developer.apple.com and look for pending agreements. The same engineer's first suggestion for automatic signing failures was to confirm the account has none.
Check that you hold a paid Apple Developer Program membership. Without one, Xcode creates a personal team, which is enough to try the app on your own device but can't upload to App Store Connect.
Check your role if the account belongs to a company or a client. Apple's certificates overview says distribution certificates belong to the team and only the Account Holder or an Admin can create them. If you are a plain team member, that alone can block you.

Step 2: Fix "No signing certificate found"

Read the quoted name in the error, because it tells you which build type failed. "iOS Development" means running on a device. "iOS Distribution" means archiving or exporting for TestFlight and the App Store.

Start by seeing what this Mac has. Run this in Terminal:

security find-identity -p codesigning

The output has two lists. Anything under "Valid identities only" is usable. An entry marked CSSMERR_TP_CERT_EXPIRED has expired. If there is no Apple Development line at all, this Mac has no development identity.

For most solo founders, the fix is to let Xcode own the whole thing:

Select the project in the navigator, then the app target, then Signing & Capabilities.
Turn on Automatically manage signing.
Choose your Team, and confirm the Bundle Identifier is the one you want to ship.
Build to a connected iPhone. Apple says the first run on a device makes Xcode create the development assets and register the device.

To create a certificate by hand, Apple's steps are: Xcode > Settings, Accounts, select your account and team, click Manage Certificates, click the Add button (+) in the lower-left corner, choose the type, then click Done.

Distribution builds and cloud signing

You often don't need a local distribution certificate at all. Apple's page on cloud-managed certificates says that in Xcode 13 or later, Xcode signs in the cloud when you use the Organizer archive and distribution flow, and it does this only when no local signing certificate is found. App Store Connect has additional permissions that let Admins and Developers use them.

If archiving fails with a message that you haven't been given access to cloud-managed distribution certificates, ask the Account Holder or an Admin to grant it. One forum poster already held the Admin role and still got a 403 with ResultCode 7495. Apple Developer Technical Support traced that case to a permission problem on Apple's side, so if your role is correct, send them your IDEDistributionProvisioning logs and Organizer screenshots.

The same error from Xcode Cloud

If exportArchive fails in Xcode Cloud with No signing certificate "iOS Distribution" found, the accepted forum answer is to revoke the "Distribution Managed (Xcode Cloud)" certificate at Certificates, Identifiers & Profiles, so Xcode Cloud generates a new one. For the "iOS Development" error, revoke the development one. Two other developers confirmed it worked. This is community advice, so read Apple's note first: revoking doesn't affect apps already on the App Store while your membership is valid, but builds you haven't submitted yet may become invalid.

Step 3: Recover a private key after moving Macs

If the certificate shows up on the developer site but not in the security find-identity output, the private key is probably on another Mac. Apple is direct about this: without the private key you can't use the certificate for code signing. You have two ways forward.

Get the key from whoever has it. On the original Mac, open Manage Certificates, Control-click the certificate, choose Export Certificate, and set a strong password. This produces a .p12 file. Double-click it on the new Mac to import it into the login keychain.
If the key is gone, create a new certificate from the Mac you use now. For distribution builds, Organizer's cloud signing from Step 2 may remove the need for a local one.

Treat a .p12 like a password. Apple warns that anyone holding the file and its password can distribute software that appears to come from your account, and advises sending the file and the password through different channels. This matters when you hand your project to a freelancer or paste files into an AI tool's workspace. Keep .p12 and .p8 files out of the repository.

Step 4: Fix "Failed to register bundle identifier"

The full message reads: "The app identifier cannot be registered to your development team because it is not available. Change your bundle identifier to a unique string to try again."

This can happen with AI-generated projects, because a template or scaffold can leave a generic ID such as com.example.app in place. Bundle IDs are unique across all developers, so a common name is usually taken.

For a new app that isn't on the App Store, change the Bundle Identifier to something based on a domain you control, like com.yourcompany.yourapp.
For an app that is already published, don't change it. An update has to use the same ID. An Apple engineer's advice in that situation is to go to Certificates, Identifiers & Profiles, select the right team at the top right, and look for the App ID under Identifiers. If it isn't there, you are probably signed in to the wrong team.

Step 5: Fix "Your team has no devices"

The full text is "Communication with Apple failed. Your team has no devices from which to generate a provisioning profile." This one trips people up because they respond by creating certificates. An Apple engineer explains that the error is about a device, which you need to add to your developer account.

Connect an iPhone, select it as the run destination, and build and run. Xcode should register it automatically. If it doesn't, add it manually under Certificates, Identifiers & Profiles using Apple's device registration steps. Paid memberships can register up to 100 devices per product family each membership year.

Step 6: Fix a profile that doesn't include something

Errors saying a profile doesn't include a signing certificate, or doesn't include an entitlement, mean the profile no longer matches the project. An AI tool may have added a feature such as push notifications or Sign in with Apple, with the edit reaching the entitlements file but not the App ID on Apple's side.

TN3125 explains the rule: the entitlements in a profile are an allowlist, and every entitlement the app claims has to be on that list. The reverse isn't required, so extra entitlements in a profile do no harm.

With automatic signing, the clean fix is to add or remove the capability in Signing & Capabilities so Xcode does the work. Apple's documentation on capabilities and provisioning says that enabling one there creates new provisioning profiles with the new entitlements. Some capabilities need Apple's approval first, so a checkbox alone won't always be enough.

With manual signing, edit the App ID, update the profile on the developer site, then in Xcode open Accounts, select your team and click Download Manual Profiles.

Don't forget extensions

TN3125 counts app extensions as apps, so each one needs its own signing setup. In the cloud signing thread above, Xcode failed on profiles for the app and for its Notification Service Extension. Check Signing & Capabilities for every target in the project, because a widget or notification extension added by an AI tool may still have no team selected.

Step 7: Fix errSecInternalComponent and untrusted certificates

If the identity exists but signing still fails, the Apple forums guide on untrusted certificates lists three causes: an expired certificate, a missing issuer, and trust settings overrides. A missing intermediate certificate is the most common, and a telltale sign is an identity that appears in the first list from security find-identity but is missing from "Valid identities only," with no explanation.

Open Keychain Access and select the certificate. You want a green check and "This certificate is valid."
If it reports expired but the date looks fine, check your Mac's clock.
Download the intermediates from the Apple PKI page and add them to your keychain. The guide says extra intermediates are generally harmless.
Open each certificate in the chain, expand Trust, and return every popup to its default. Apple's certificates are trusted by default, so custom settings can cause this problem.
Run security dump-trust-settings and security dump-trust-settings -d. A stock system reports no trust settings for both.

Don't use sudo while you investigate. The guide calls root a common source of confusion.

Check what your AI tool wrote into the project

Coding agents can edit project.pbxproj directly, and a merge or a generated project can leave targets disagreeing with each other. Before clicking around in Xcode, search for the settings that decide signing:

grep -n -E "DEVELOPMENT_TEAM|CODE_SIGN_STYLE|CODE_SIGN_IDENTITY|PROVISIONING_PROFILE_SPECIFIER|PRODUCT_BUNDLE_IDENTIFIER|CODE_SIGN_ENTITLEMENTS" \
  YourApp.xcodeproj/project.pbxproj

Look for these in the output:

A DEVELOPMENT_TEAM value that isn't your team ID, or differs between targets.
CODE_SIGN_STYLE = Manual on one target and Automatic on another, when you meant to use automatic everywhere.
A hard-coded PROVISIONING_PROFILE_SPECIFIER or CODE_SIGN_IDENTITY copied from a template. With automatic signing, these can fight Xcode's own choices.
Different bundle IDs for Debug and Release that you didn't plan.

Commit before you change anything, so you can see exactly what Xcode rewrote. After that, tell your agent not to edit signing settings. Signing belongs to you and your account, and each guess from the tool adds a new variable.

If you build with Expo and EAS

EAS can create and hold your credentials, so the Xcode steps above often don't apply. Run eas credentials, choose iOS, and you can inspect and manage what Expo has stored. Three details from Expo's credentials page are worth knowing:

A distribution certificate belongs to you as the developer and is used across your apps. A provisioning profile is specific to one app.
Profiles expire after 12 months, which doesn't affect production apps. A new one is created at your next build, or through eas credentials.
Clearing credentials in eas credentials only removes them from Expo's servers. Removing them from Apple's side happens in the Apple Developer Console.

Roles apply here too. Expo's permissions page says that on an individual account only the Account Holder can generate credentials. On an organization account, the Account Holder and Admins can, and an App Manager can only with "Access to Certificates, Identifiers, and Profiles" enabled.

If you already have a certificate and profile, you can use them through local credentials. Add a credentials.json file like this and set "credentialsSource": "local" on the build profile in eas.json. Without that setting, EAS uses the remote credentials.

{
  "ios": {
    "provisioningProfilePath": "ios/certs/profile.mobileprovision",
    "distributionCertificate": {
      "path": "ios/certs/dist.p12",
      "password": "DISTRIBUTION_CERTIFICATE_PASSWORD"
    }
  }
}

Keep this file and those certs out of Git. Apps with a share extension or other target need each target listed under ios with its own profile and certificate.

Signing in CI

If a build works in Xcode but fails on a build server, the server usually can't reach your account. xcodebuild won't talk to Apple's developer site unless you pass -allowProvisioningUpdates. With that flag, as quoted from man xcodebuild in this forum thread, it can create and update profiles, app IDs and certificates for automatically signed targets. The flag requires an account added in Xcode, or an App Store Connect key passed like this:

xcodebuild archive \
  -project YourApp.xcodeproj \
  -scheme YourApp \
  -archivePath build/YourApp.xcarchive \
  -allowProvisioningUpdates \
  -authenticationKeyPath /path/to/AuthKey.p8 \
  -authenticationKeyID YOUR_KEY_ID \
  -authenticationKeyIssuerID YOUR_ISSUER_ID

Even so, the reporter in that thread still hit "no profile found" at export until they opened the project in Xcode on the CI machine and let it finish managing signing. Try that if the flags alone don't work.

Prove the fix before you upload

A green build tells you Xcode found something to sign with. It doesn't tell you the result has the entitlements you intended. Two checks from TN3125 will show you. First, read a profile:

security cms -D -i embedded.mobileprovision -o profile.plist
plutil -extract Entitlements xml1 -o - profile.plist
plutil -extract ExpirationDate raw -o - profile.plist

On iOS the profile sits inside the app bundle as YourApp.app/embedded.mobileprovision. Second, compare it with what the app actually claims:

codesign --display --entitlements - --xml YourApp.app | plutil -convert xml1 -o - -

Every entitlement in the second output has to be allowed by the first. To check the identity used, run codesign --display -vv YourApp.app and read the Authority lines.

Expiry is less scary than it looks. TN3161 explains that the App Store re-signs your app with credentials that don't expire, so your own certificate only has to be valid when you submit. An expired distribution certificate blocks your next upload and leaves your live app alone. Also, you can't run an App Store signed build yourself, so test it through TestFlight, which re-signs the app in much the same way as the App Store.

The order to work in

Confirm the account: signed in, right team, paid membership, no pending agreements, enough role.
Commit, then run the grep above and clean up the signing settings.
Run security find-identity -p codesigning to see what this Mac can sign with.
Turn on automatic signing for every target and pick one team.
Build to a real iPhone.
Archive through Organizer, then upload to TestFlight and install from there.

If an AI agent is part of your workflow, the same discipline helps with release work. Jerry PM's Claude Code + Xcode: The Production iOS Workflow Kit is a set of Claude Code rules, commands and agents for iOS projects, including a /ios-release command and a release safety rule. Its product page lists signing as an area that needs human approval. It won't do your signing, and signed archives and App Store submission stay your responsibility, but it can keep an agent from guessing around them.