Fix common iOS signing errors

iOS signing has three coordination problems that Mac signing doesn't:

• Provisioning profiles are server-side state. Every entitlement, capability, and device list lives at developer.apple.com. Xcode caches it locally. When the two disagree, builds fail with messages that name neither.
• Automatic signing tries to be helpful and isn't always. It will create profiles, add capabilities, and register devices on your behalf — but only if Xcode knows which team you mean. Multiple-team accounts trigger "No account for team" the first time you open a checked-out project.
• Capabilities have two enablement points. A capability needs to be enabled on the App ID at developer.apple.com and in the entitlements file in your project. Enabling one without the other produces errors that don't mention either location.

The simulator is exempt from all of this — simulator builds don't sign or provision. If your build works in the simulator and fails on device or upload, the failure is in the signing layer, not the code.

Before chasing any signing error, prove the build works without signing. Run on the simulator first:

xcodebuild build \
  -project MyApp.xcodeproj \
  -scheme MyApp \
  -destination 'generic/platform=iOS Simulator'

If this fails, your problem is code, not signing — go fix that first. If it succeeds, every subsequent failure on a device or in an Archive is a signing problem and the diagnostic table below applies.

The classic first-time error on a fresh checkout:

error: No account for team "ABCDE12345". Add a new account in
Accounts settings or verify your selected team is correct.

This does not mean the team doesn't exist. It means your Xcode (and by extension LingCode when it calls xcodebuild) isn't signed into an Apple ID that's a member of that team. Three ways to land here:

• Fresh machine, no Apple ID added to Xcode yet. Open Xcode > Settings > Accounts and add your Apple ID. The team appears automatically once added.
• Multiple Apple IDs, wrong one selected for the project. The project's DEVELOPMENT_TEAM is pinned to one team's ID; your active Apple ID belongs to a different team. Either change the project's DEVELOPMENT_TEAM or add the right Apple ID.
• Apple ID expired / 2FA session lapsed. Xcode > Settings > Accounts > click your Apple ID > the team list is empty or shows a session warning. Re-authenticate.

Find the project's Team ID without opening Xcode:

grep -A1 DEVELOPMENT_TEAM MyApp.xcodeproj/project.pbxproj | head -10

Then confirm that team is in your account at developer.apple.com/account.

Two signing modes, two failure profiles:

• Automatic signing (Xcode > project > Signing & Capabilities > "Automatically manage signing"): Xcode creates and refreshes provisioning profiles on your behalf as you add capabilities or new test devices. Convenient for development; fragile in CI because the credentials needed to mutate developer.apple.com on your behalf aren't trivially scriptable.
• Manual signing: you pick the provisioning profile and signing certificate by name. Reproducible, scriptable, but every capability change requires regenerating the profile on the portal and re-downloading.

The pragmatic split: automatic for local development, manual for archive/release. Switch the build configuration in Xcode > Signing & Capabilities > "Automatically manage signing" per Debug/Release configuration. From the command line:

# Automatic (development)
xcodebuild build \
  -scheme MyApp \
  -destination 'generic/platform=iOS' \
  -allowProvisioningUpdates \
  CODE_SIGN_STYLE=Automatic \
  DEVELOPMENT_TEAM=ABCDE12345

# Manual (release / CI)
xcodebuild archive \
  -scheme MyApp \
  -archivePath build/MyApp.xcarchive \
  -destination 'generic/platform=iOS' \
  CODE_SIGN_STYLE=Manual \
  DEVELOPMENT_TEAM=ABCDE12345 \
  PROVISIONING_PROFILE_SPECIFIER="MyApp Distribution" \
  CODE_SIGN_IDENTITY="Apple Distribution: Your Name (ABCDE12345)"

-allowProvisioningUpdates is the flag that lets xcodebuild talk to Apple's servers to refresh profiles. Without it, automatic-signing builds in CI fail with "no provisioning profile matches."

A capability is enabled in two places. Both must agree:

• The App ID at developer.apple.com/account/resources/identifiers — capability checkboxes (Push Notifications, iCloud, Sign in with Apple, In-App Purchase, App Groups, Associated Domains, etc.).
• The entitlements file in your project (typically MyApp.entitlements) — XML key/value pairs that map to those capabilities.

Errors that surface a mismatch:

Provisioning profile "iOS Team Provisioning Profile: com.you.MyApp"
doesn't include the aps-environment entitlement.

This means your entitlements file declares Push Notifications (aps-environment) but the App ID at developer.apple.com doesn't have Push Notifications enabled. Either enable it on the portal and regenerate the profile, or remove the entitlement from your project.

The executable was signed with invalid entitlements. The
entitlements specified in your application's Code Signing
Entitlements file do not match those specified in your
provisioning profile.

Same root cause, different message — the entitlements file and the profile disagree. The fix order is always: portal first, then regenerate the profile, then let Xcode pick it up.

Ask LingCode to dump the current entitlements from a built app for a sanity check:

codesign -d --entitlements - build/MyApp.app

And to dump what the provisioning profile actually grants:

security cms -D -i build/MyApp.app/embedded.mobileprovision

If the entitlements list in those two outputs doesn't match, that's the bug.

This error has six common causes. Work through them in order:

• Bundle ID mismatch. The bundle ID in your project (PRODUCT_BUNDLE_IDENTIFIER) doesn't match the App ID on the portal. Most common after a rename. Confirm with grep PRODUCT_BUNDLE_IDENTIFIER MyApp.xcodeproj/project.pbxproj.
• Wrong profile type for the build configuration. Debug builds need a Development profile, Archive needs Distribution. Don't reuse one for the other.
• Expired profile. Profiles expire after a year. Regenerate on the portal and re-download.
• Capability added in Xcode but not on the portal (see Step 4). Manual signing surfaces this as a profile mismatch.
• Test device not registered. Development profiles include a fixed device list. New device = regenerate the profile after adding the device's UDID to the portal.
• Signing certificate expired or revoked. The profile is tied to a specific certificate; if the cert is gone, the profile is dead. Issue a new cert, regenerate the profile.

The same error message covers all six. Walk the list rather than guessing.

After any capability change, certificate rotation, or device add, the cached profile in Xcode is stale. The fix is the same every time:

1. Go to developer.apple.com/account/resources/profiles.
2. Find the affected profile, click Edit, click Save (this regenerates against the current App ID state).
3. Download the new .mobileprovision file and double-click to install it into Xcode.
4. Or from the CLI: xcodebuild -allowProvisioningUpdates … and let Xcode fetch the refreshed profile itself.

Skipping the "Edit > Save" step on the portal is the single most common reason a regenerated download still produces the same error — the portal regenerates on save, not on download.

If your iOS archive fails with errSecInternalComponent, the cause is the same as on macOS: the process running xcodebuild (or LingCode, or your CI worker) lacks Full Disk Access and can't read the signing key from the Keychain. The message is identical to a corrupt-keychain message, which is why people chase the wrong fix.

Resolution:

• System Settings > Privacy & Security > Full Disk Access > add Terminal.app (or your CI agent, or the host running LingCode).
• Restart the terminal session — TCC grants don't apply to already-running processes.
• Retry the archive.

If FDA is already granted and the error persists, then it's a keychain problem — open Keychain Access, find the signing certificate, double-click the private key, and check Access Control allows codesign.

Automatic signing is great until it isn't. Switch to manual when:

• You need reproducible CI builds. Automatic profile creation requires Apple ID credentials that don't belong in a CI environment.
• You're on a developer-role account where Xcode can't auto-enable capabilities. Manual signing makes the failure visible at portal-time instead of archive-time.
• You have multiple bundle IDs (main app + extensions + WatchKit) and Xcode is creating overlapping profiles.
• You've spent more than 30 minutes on a "No matching provisioning profile" error that the regenerate-and-retry loop hasn't fixed.

Manual signing trades convenience for visibility. Every error becomes a portal action rather than a black-box Xcode reconciliation.

Drop this skill into LingCode's skills folder and ask LingCode to diagnose any iOS signing error — it walks the diagnostic ladder for you:

---
name: ios-signing-and-app-store
description: Use when shipping an iOS app to TestFlight or the App Store — Apple Developer enrollment, automatic signing, capabilities provisioning, archive, export, and notarytool/Transporter upload. Triggers: 'No account for team', 'No matching provisioning profile', 'TestFlight upload fails', 'App Store submission', 'iOS signing error', capability/entitlement sync failure, simulator-doesn't-need-signing baseline question, errSecInternalComponent during xcodebuild. Actions: prove simulator builds, pick automatic vs manual signing, fix entitlement drift, run notarytool, upload via Transporter. Errors: 'No account for team X', 'Capabilities X requires entitlement', expired profile, bundle ID mismatch. Skip if: just running on simulator.
---

Diagnose and fix iOS signing errors.

Step 0 — Prove the simulator builds clean. Simulator doesn't
sign; if simulator fails, the problem is code, not signing.

Step 1 — Resolve "No account for team": confirm the project's
DEVELOPMENT_TEAM matches an Apple ID added in Xcode > Settings >
Accounts. Re-auth on 2FA lapse.

Step 2 — Pick signing mode deliberately. Automatic for local dev
with -allowProvisioningUpdates. Manual for release/CI with
PROVISIONING_PROFILE_SPECIFIER and CODE_SIGN_IDENTITY pinned.

Step 3 — Capability/entitlement sync: a capability must be
enabled BOTH on the App ID at developer.apple.com AND in the
entitlements file. Verify with codesign -d --entitlements - and
security cms -D -i embedded.mobileprovision.

Step 4 — "No matching provisioning profile" walks six causes:
bundle ID mismatch, wrong profile type, expired profile,
unsynced capability, missing device, dead certificate.

Step 5 — After ANY portal change: Edit > Save the profile on
developer.apple.com (regenerates), then re-download or use
-allowProvisioningUpdates.

Step 6 — errSecInternalComponent = host process missing Full
Disk Access (same as macOS). Fix in System Settings, restart
terminal session.

Step 7 — Escalate to manual signing if automatic has failed
twice in a row.

Save as ~/.lingcode/skills/ios-signing-and-app-store/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →