IPAFlowEarly Access

IPAFlow / errors / ipa installs on one iphone not another

Installation errors

Why an IPA Installs on One iPhone but Not Another

Compare a working and failing iPhone using the exact IPA, embedded profile, UDIDs, OS requirements, install path, and device state.

Updated August 15, 2026

When an IPA installs on one iPhone but not another, the working phone is a useful control: it shows that the artifact and install path can succeed under at least one device context. It does not prove that the failing phone is authorized or compatible.

Start by proving both phones received the exact same IPA. Then compare device authorization, OS requirements, installation route, and local device state one field at a time.

Step 1: prove the artifact is identical

Calculate the checksum of the IPA before each handoff:

shasum -a 256 ClientApp.ipa

Record the filename, byte size, SHA-256 value, app version/build, delivery URL, and timestamp. If the two phones downloaded different bytes or builds, you do not yet have a device comparison. Fix caching, upload, or release labeling first.

Preserve the exact failing file. Do not re-export before you have captured what differed.

Working-vs-failing comparison matrix

Create one incident record with these fields. Fill both sides with observed values rather than assumptions:

Artifact

Device identity

App authorization

Compatibility

Installation path and prior state

This matrix prevents the common mistake of changing signing because two phones merely appear similar.

Inspect the profile inside the delivered IPA

For an Ad Hoc build, the embedded profile is the relevant authorization evidence. Extract and decode it:

mkdir device-compare
unzip -q ClientApp.ipa -d device-compare
APP_PATH="device-compare/Payload/ClientApp.app"
security cms -D -i "$APP_PATH/embedded.mobileprovision" > embedded-profile.plist
plutil -p embedded-profile.plist

Check ProvisionedDevices for both UDIDs, then record the profile UUID, expiration date, team identifier, application identifier, certificate selection, and entitlements. Apple’s profile model binds these facts together; a device entry by itself does not correct an unrelated identity or signing mismatch.

Do not post the decoded profile publicly. Device identifiers and team information belong in a controlled engineering record.

Pattern A: only the working device is in the profile

This is the strongest Ad Hoc-specific explanation. The developer portal may show the failing phone as registered now, while the delivered IPA still embeds a profile generated before it was added.

Repair sequence:

  1. validate the failing phone’s UDID and team;
  2. register it if necessary and capacity allows;
  3. edit or regenerate the correct Ad Hoc profile with the device selected;
  4. export or authorizedly re-sign a new IPA using that profile;
  5. inspect the profile inside the new packaged IPA;
  6. test the exact checksummed replacement on the failing phone.

Use the focused device-not-in-profile guide when this pattern is proven. If the UDID format or source is uncertain, first follow Invalid UDID.

Pattern B: both devices are listed, but compatibility differs

Compare the app’s deployment requirements with each OS version and supported device family. Also check available storage and organizational device-management restrictions. Do not assume the newest phone is automatically compatible; rely on the build’s declared requirements and the exact error.

If the working phone has an older copy of the app, remove it only after recording its version and signing context. A clean install on both devices can eliminate upgrade-state differences, but deleting evidence too early can hide the cause.

When the full alert is “Unable to Install App,” continue with the broader installation diagnostic. When the alert specifically reports verification or integrity, preserve the IPA and use the integrity workflow.

Pattern C: the installation route differs

One phone may have received the app through TestFlight while the other opened a direct IPA URL. One may be connected to Xcode or Apple Configurator while the other uses an OTA manifest. Those are not equivalent tests.

Record the exact path on both devices. For OTA installation, verify that the manifest and IPA URLs are HTTPS and available, the manifest metadata matches the app, and the artifact itself uses a compatible distribution method. For TestFlight, confirm the tester accepted the right invitation and the build is still available.

Do not treat ordinary file download as installation. Hosting cannot add a missing device to an Ad Hoc profile or convert a build to TestFlight.

Pattern D: the artifact or device state is not actually the same

If checksums differ, investigate upload replacement, CDN or browser caching, filename reuse, and mixed build links. If checksums match but only one phone fails, capture:

Change one condition at a time. A successful retry after several simultaneous changes does not reveal which condition mattered.

Ordered diagnostic workflow

Use this sequence to keep evidence intact:

  1. Freeze the IPA: save it and record its SHA-256 value.
  2. Confirm the handoff: verify both phones received the same bytes and build.
  3. Capture device facts: model, OS version, exact UDID, and team registration.
  4. Inspect the embedded profile: compare both UDIDs, expiry, identity, certificate, and entitlements.
  5. Compare the install route: reproduce the working path on the failing phone if appropriate.
  6. Capture the exact failure: avoid summarizing every alert as “won’t install.”
  7. Repair the first proven mismatch: device/profile, compatibility, delivery, or artifact.
  8. Export and verify a replacement: give it a new checksum and test it on both representative devices.

If neither phone’s UDID is in an alleged Ad Hoc profile, question whether the successful installation came from the same route or whether a prior version remained installed. If both are listed and the signature/profile facts match, stop adding devices and focus on compatibility, install path, and the exact device log.

Prevent the next one-device incident

Maintain a consented tester registry that separates a person’s name from the verified device identifier. For each release, record the approved device set, profile UUID and expiry, source/build identity, IPA checksum, delivery route, and representative-device result.

Run the browser-local iOS Distribution Checklist before sending the build. IPAFlow is in Private Beta for authorized device onboarding and delivery evidence; it does not collect signing credentials or bypass Apple’s device authorization.

Related next steps

Next step. Compare both devices against the embedded profile, then run the distribution checklist before exporting a replacement. Join Early Access.

Sources