Re-sign an IPA with a new provisioning profile: when it works and when you must build again

You exported an ad hoc build, shared it, and then a tester got a new iPhone, or the profile expired, or you moved to a new certificate. The app itself is fine; only its signing is out of date. Re-signing fixes that without building again: it takes the finished .ipa, puts in a new provisioning profile and signs it again. It works well when the pieces match and fails in confusing ways when they do not. This guide covers what re-signing changes, what has to match, the tools people use, and the cases where you have to build again.

What re-signing changes

An iOS app carries two things that tie it to a team and to devices. The code signature seals every file in the app bundle and names the certificate that signed it. The provisioning profile (embedded.mobileprovision) says which team and App ID the app belongs to, which certificates may sign it, which entitlements it may use and, for ad hoc and development profiles, which devices may run it.

Re-signing replaces both. The tool removes the old signature, copies in the new profile, then signs every nested piece from the inside out: frameworks, app extensions, a watch app if there is one, then the app itself. The compiled code, the assets and the Info.plist stay as they were, unless you ask the tool to change something.

What has to match

• Certificate and profile. The profile must list the certificate you sign with, and both must belong to the same team. Ad hoc and enterprise profiles go with an Apple Distribution certificate (the enterprise one from an enterprise account); development profiles go with an Apple Development certificate. You need the certificate with its private key, usually exported from Keychain Access as a .p12.
• Bundle ID. The profile's App ID must match the app's bundle ID, either exactly or through a wildcard App ID.
• One profile per extension. Each app extension (widgets, notification service, share extension) and a watch app has its own bundle ID, so each needs its own profile of the same kind.
• Entitlements. Push notifications, app groups, associated domains, keychain sharing and iCloud must be allowed by the new profile. The aps-environment value follows the profile: development for development profiles, production for ad hoc and enterprise.
• Devices. For ad hoc and development builds, the new profile must include every iPhone that should install it. Registering a device on Apple does not add it to old profiles; you make the profile again.
• Dates. Neither the profile nor the certificate may have expired or been revoked.

When you must build again

• Apps downloaded from the App Store. Their code is encrypted, so they cannot be re-signed for testing. Use the .ipa your Xcode or CI exported.
• Store builds. For TestFlight and the App Store, upload the build your Xcode or CI exported for App Store Connect. Re-signing is a tool for test builds.
• A different team. Moving an app to another team's certificate changes the team prefix in app group and keychain identifiers, which can break shared data and extensions. Rebuild under the new team.
• New capabilities or code changes. If the app needs an entitlement it was not built with, or a setting compiled into the code, re-signing will not add it.
• A file that was damaged or edited by hand. Start again from a clean export.

The usual tools

• codesign on a Mac. Apple's own tool. By hand you unzip the .ipa, replace each embedded.mobileprovision, sign the nested bundles and then the app with codesign -f -s and the right entitlements file, and zip the Payload folder again. Precise, but easy to get the order or the entitlements wrong.
• fastlane resign. Wraps those steps on a Mac, for example fastlane run resign ipa:"App.ipa" signing_identity:"Apple Distribution: Example Ltd (ABCDE12345)" provisioning_profile:"AdHoc.mobileprovision". It takes a map of bundle IDs to profiles for apps with extensions.
• rcodesign. Part of apple-codesign, an open source project (Apache 2.0) that signs Apple code on Linux and Windows as well as macOS, with the certificate read from a .p12 file.
• zsign. An open source signer written in C++, often used in sideloading tools, that also runs on Linux.

Whichever you use, check the result before you send it: codesign -dv --verbose=4 Payload/App.app shows the signer, codesign -d --entitlements :- Payload/App.app shows the entitlements, and the free IPA inspector shows the profile type, expiry and device list in your browser.

Re-signing on AppForShare

AppForShare re-signs iOS builds with a new profile, no rebuild, on Pro and Team.

1. Add the certificate once. An Owner or Admin adds one .p12 (Apple Distribution or Apple Development, with its private key) in Settings, iOS re-signing. The file and its password are sealed with Google Cloud KMS and never shown again; the page shows the name, team, kind, SHA-1 and expiry only.
2. Pick the profile. On the build page, "Re-sign with a new profile" uses an active ad hoc, development or enterprise profile from your connected App Store Connect key (the best match for the bundle ID if you pick none), or .mobileprovision files you upload, one per app extension.
3. Check, then sign. AppForShare checks the rules above first and says what does not match: an App Store profile, a profile of another team, a profile without your certificate, an expired profile, or profiles of mixed kinds. Entitlements come from the profile; you can choose to keep the app's own where the profile allows them.
4. Get a new build. The result is a new build of the same app, marked "Re-signed by AppForShare with profile <name> from build X", with the same release notes and password and a new SHA-256. The original build, its link, its SHA-256 and its sign-offs stay as they were. The bundle ID, version and build number are never changed. The new build goes through the usual readiness and install checks, the Security scan and the malware check.

The same works from the CLI with appforshare resign <id|slug> --profile AdHoc.mobileprovision --yes (without --yes it only runs the check) and from AI tools through the MCP tool resign_build. A workspace can re-sign up to 30 builds a day, and re-signed builds count toward storage.

On Team, Hands free does it on its own: after it registers new devices and remakes the ad hoc profile, it re-signs the newest iOS build of the project when there is no GitHub iOS build, and emails each enrolled tester when the build is ready.

What it does not do: re-sign builds for the App Store or TestFlight, re-sign App Store downloads or builds from the old AppForShare site, or re-sign Android files. On Android, AppForShare signs the APK it makes from your .aab with a test key or your own keystore, and serves uploaded APKs as they are.

Common questions

Does re-signing change the app's version?

Not on AppForShare: bundle ID, version and build number stay as built. Some tools, such as fastlane resign, can change them if you ask.

Can I re-sign on Linux?

Yes, with open source signers such as rcodesign or zsign. On AppForShare the signing runs on our servers, so you need no Mac for it.

Why does a re-signed build still fail to install?

Usually the device is not in the new profile, an extension was left with its old profile, or an entitlement is not allowed. Check the profile's device list and the entitlements of each bundle.

Will re-signing fix "integrity could not be verified"?

When the cause is a missing device or an expired profile, a re-signed build with a new profile can install. Other causes need a different fix; see integrity could not be verified.

More on the feature: re-sign iOS builds and the re-signing docs.