IPAFlowEarly Access

IPAFlow / errors / provisioning profile expired

Installation errors

Fix an Expired Provisioning Profile in an IPA

Confirm the ExpirationDate inside the failing IPA, regenerate the correct profile, and verify a newly signed replacement artifact.

Updated August 15, 2026

Confirm the ExpirationDate inside the exact failing IPA before changing anything. Do not infer profile expiry from a similarly named file on a Mac, a portal profile that may be newer, a certificate date, or the app’s build age.

If the embedded profile is expired for the distribution workflow that depends on it, the old artifact cannot be repaired on the tester’s phone. Regenerate or obtain the correct current profile, rebuild or authorizedly re-sign, inspect the replacement IPA, and replace the delivered object.

Establish the exact failing artifact

Record the tester-facing URL or transfer path, filename, version/build, intended distribution method, and checksum:

shasum -a 256 ClientBuild.ipa
mkdir ClientBuild-unpacked
unzip -q ClientBuild.ipa -d ClientBuild-unpacked

APP_PATH=$(find ClientBuild-unpacked/Payload \
  -maxdepth 1 -name '*.app' -print -quit)

Verify that the checksummed file is the one the tester actually received. If a CDN, manifest, message, or upload dashboard still returns an older IPA, diagnosing a newer local copy gives the wrong answer.

Preserve the original artifact. Do not edit it in place or overwrite the only evidence.

Decode the profile and confirm its date

For an app that carries embedded.mobileprovision:

security cms -D \
  -i "$APP_PATH/embedded.mobileprovision" \
  -o /tmp/failing-profile.plist

plutil -extract Name raw -o - /tmp/failing-profile.plist
plutil -extract UUID raw -o - /tmp/failing-profile.plist
plutil -extract CreationDate raw -o - /tmp/failing-profile.plist
plutil -extract ExpirationDate raw -o - /tmp/failing-profile.plist
plutil -extract Entitlements.application-identifier raw \
  -o - /tmp/failing-profile.plist

Compare ExpirationDate with a trustworthy current time and record the result. Apple describes the profile’s validity as the “when” boundary in provisioning authorization.

The provisioning-profile inspection guide is the canonical field workflow. It also covers Apple’s warning that the readable internal property list is diagnostic evidence, not a stable product API.

Four dates and states that are not interchangeable

Provisioning-profile expiry, certificate expiry, Apple Developer membership state, and app build age can affect the same release operation, but they are not the same object or date.

Provisioning-profile expiration

ExpirationDate in the embedded profile limits that profile’s authorization. A newer profile in the portal does not change the profile already packaged in the IPA.

Signing-certificate expiration or revocation

The signing certificate has its own validity and revocation state. A profile can be current while its certificate relationship is unusable, and a certificate can be current while the embedded profile has expired. Use Expired iOS Distribution Certificate or Certificate/Profile Mismatch only when the corresponding evidence points there.

Apple Developer membership

Membership determines whether the team can maintain signing and distribution assets and can have distribution-specific operational consequences. A renewed membership does not rewrite an IPA or replace its embedded profile.

App build age

A build date is release metadata, not profile validity. A recent build can embed an old cached profile; an older build can still have a profile whose date has not yet passed. Inspect the artifact.

Do not generalize one distribution method to every app

The practical effect of “expiry” depends on how the app is distributed.

Development and Ad Hoc

These workflows depend on the signed app’s provisioning authorization and, for registered-device distribution, the device set. An expired embedded profile no longer supplies a current authorization for that artifact. Treat install or launch failure as an artifact-replacement problem: refresh the correct profile and produce a new signed IPA.

Do not assume that because an Ad Hoc app launched yesterday, its profile is still current today. Conversely, do not label every generic installation alert as expiry without reading ExpirationDate.

TestFlight

TestFlight is an App Store Connect testing workflow, not a local Ad Hoc IPA handoff. Apple currently documents a build-testing window of up to 90 days and an Expired build status after that availability window. Diagnose TestFlight availability in App Store Connect and upload a new eligible build when needed; do not try to renew an Ad Hoc profile beside a TestFlight installation.

App Store, Custom Apps, and unlisted apps

Store-distributed apps use Apple’s store distribution path. Apple states that existing App Store apps are not affected when an App Store distribution certificate expires while program membership remains valid, although the expired certificate cannot sign new uploads or updates. That is a certificate rule, not permission to apply an Ad Hoc profile repair to an App Store installation.

For a store-delivered app, use App Store Connect build/distribution status and Apple’s store workflows as the source of truth. A local Development or Ad Hoc profile named for the same bundle ID is not the installation evidence.

Proprietary in-house and managed organizational distribution

Apple’s current Platform Deployment guide documents proprietary in-house profile lifecycle separately: in-house distribution profiles expire, and organizations should issue an updated app or, in documented managed cases, distribute an updated profile before expiry. Apple also documents separate certificate validation behavior for in-house apps.

Managed apps can be App Store, Custom, unlisted, or proprietary in-house apps. “Managed” describes device-management control, not one universal signing type. Identify the underlying app distribution method before applying an expiry repair.

Do not use Enterprise or device-management workflows as a shortcut for client testing. Follow the organization’s actual Apple program eligibility and current deployment documentation.

Repair the exact proven expiry

Once the failing IPA’s embedded ExpirationDate is confirmed past, preserve the rest of its intended authorization while replacing the expired profile:

  1. Identify the intended team and App ID. Use the profile and app identifiers, not the profile name alone.
  2. Confirm certificate and private-key availability. The replacement profile must authorize the identity the signing workflow can use.
  3. Confirm the intended device set. For Development or Ad Hoc, preserve the reviewed devices and add only approved new devices.
  4. Regenerate or refetch the correct profile. Apple’s current account help says expired profiles need regeneration.
  5. Deliver the profile to the actual signing workflow. Avoid stale Xcode, CI, export-mapping, or signing-store copies.
  6. Rebuild from source or perform an authorized re-sign. Rebuilding is safer when source and extensions are available. Re-sign only with app-owner authorization and compatible assets.
  7. Inspect the final packaged IPA. Do not stop at a portal success message or downloaded .mobileprovision.
  8. Verify the new ExpirationDate, device membership, App ID, team, certificate authorization, and entitlements.
  9. Verify the main signature and every nested signed target.
  10. Record a new checksum and replace the delivery object.
  11. Acceptance-test that exact checksum on a representative intended device and install path.

How to Re-sign an IPA Safely explains the source-unavailable boundary. Check an IPA’s Code Signature owns signature evidence. If only the device list is stale, use Device Not in Provisioning Profile rather than calling it an expiry incident.

Why common “fixes” leave the old IPA expired

None of these actions modifies the signed bundle inside the old artifact:

The embedded profile is signed app content. Copying a new profile into the extracted bundle without re-signing invalidates the existing code signature. The result must be a newly signed and independently verified artifact.

Current Fastlane boundaries

Fastlane’s current sigh documentation says it can create, renew, download, and repair provisioning profiles. Its force option renews regardless of current state and also adds all available devices to an Ad Hoc profile.

That device-set behavior requires review. Do not use force blindly for a restricted client cohort. Make app identifier, team, distribution type, profile ownership, and device policy explicit.

Fastlane recommends match for teams that centrally synchronize certificates and profiles. If match already owns the release, renew and synchronize through that established store rather than creating a parallel sigh-managed profile. Neither action rebuilds the app, fixes nested target mappings, verifies the final IPA, replaces the client artifact, or proves installation by itself.

Do not run destructive certificate/profile reset commands as a first response. Preserve unrelated working identities and profiles until the exact expired asset and owning workflow are known.

Prevent expiry from becoming a client incident

Track profile lifecycle per release artifact, not only per portal profile. A useful release record includes:

Alert before the earliest active-artifact profile expiry, prepare a replacement while the existing build still works, and retire stale links after acceptance. Do not revoke unrelated certificates or delete all local profiles merely because one client’s IPA is near expiry.

Run the browser-local iOS Distribution Checklist before re-delivery. The operational goal is a traceable replacement artifact, not a newer file sitting in Downloads.

Related next steps

Next step. Replace the artifact only after proving its embedded profile expired and validating the new release evidence. Join Early Access.

Sources