App Rejection Fix
Menu
Apple App Store

Xcode Signing Errors Blocking Your Build? Separate the Four Layers First.

iOS signing errors are confusing because four different things are called “signing”: the certificate (who you are), the identifier and its capabilities (what the app is allowed to use), the provisioning profile (which certificate may sign which app for which devices), and the entitlements baked into the build (what the app claims). Almost every error message is really about a mismatch between two of them. Separate the layers and the fix is usually obvious.
Get My Free Signing Review

Free initial review · No payment required · No source code required initially

On this page (7 sections)

The four layers

What each signing artefact is and where it lives
Layer What it is Where it lives Typical failure
Certificate Your team’s identity — Apple Development or Apple Distribution Keychain (with its private key) + Apple Developer account Expired, revoked, or on another machine without the private key
Identifier and capabilities The App ID and the capabilities enabled on it Apple Developer → Identifiers A capability used in the app but never enabled on the App ID
Provisioning profile Binds certificate + App ID + entitlements (+ devices for development) Apple Developer, downloaded by Xcode Does not include the signing certificate, or predates a capability change
Entitlements What the built app claims it may do The .entitlements file in the target Claims an entitlement the profile does not grant

Reading the common messages

“Xcode cannot create a provisioning profile for …”

Automatic signing tried to build a profile and Apple refused. Usual causes, in order:

  • The bundle identifier is not registered to your team — or belongs to a different team (a contractor's account, or an old Apple Developer Program membership).
  • The bundle identifier is already in use globally; identifiers are unique across all of Apple, so com.company.app may simply be taken.
  • A capability is enabled in the project but not on the App ID (push notifications, App Groups, iCloud, Sign in with Apple, HealthKit, associated domains).
  • Your Apple ID is on the team but does not have permission to create profiles (App Manager or Admin is usually required).
  • The team's Apple Developer Program membership has lapsed, or an agreement is waiting to be accepted.

“Provisioning profile doesn't include signing certificate …”

The profile was created for a certificate your Mac does not hold. Either import the correct certificate with its private key (a .p12 export from the machine that created it), or create a new distribution certificate and regenerate the profile. A certificate without its private key cannot sign anything — the Keychain will show it without the key triangle.

“Certificate has expired” / “is not trusted”

Distribution certificates expire yearly. An expired certificate does not invalidate an app already on the App Store, but it blocks new uploads until a new certificate and profile exist. “Not trusted” usually means Apple's intermediate certificate (WWDR) in the Keychain is out of date — install the current one.

“Invalid entitlement” / “doesn't support the … capability”

The build claims an entitlement the profile does not grant. Enable the capability on the App ID, regenerate the profile, and check the entitlements file for capabilities left over from an experiment — Push Notifications, App Groups and iCloud are the usual leftovers, and an unused one blocks the upload just as effectively as a missing one.

“Invalid binary” / ITMS-90xxx after upload

The archive was accepted but validation failed: a missing entitlement, an unsupported architecture, a missing icon, an SDK requirement. These are exact, searchable errors — see the Rejection Library entries for invalid binary uploads and ITMS-90078 (missing push entitlement).

Push notifications: entitlement, key and certificate

Push is the single most common signing-adjacent failure because it touches three layers at once:

  • The entitlement (aps-environment) must be in the build — Xcode adds it when the Push Notifications capability is enabled. Without it, the upload is rejected with ITMS-90078.
  • The App ID must have Push Notifications enabled, and the profile must be regenerated afterwards.
  • The server credential is separate: a modern APNs auth key (.p8, per team, does not expire) or a legacy APNs certificate (per app, expires yearly). Pushes failing in production with the app installed correctly is a credential problem, not a signing problem — and after an app transfer the recipient must issue new ones.

Automatic or manual signing?

Choosing a signing mode
Setup Use when Trade-off
Automatic (Xcode-managed) One team, a few apps, developers with Admin/App Manager access Xcode silently regenerates profiles; CI needs an App Store Connect API key to do the same
Manual with an App Store Connect API key on CI Shared CI, several apps, agencies building for clients Explicit and reproducible; someone has to maintain identifiers and profiles
Shared encrypted certificate repository (fastlane match style) Teams where several machines and CI must sign One source of truth for certificates; the repository itself becomes a secret to protect

Agencies and client-owned accounts

If you build for clients, decide deliberately who owns what. The safest arrangement is: the client owns the Apple Developer Program account and the App ID; you are added to their team with App Manager access; CI uses an App Store Connect API key the client can revoke. That avoids the common end-of-project problem where the app is owned by an agency account and has to be transferred later — see App Store app transfer.

What we never ask for

A signing review does not need your private key, your .p12 password, your Apple ID password or a 2FA code, and you should never send those to anyone — including us. We work from error text, the entitlements file, the project's signing settings and, when you engage us for implementation, access your own team grants to a named account or an App Store Connect API key you control and can revoke.

What we do

  1. Classify the error by layer from the message and the project's signing settings.
  2. Reconcile App ID capabilities, profile contents and the entitlements file, and remove leftovers.
  3. Rebuild the signing setup so it is reproducible: identifiers documented, profiles regenerated, CI using an API key rather than a developer's personal login.
  4. Verify by archiving and uploading a build, then hand over the runbook — including certificate expiry dates, so the next renewal is not a surprise.

Checklist

  • Bundle identifier registered to the right team and matching the target
  • Distribution certificate valid, with its private key on the signing machine or in CI
  • Capabilities enabled on the App ID and reflected in a freshly generated profile
  • Entitlements file contains only capabilities the app actually uses
  • Push: aps-environment present, App ID capability enabled, APNs key or certificate current
  • CI signs with an App Store Connect API key, not a personal Apple ID
  • Certificate and profile expiry dates recorded with an owner

Rejection messages covered by this guide

Exact notice wording from the Rejection Library, with what each one means and what to check.

Signing error blocking the release?

Send the error text and how signing is configured (automatic or manual, who holds the certificates, which CI builds the archive). The review returns the layer at fault, the fix, and how to stop it recurring — without ever asking for your private key.

What happens next: an engineer on our technical team reads the notice you send — not an autoresponder. We work out what it most likely means and what we would check, and reply with that assessment and a recommended next step.

The initial signing review is free. Implementation and CI work, if you want us to do it, is quoted separately. We never ask for private keys or certificates.

Get My Free Signing Review

Free initial review · No payment required · No source code required initially