IPA signing
How iOS Code Signing Works
Build a practical mental model of private keys, certificates, provisioning profiles, entitlements, signatures, and device authorization.
iOS code signing answers two different questions: who signed this code? and is this code authorized to run here with these capabilities? A certificate and private key answer the identity part; a provisioning profile supplies Apple’s authorization boundaries; the code signature protects the signed app and records its claimed entitlements.
The model matters because these objects are related but not interchangeable. A profile can authorize a certificate without giving you that certificate’s private key, and a valid profile does not prove that the IPA you received was signed with an authorized identity.
The relationship in one model
private key + Apple certificate
-> signing identity
-> signs app code, resources, and entitlements
App ID + certificate + allowed entitlements
+ selected devices (when required) + expiry
-> Apple-signed provisioning profile
signed app + embedded profile
-> IPA for that authorization contextThe private key remains in the signer’s Keychain or secured CI environment. It is not placed in the IPA. Losing the private key means the certificate alone cannot produce a new valid signature.
The distinctions that prevent most confusion
| Item | Its job | It is not |
|---|---|---|
| Certificate | Apple-signed statement binding a public key to a team identity | The secret private key that creates a signature |
| Private key | Secret half of the signing key pair, held by the signer | Recoverable from a downloaded certificate or profile |
| App ID | The identifier and capability configuration the profile targets | A signed app artifact |
| Provisioning profile | Apple-signed authorization data for a distribution context | A code signature on the finished app |
| Entitlements | Capability claims inside the signed app, constrained by authorization | A substitute for an App ID or profile |
| Signed artifact | The app and its signature as delivered | Proof that every intended device is authorized |
In particular: certificate != private key; registered device != profile membership; valid profile != valid app signature; and same team != same signing identity. A team can have several certificates and profiles, while a particular signature is made by one private key paired with one certificate.
Certificate and private key: who may sign
A signing certificate connects a public key to an Apple Developer team identity. The matching private key creates the signature. On the signing Mac, Keychain Access should show the certificate with its private key; a certificate imported without that key cannot sign the app. Apple’s TN3161 calls the paired certificate and private key a code-signing identity.
Apple’s TN3161 explains that code-signing identity comes from this key-and-certificate relationship. Certificate expiry or revocation affects future signing and, depending on the distribution method, whether delivered code remains valid.
Provisioning profile: what Apple authorizes
Apple’s TN3125 describes five profile questions:
- Who: which certificates may sign the app.
- What: which App ID or bundle ID the profile covers.
- Where: which devices may run it, when the distribution type uses a device list.
- When: the profile’s validity window.
- How: which entitlements the app may claim.
The profile is itself signed by Apple. For Ad Hoc distribution, its device list is why the same IPA can install on one registered iPhone and fail on another. A device appearing in the team’s registered-device inventory is not enough: it must be selected into the profile embedded in the particular app.
Entitlements: capabilities the app claims
Entitlements enable capabilities such as keychain groups, associated domains, push notifications, or app groups. The profile contains an allowlist; the app’s signature contains the entitlements it actually claims. Every restricted entitlement claimed by the app must be authorized by the profile.
An entitlement mismatch can therefore fail even when the bundle ID and certificate look correct. App extensions are separate signed bundles and may carry their own entitlements and profiles.
The signed artifact: what reaches the device
The finished IPA contains the signed app and, for this distribution context, an embedded provisioning profile. At install or launch, the platform can validate the signature’s integrity, the Apple-signed profile, app identity, authorization period, allowed entitlements, and—where applicable—the device list. Delivery technology does not bypass these checks. Renaming an IPA, changing a manifest, or moving it to a different host cannot repair a signing mismatch.
Keep the conceptual model separate from diagnosis
This page defines the authorization model; it is not an error runbook. When a release needs evidence, start with the exact IPA that reached the tester and inspect these relationships:
- Verify the app bundle’s signature with the system
codesigntool. - Decode the embedded profile with
security cms. - Compare the signing certificate with the profile’s authorized certificates.
- Compare the application identifier and entitlements.
- Check expiry and the target UDID where the profile uses registered devices.
- Repeat for embedded extensions.
Follow Check an IPA’s Code Signature for commands, or inspect the embedded profile for device membership. Re-signing can be appropriate when the artifact owner authorizes it and compatible assets exist, but it is not a substitute for understanding which authorization relationship is wrong.
IPAFlow is in Private Beta and is being developed to make authorized artifact checks and client delivery easier. It does not ask testers for signing keys or bypass Apple’s authorization model.