IPA delivery
How to Install an IPA on an iPhone
Choose a supported installation path for a signed IPA and verify the device, profile, signing, and artifact prerequisites before troubleshooting transfer.
An IPA is an app artifact, not permission to install an app on any iPhone. A successful installation requires three things to agree:
- the IPA’s signature and embedded provisioning profile;
- the target device and the app owner’s Apple distribution authorization; and
- an installation path supported for that distribution method.
For a Development or Ad Hoc IPA and a device you physically control, Apple’s current Xcode guidance supports installation with Xcode or Apple Configurator. For remote testing, first establish whether the artifact belongs in a registered-device, TestFlight, managed-app, or App Store workflow. A different transfer tool cannot turn one distribution type into another.
Preflight the exact IPA before installing it
Record the filename and a checksum so everyone tests the same artifact. If the file came from an unknown person or untrusted download, stop: do not install it, re-sign it, or weaken device security to make it run.
For an authorized artifact, verify:
- Provenance: who built or exported it, for which app owner and release.
- Bundle identity and version: the expected bundle identifier, version, and build number.
- Distribution method: Development, Ad Hoc, App Store/TestFlight, or an eligible organizational method.
- Signing team and certificate: the intended app-owner team and a certificate compatible with the profile.
- Embedded profile: the expected App ID, entitlements, expiry, and—when required—the target device UDID.
- Device compatibility: the iPhone meets the app’s deployment target and hardware requirements.
- Artifact integrity: nobody modified the app bundle after signing.
The provisioning-profile inspection guide shows how to inspect the embedded profile without changing the IPA. The iOS Distribution Checklist turns the same facts into a repeatable release handoff.
Case A: Development or Ad Hoc IPA, device in hand
Use a Mac, connect and unlock the iPhone, and accept the normal trust prompt if one appears. The device must already be authorized by the artifact’s signing configuration.
Install with Xcode
- Open Xcode and choose Window → Devices and Simulators.
- Select the connected physical device.
- In the installed-apps area, choose the add control and select the IPA.
- Observe Xcode and the iPhone for the first specific failure.
- Launch the installed app and test the release-critical path.
Apple documents selecting an IPA from the Installed Apps section for a connected device. Xcode supplies the transfer path; it does not silently add a missing device to the IPA’s embedded profile or repair an invalid signature.
Install with Apple Configurator
- Connect the device and select it in Apple Configurator.
- Choose the action to add apps.
- Choose the app from the Mac and select the IPA.
- Let Configurator complete the operation, then verify the app on the device.
Apple Configurator is also transport. iOS still evaluates the signature, bundle identity, entitlements, profile, expiry, and device authorization.
If the alert mentions Developer Mode or another current device requirement, follow the exact guidance shown by the current iOS and Xcode versions. Do not use unofficial profiles or security-bypass instructions as a substitute for valid signing.
Case B: remote registered-device tester
A remote tester cannot use your local Xcode window. The app owner needs a maintained delivery path that supports the exact registered-device artifact and the current Apple platform behavior.
Before sending any link:
- confirm the tester supplied the correct physical-device UDID with consent;
- verify that device in the correct developer team;
- select it in the relevant Development or Ad Hoc provisioning profile;
- export or authorizedly re-sign a replacement IPA containing that refreshed profile;
- verify the hosted object is the replacement artifact, not an older file; and
- test the complete path with an eligible device.
The send an IPA to a client guide owns the remote handoff workflow. OTA IPA Installation explains the important difference between delivery and authorization, including the limits of current Apple documentation.
Case C: the device is not registered or not in the profile
If the artifact uses registered-device distribution, no installer can bypass a missing device authorization.
- Find the intended iPhone UDID using a reliable method.
- Validate the UDID format before changing the account.
- Register the device in the app owner’s correct team.
- Add or select it in the relevant provisioning profile.
- export or authorizedly re-sign a new IPA using that refreshed profile;
- replace the delivered artifact and verify the replacement.
Registration after export does not mutate the old IPA. If the account record is correct but the artifact still fails, use Device Not in Provisioning Profile.
Case D: source code is unavailable
First inspect the existing IPA. If the app owner authorizes re-signing and provides compatible signing assets through an approved secure process, a release engineer may be able to produce a replacement artifact. Re-signing is not a way to claim another developer’s app, bypass entitlements, or avoid Apple program rules.
If ownership or authorization is unclear, stop. Ask the app owner to supply a correctly distributed build. Do not ask a tester to share Apple Account credentials, signing certificates, P8 keys, P12 files, or device passcodes.
Case E: the intended route is TestFlight or the App Store
An arbitrary local IPA is not uploaded to a tester’s iPhone as though it were a TestFlight invitation. TestFlight is an App Store Connect beta-distribution workflow managed by the app owner; it requires the corresponding release pipeline and build upload. App Store installation similarly comes through Apple’s store distribution.
TestFlight is often a better fit when the team does not want to collect UDIDs or repeatedly rebuild registered-device artifacts. It is not a generic IPA hosting service. If you lack the source or app-owner release access, you cannot convert an unknown IPA into a legitimate TestFlight build.
Compare TestFlight vs Ad Hoc using tester eligibility, review needs, release cadence, and device-registration overhead—not just link convenience.
Case F: managed organizational distribution
Apple documents managed-app installation through device-management services for eligible organizational deployments. That is a distinct policy and device-management context, not a public sideloading shortcut. Use the organization’s administrator, MDM configuration, app licensing, and Apple program eligibility as the source of truth.
For proprietary in-house distribution, confirm the organization actually qualifies for and follows the applicable Apple program. Do not relabel client testing as internal employee distribution.
Diagnose an installation failure in the right order
If the transfer starts but iOS rejects the app, stop switching installer tools and capture the first concrete error. Then check:
- Artifact identity: correct filename, checksum, bundle identifier, version, and build.
- Profile: correct App ID, unexpired, expected device present when required.
- Signature: intact and compatible with that profile and entitlement set.
- Device: correct UDID, OS/device compatibility, available storage, and current platform requirements.
- Delivery: the tester actually received the replacement IPA rather than a cached or older object.
If the same IPA works on one registered device but not another, follow IPA Installs on One iPhone but Not Another. For a generic device alert, use Unable to Install App and preserve the original evidence instead of repeatedly re-exporting.
What an installer cannot fix
Xcode, Configurator, and a download page cannot:
- add an omitted UDID to a signed artifact;
- revive an expired profile or revoked certificate;
- repair a signature after the app bundle changed;
- change the bundle ID, entitlements, or deployment target safely after signing;
- convert Development or Ad Hoc distribution into TestFlight, App Store, or managed distribution; or
- authorize software of unknown provenance.
The reliable path is to identify the intended distribution method, correct the signing inputs, produce one replacement artifact, and test that exact file. IPAFlow is in Private Beta for authorized client-device delivery operations; it does not bypass Apple’s signing, device, security, or program controls.