IPA delivery
Install an IPA Over the Air: What the Link Must and Cannot Do
Separate OTA delivery from app authorization, understand Apple's current documented boundaries, and diagnose landing-page, manifest, IPA, and signing failures.
An over-the-air link can deliver an app, but it cannot authorize that app to run. The IPA still needs a valid signature and provisioning context for the intended distribution method. When registered-device distribution applies, the target iPhone must also be authorized by the profile embedded in the exact delivered IPA.
That separation is the fastest way to troubleshoot OTA installation:
- Delivery layer: landing page, link, manifest where applicable, redirects, authentication, HTTPS, and the hosted IPA object.
- Authorization layer: app ownership, distribution method, signature, certificate, profile, entitlements, expiry, and device eligibility.
A working link cannot repair a bad artifact. A correctly signed artifact cannot compensate for a broken delivery chain.
Start with the current Apple documentation boundary
Apple’s current Xcode help documents Xcode and Apple Configurator for installing exported Development and Ad Hoc IPAs on connected devices. Apple’s current Platform Deployment guide separately documents wireless website-and-manifest installation for proprietary in-house apps distributed by eligible organizations. Apple also documents managed-app installation through device-management services as a distinct organizational route.
Those are different distribution contexts. The current Apple sources cited here do not clearly establish a general browser-based OTA recipe for every arbitrary Ad Hoc IPA. Therefore, do not copy an in-house deployment manifest and present it as universal current Apple support for Ad Hoc client testing.
If a hosted provider advertises registered-device delivery, verify that provider’s current documentation, supported signing type, security model, and tested iOS behavior. The provider must still deliver an artifact authorized for the target device; it cannot override Apple’s installation checks.
This support boundary matters more than historical snippets or an old blog post. Confirm the distribution program first, then choose the delivery path.
What a documented manifest flow does
In the proprietary in-house website flow Apple currently documents, the organization prepares:
- an HTTPS website or landing page;
- a manifest that identifies the app and points to the IPA;
- the IPA at a reachable HTTPS URL; and
- an installation link using the platform’s manifest-service mechanism.
The device follows the installation link, requests the manifest, and then fetches the IPA named by that manifest. A direct hyperlink to an .ipa is not the same operation.
Treat these as conceptual components rather than a timeless copy-and-paste template. Apple can change platform, certificate, trust, and deployment requirements. Use the current Apple deployment documentation for the eligible program and test the exact path on the iOS versions you support.
Diagnose stage A: landing page and tap target
Open the exact tester-facing page on the target iPhone and check:
- the page loads without a TLS or certificate warning;
- authentication succeeds without looping or losing session state;
- the visible install control is a real link, not a disabled script-only element;
- the tap sends the device to the intended current installation URL; and
- Content Security Policy, redirects, or client-side routing do not rewrite the target.
If tapping appears to do nothing, use itms-services Link Not Working for a focused link/request investigation. Do not change the IPA until you know whether the device ever requested the next resource.
Diagnose stage B: manifest request, where applicable
For a distribution context that legitimately uses a manifest, request the exact manifest URL from a clean path. Confirm that:
- it is absolute and served over HTTPS;
- it returns the expected manifest rather than an HTML sign-in page, access-denied response, or generic error document;
- any IPA URL inside it is absolute, current, and points to the intended artifact;
- redirects preserve the required access context; and
- the response is not being replaced by a CDN error or stale cached copy.
Do not publish sensitive tokens inside a permanent manifest URL. If access control is required, design and test the complete authenticated flow instead of making the IPA public as a quick fix.
Diagnose stage C: IPA fetch
Prove that the device can fetch the exact object referenced by the delivery flow. Record its filename, size, version, and checksum. Check that:
- the response is the IPA binary, not a login page renamed as
.ipa; - the URL has not expired before the device follows it;
- the object store or CDN is not serving yesterday’s artifact;
- redirects do not drop authorization or send the device to a regional error; and
- partial, corrupted, or interrupted downloads are not being mistaken for signing failures.
When a team says “the link works,” ask whether that means the landing page loaded, the manifest was fetched, the IPA request succeeded, or the app installed. Those are four different observations.
Diagnose stage D: wrong artifact behind the right link
The most expensive OTA failures are often release-coordination failures: a new device was registered and a new IPA was exported, but the link still points to the previous object.
Compare the hosted checksum with the approved release artifact. Inspect the delivered IPA’s embedded profile, bundle identifier, version, and build. The provisioning-profile inspection guide helps verify the file itself, while Send an IPA to a Client covers artifact naming and controlled handoff.
Do not rely on a changed filename alone. A cache, redirect, or deployment alias can still return the old bytes.
Diagnose stage E: signing, profile, and device eligibility
Once delivery is proven, inspect authorization:
- Is the IPA signed by the intended app-owner team?
- Does the embedded profile match the bundle identifier and entitlements?
- Are the profile and signing certificate still valid?
- For registered-device distribution, is the target iPhone’s exact UDID present?
- Was the device added before this IPA was exported or authorizedly re-signed?
- Does the app support the device’s current OS and hardware?
If the device was registered after export, create a replacement IPA with the refreshed profile and replace the hosted artifact. Reusing the old IPA cannot carry the new authorization.
For device-profile failures, continue to Device Not in Provisioning Profile. If one phone works and another fails, use IPA Installs on One iPhone but Not Another.
Diagnose stage F: the device shows a generic installation error
Preserve the first device message, the time, the tested URL, the artifact checksum, and which network was used. Then follow Unable to Install App in its evidence-first order.
Do not respond by rotating certificates, creating multiple new profiles, and editing the manifest at once. That destroys the evidence needed to distinguish delivery from authorization.
Choose a safer path when OTA is the wrong fit
Depending on the release and audience, a better supported route may be:
- Xcode or Apple Configurator: Development or Ad Hoc artifact, physical device available to the authorized developer or QA operator.
- TestFlight: app-owner beta release through App Store Connect, especially when repeated UDID collection and artifact replacement are poor fits.
- Managed apps: eligible organizational devices controlled through an appropriate device-management service.
- Custom Apps or the App Store: organization-specific or public production distribution through Apple’s supported store paths.
- Proprietary in-house distribution: only for eligible organizations and the internal use case covered by the applicable Apple program and current deployment guidance.
Distribute an iOS App Without TestFlight compares the legitimate alternatives. TestFlight vs Ad Hoc helps choose between a beta pipeline and registered-device testing.
What an OTA link must never promise
An OTA workflow cannot:
- install unsigned or tampered software;
- add a device to an already signed IPA;
- bypass device limits, certificate expiry, or profile expiry;
- turn Ad Hoc distribution into public distribution;
- convert an unknown IPA into a TestFlight build;
- make an organization eligible for Enterprise or managed distribution; or
- justify collecting tester Apple credentials, signing keys, device passcodes, or unrelated identifiers.
The honest workflow proves an eligible distribution method, produces one authorized artifact, proves each delivery stage, and records what the tester actually received. IPAFlow is in Private Beta for controlled, authorized client-delivery operations; it does not bypass Apple program, signing, device, or security requirements.