1
Signing identity
The .p12 must open with the correct password and represent a usable certificate for the intended workflow.
Technical reference for authorised iOS app workflows
IPA signing compatibility checklist
Before you sign an IPA again, check whether the certificate, provisioning profile, app identifier, target device, and app capabilities actually belong together. This prevents the most common “signs successfully but will not install” loop.
Published 7 August 2026 · Reviewed against Apple’s provisioning-profile documentation
A signing attempt has the best chance of succeeding only when the signing identity, profile, bundle ID, device registration, entitlements, and validity period agree. Changing just one field cannot make an unrelated profile compatible.
The five matching checks
2
Provisioning profile
The .mobileprovision must be valid and include the signing identity it is being used with.
3
App identifier
The IPA’s bundle ID must be covered by the profile’s App ID rule. An override does not authorise an unrelated profile.
4
Target device
For registered-device distribution, the exact iPhone or iPad must be included in the profile’s device list.
5
Capabilities and time
Required entitlements must be permitted by the profile, and neither certificate nor profile can be expired or revoked.
Identify the failing stage first
| What happened? | Check first | What it does not prove |
|---|---|---|
| The signer rejects the files | Certificate password, certificate validity, and whether the profile contains the intended signing certificate. | That the IPA, device, or app identifier is compatible. |
| The IPA signs but will not install | Profile validity, registered device, bundle ID rule, and the final profile embedded in the signed app. | That signing the same files again will change the profile/device mismatch. |
| The app installs but closes | Entitlements, app extensions, iOS compatibility, dependencies, and any app-side account requirement. | That the certificate is necessarily the problem. |
| A previously working app stopped | Certificate/profile expiry or revocation, device/profile changes, and a changed app build. | That an unrelated certificate will solve the issue. |
What a provisioning profile connects
Apple describes the profile as the record that ties together who may sign code, what they may sign, where it may run, when it may run, and which entitlements it may use. That is why a certificate file alone is not enough for a registered-device workflow.
Keep the exact error and the failing stage in your notes. “Could not sign”, “would not install”, and “opened then closed” need different checks.
Before trying again
Confirm
- The
.p12password is exact. - The profile has not expired.
- The profile and signing identity are meant to be used together.
- The target device is registered when that workflow requires it.
Do not assume
- A successful upload means the app can install or launch.
- A new bundle ID value creates a valid profile match.
- Re-signing removes server-side logins, subscriptions, or restrictions.
- One failing IPA means every certificate file is bad.
Frequently asked questions
Does a bundle ID override make any profile work?
No. The profile still has to cover the intended app identifier and permissions. An override does not create that authorisation.
Why can an IPA install but fail to open?
Launching checks more than installation. Missing entitlements, extensions, dependencies, iOS compatibility, or server-side requirements can still stop the app.
What should I record when troubleshooting?
Record the exact error, signing tool, iOS version, the stage that failed, and which certificate/profile combination was used. Do not share private keys or certificate passwords in public support requests.
Optional pre-flight checks
If you already have your own authorised signing files, these CertDrop tools can help inspect a profile/certificate match or an IPA before signing. They do not replace Apple’s rules and do not guarantee that any app will run.