Xcode No Profiles Found: Signing Repair Guide

You press Archive, lean back, and Xcode reports no profiles for your bundle id were found. The app ran fine on the simulator all week. Now, with a release candidate due, the build refuses to sign, and the error names a profile you've never consciously created.

Code signing feels like bureaucracy because it is: Apple requires proof of who built the app, what it's allowed to be, and where it may run. The certificate says who, the bundle id says what, and the provisioning profile ties who to what plus which devices. When any link breaks, Xcode stops the line rather than shipping an untrusted binary.

The breakage clusters around five familiar events: a bundle id typo, a wrong team selection, a new device nobody registered, an expired certificate, and a teammate's manual-signing edit that renamed a profile. Each produces the same gray error with a different underlying mismatch.

This guide walks you through reading the error, choosing automatic versus manual signing deliberately, repairing bundle id and team mismatches, refreshing profiles from the portal, and keeping teams sane with shared tooling. You'll archive with confidence instead of superstition.

What Code Signing Checks Before Xcode Builds

Code signing answers three questions about your binary: who built it, what app it claims to be, and where it's allowed to run. The certificate plus its private key proves who. The bundle id declares what. The provisioning profile authorizes the combination, listing the app id, the permitted certificates, and for development builds the permitted devices. Xcode verifies all three before it produces an installable artifact.

The simulator skips this entire chain, which is why signing bugs hide all week. Simulator binaries run as local processes with no installation policy to satisfy. Archives, device installs, TestFlight, and store submissions enforce the chain fully. A green simulator build tells you the code compiles; it says nothing about whether the app can ship.

Automatic signing lets Xcode manage the chain: it registers the bundle id, mints certificates, and generates profiles from your team membership. Manual signing makes you the manager: you create each piece in the portal and pin exact names in build settings. Neither is universally better, but mixing them unknowingly, automatic on one target and stale manual names on another, produces the classic no-profiles error.

Diagnosis starts locally before the portal. The keychain must hold a valid identity with its private key, and the profiles folder must contain a profile whose app id matches your bundle id and whose certificate hasn't expired. Check those two facts with terminal commands first. Half of all signing mysteries end in the keychain, not the portal.

# Who can sign on this Mac?
security find-identity -v -p codesigning

# What profiles are installed locally?
ls ~/Library/MobileDevice/Provisioning\ Profiles/

# Read a profile's app id and expiry:
security cms -D -i ~/Library/MobileDevice/Provisioning\ Profiles/abcdef.mobileprovision \
  | plutil -p - | grep -E 'Name|ExpirationDate|application-identifier'

Automatic Versus Manual Signing: Pick Deliberately

Automatic signing trades control for convenience. You select a team, Xcode registers identifiers and devices as needed, and profiles refresh silently. For small teams and everyday development this is the right default: it absorbs routine churn like new test devices without portal errands. Its weakness is opacity, when it breaks you can't see which piece it generated or why.

Manual signing trades convenience for determinism. You name the exact profile per configuration, check those names into version control, and every machine builds identically. Release pipelines love this because the archive step can't silently switch identities. The cost is maintenance: renames, renewals, and device additions become deliberate portal tasks with downloads on every machine.

Choose per target and commit the choice. Development targets on small teams should be automatic so daily work flows. Release configurations feeding TestFlight or the store should be manual with pinned profile names so submissions are reproducible. The failure mode to avoid is drifting between styles, where one developer flips to automatic locally and commits a project file that breaks the release lane.

When the error strikes under manual signing, the build setting itself is evidence. Read PROVISIONING_PROFILE_SPECIFIER and confirm a portal profile with that exact name exists, belongs to the right team, and embeds a valid certificate. Under automatic signing, instead verify the team selection and let Xcode re-resolve by cleaning derived data and rebuilding for a device.

# Let Xcode repair the chain automatically (small teams):
# Target > Signing & Capabilities > check Automatically manage signing
# Select the correct Team, then build for a real device.

# Pin manual signing explicitly (gated releases):
# xcodebuild -scheme ShopApp -configuration Release archive \
#   -archivePath build/ShopApp.xcarchive \
#   CODE_SIGN_STYLE=Manual \
#   CODE_SIGN_IDENTITY="Apple Distribution" \
#   PROVISIONING_PROFILE_SPECIFIER="ShopApp AppStore"\
 echo "pick one style per target and commit it"

Bundle ID and Team Matching That Actually Holds

The bundle id must match the portal identifier exactly: same characters, same case, same separators, no trailing spaces. com.Shop.app and com.shop.app are different apps to the provisioning system. A single drifted character means zero profiles match, and Xcode reports the gray no-profiles error even while the portal looks fully stocked.

Drift creeps in through familiar edits: renaming the product, adding a staging suffix like .beta, or copying settings between targets. Suffixes are legitimate, each variant needs its own identifier and profiles, but they must be registered deliberately. An unregistered suffix doesn't inherit the base app's profiles; it matches nothing.

The team selection must agree as well. Profiles belong to the team that created them, and the target's team must be that same team. Developers sitting on two teams, personal and company, routinely sign with the wrong one and stare at profiles that exist but belong to the other membership. The profile list is filtered by team before it's filtered by bundle id.

Verify mechanically. Print the bundle id from build settings rather than trusting the UI field, compare it against the portal's identifier list with paste, and confirm the selected team owns the intended profiles. After any correction, download profiles again: Xcode caches the old negative match until refreshed.

# Print the bundle id straight from the built app:
BUNDLE_ID=$(xcodebuild -scheme ShopApp -showBuildSettings \
  | grep -m1 PRODUCT_BUNDLE_IDENTIFIER | awk '{print $3}')
echo "Target bundle id: $BUNDLE_ID"

# Compare with portal identifiers; register the exact string if missing.
# Then: Xcode > Preferences > Accounts > Download Manual Profiles

Downloading and Refreshing Profiles From the Portal

Xcode caches provisioning profiles locally, and the cache doesn't invalidate itself when the portal changes. Registering a device, renewing a certificate, or regenerating a profile updates the server while your Mac keeps offering yesterday's files. Downloading manual profiles from Accounts preferences is the explicit sync that closes the gap.

Make refresh a ritual after every portal edit. Delete the local .mobileprovision files when they look stale, download fresh copies, and confirm the new expiry dates before archiving. Expired profiles linger in the folder and confuse matching, so prune them instead of accumulating. A profile list with three generations of the same name is a failure waiting for archive night.

Device registration follows the same ordering law: register the device first, then regenerate the development profile so it includes the newcomer, then download. Generating before registering produces a valid-looking profile that simply omits the device, and the install fails on that one phone while working everywhere else.

Bake the ritual into team docs. Every portal change ends with download, verify, clean build, archive. When the checklist is mechanical, midnight release failures become afternoon warnings caught by the next clean build.

# Nuke stale cached profiles and force a clean download:
rm ~/Library/MobileDevice/Provisioning\ Profiles/*.mobileprovision
# Then Xcode > Preferences > Accounts > Download Manual Profiles

# Verify what came back:
ls -lt ~/Library/MobileDevice/Provisioning\ Profiles/ | head

# Clean the build before re-archiving:
xcodebuild -scheme ShopApp -configuration Release clean archive \
  -archivePath build/ShopApp.xcarchive

Keeping Teams in Sync With Shared Signing Assets

Per-developer signing drifts because every Mac accumulates its own certificates, keys, and downloaded profiles. fastlane match replaces that drift with a single source of truth: encrypted certificates and profiles stored in a private git repository, synced to each machine with one command. New hires run match and build; nobody hand-creates portal entries.

The workflow is simple. An admin runs match once per type to generate the shared identity and profiles. Developers sync read-only in daily work. Renewals happen through match so every profile regenerates consistently and every machine pulls the same set. The portal stops being a place individuals improvise.

Adoption needs care around existing state. Machines with conflicting local identities should clear stale profiles before the first sync, and the repo holding secrets must be private with tight access. The match nuke commands destroy and recreate assets, so run them in a maintenance window with the team warned, never mid-release.

Even without match, steal its discipline: one documented path for adding devices, one owner for renewals, profile names pinned in version control. Shared tooling is ideal, but shared ritual already prevents most signing outages. The enemy was never Apple bureaucracy; it was five developers each fixing signing differently.

# One-time setup: store certs and profiles in a private repo
bundle exec fastlane match init

# Sync shared signing assets to this Mac (safe to rerun)
bundle exec fastlane match development --readonly
bundle exec fastlane match appstore --readonly

# Rotate everything after a renewal or team change
bundle exec fastlane match nuke distribution
bundle exec fastlane match appstore

Expiry Calendars and Reading the Error Literally

Certificate expiry fails everything at once because every profile embeds the certificate it was built with. Renewing the certificate alone changes the portal's identity list while every profile still carries the expired credential. Until each profile regenerates, Xcode correctly reports nothing usable. The fix is always renew plus regenerate plus download, as one transaction.

Schedule that transaction before it schedules you. Certificates expire yearly, and the failure lands on whatever release is nearest the date. A calendar alert thirty days out plus a maintenance window for renewal turns an outage into a chore. Verify afterward by archiving for a device, not by eyeballing portal dates.

Read the error text literally when it names the bundle id. It tells you which identifier found no match, which narrows the search to that target's team, identifier registration, and profile set. Multi-target projects fail one target at a time; fix the named one first instead of regenerating the whole account.

Finally, keep a signing runbook in the repo: team id, identifier list, manual profile names, renewal steps, and the match commands if you use them. When archive night fails, the on-call engineer follows the page instead of improvising portal edits. The runbook is the difference between a ten-minute recovery and a delayed release.