IPA signing
How to Re-sign an IPA Safely
Learn when an existing IPA can be re-signed, what signing inputs must agree, how to inspect the result, and when rebuilding is safer.
Re-signing an IPA means replacing its existing code-signing authorization with another authorization controlled by the app owner. It does not make an arbitrary IPA installable on every iPhone. The replacement certificate, private key, provisioning profile, application identifier, entitlements, nested code, and target devices must still form a valid chain.
If you have the source and build environment, a clean archive and export is usually the safer choice. Re-sign only when the app owner authorizes it, the existing artifact is trustworthy, and rebuilding is impractical or would change the artifact you need to deliver.
The authorization chain that must agree
A valid re-signed Ad Hoc IPA depends on all of these facts:
- The app identity: the bundle identifier must match the App ID authorized by the new profile.
- The signing identity: the signer must hold the private key for a current Apple Distribution certificate selected by that profile.
- The entitlements: the app’s requested entitlements must be permitted by the profile. Re-signing cannot grant a capability that the team or App ID does not have.
- The device list: for Ad Hoc delivery, every intended device must be registered and included in the embedded profile.
- Every nested executable: extensions, frameworks, App Clips, and other signed code must remain consistent with the outer app signature.
- The final container: the resulting IPA must package the signed app without changing it afterward.
Apple describes a provisioning profile as a signed property list that joins the app, team, certificates, devices, and allowed entitlements. It is an authorization input, not the signature itself. Merely replacing embedded.mobileprovision changes signed bundle content and invalidates the existing app signature.
Rebuild or re-sign?
Choose a new archive and export when you can reproduce the app from source, entitlements or extensions have changed, the original IPA’s origin is uncertain, or you cannot explain its current signing state. Xcode can then resolve capabilities and sign nested code in the expected build order.
Consider an authorized re-sign when you must deliver an existing owner-supplied IPA, the source build is unavailable or deliberately frozen, and you control a compatible certificate, private key, App ID, and profile. The result is a new artifact: preserve the original rather than overwriting it.
Stop if the app owner cannot supply or authorize the required signing assets. Do not obtain certificates from an unrelated team, borrow credentials, strip capabilities to silence errors, or tell a tester to bypass an iOS trust warning.
Step 1: preserve and identify the original IPA
Work on a copy. Record who supplied it, the app version and build, the intended distribution method, and a checksum before extraction:
shasum -a 256 ClientApp.ipa
mkdir original-ipa
unzip -q ClientApp.ipa -d original-ipa
find original-ipa/Payload -maxdepth 1 -name '*.app' -printKeep the original checksum with the handoff record. If the delivered file later differs, you can distinguish transfer or storage corruption from a signing mistake.
Step 2: inspect the existing app before changing it
Set APP_PATH to the application bundle reported by find, then decode the embedded profile and inspect the signature:
APP_PATH="original-ipa/Payload/ClientApp.app"
security cms -D -i "$APP_PATH/embedded.mobileprovision" > original-profile.plist
plutil -p original-profile.plist
codesign -d --verbose=4 "$APP_PATH"
codesign -d --entitlements :- "$APP_PATH"Record the bundle identifier, team identifier, certificate details, profile UUID and expiry, authorized application identifier, get-task-allow, device list where present, and entitlement set. The readable profile property list is useful diagnostic evidence, but Apple cautions that its internal structure is not a supported API contract. Use supported signing and export tools for production automation.
Also enumerate nested signed code:
find "$APP_PATH" -type d \
\( -name '*.appex' -o -name '*.framework' -o -name '*.app' \) -printAn extension can have its own bundle identifier, profile, and entitlements. Treat it as a separate signed target instead of assuming the main app profile covers it.
Step 3: prepare only authorized replacement inputs
For Ad Hoc delivery, create or regenerate a profile under the same Apple Developer team that owns the app. Select the intended App ID, a current Apple Distribution certificate whose private key is available to the signer, and the exact registered devices that should install the build.
Before proceeding, verify:
- the App ID matches the app and each extension;
- required capabilities are enabled for that App ID;
- the replacement profile permits the app’s entitlements;
- every intended device appears in the profile for registered-device distribution;
- the certificate is current and the matching private key is present;
- no signing asset is being uploaded to a client-facing form or shared as an email attachment.
If one of those checks fails, repair the Apple Developer configuration or rebuild. Re-signing cannot invent missing authorization.
Step 4: re-sign the complete bundle, not one file
Use a maintained signing workflow that understands the app’s bundle structure. Fastlane’s current resign action is one documented option for replacing the signing identity and profile, but the tool does not remove Apple’s underlying requirements. Xcode-based export is preferable when a reproducible archive is available.
Whichever workflow you choose, the important ordering rule is conceptual: sign the deepest nested code first and the containing app last. Apple’s code-signing documentation explains that a containing bundle records the signatures of nested code. Changing an extension or framework after the outer app is signed breaks that record.
Do not copy a new profile into the app and stop. Do not sign only the outer .app while leaving incompatible extensions. Do not modify executable code, resources, Info.plist, or entitlements after the final signature.
Step 5: inspect the new artifact independently
Extract the output into a new directory and repeat the checks against the final packaged IPA, not the working folder:
shasum -a 256 ClientApp-resigned.ipa
mkdir final-ipa
unzip -q ClientApp-resigned.ipa -d final-ipa
FINAL_APP="final-ipa/Payload/ClientApp.app"
security cms -D -i "$FINAL_APP/embedded.mobileprovision" > final-profile.plist
codesign --verify --deep --strict --verbose=2 "$FINAL_APP"
codesign -d --entitlements :- "$FINAL_APP"Compare the final profile and entitlements with the evidence from Step 2. Confirm the expected team, application identifier, certificate, expiry, distribution type, and target-device membership. A successful local codesign verification is necessary evidence, but it is not the final installation test.
Step 6: run a representative-device acceptance test
Install the exact checksummed IPA through the same delivery path the client will use. Use a registered device that is actually listed in the profile. Record the device identifier, OS version, install method, timestamp, and outcome.
If installation fails, preserve that IPA and classify the evidence before retrying:
- a missing device points to device/profile authorization;
- a bundle or application-identifier mismatch points to the bundle ID diagnostic;
- a certificate/profile disagreement points to the certificate mismatch guide;
- a generic verification alert needs the integrity investigation.
What re-signing cannot fix
Re-signing is not a substitute for source access, a valid Apple Developer membership, an authorized private key, correct capabilities, or a supported installation method. It cannot safely repair an untrusted artifact, make an Ad Hoc build public, remove device limits, or convert ordinary file hosting into iOS installation.
For routine client delivery, reduce the number of emergency re-signs by recording artifact checksums, profile identity, authorized devices, export time, and the person who approved the build. IPAFlow is in Private Beta for authorized delivery workflows; it does not collect Apple signing credentials or bypass Apple platform controls.