iOS distribution
How to Distribute an iOS App with Ad Hoc Distribution
Follow the complete Ad Hoc iOS distribution workflow from device registration and provisioning to export, delivery, and install verification.
Ad Hoc distribution lets an Apple Developer Program team deliver an iOS build to a known set of registered devices. It fits a controlled client review, QA group, or UAT session when each recipient device can be registered with the team. It is not public distribution: the device list is part of the authorization chain, not just a delivery spreadsheet.
Choose Ad Hoc when the team owns the app’s signing assets and knows the test devices. Choose TestFlight or another Apple-supported distribution route when the audience cannot practically be maintained as registered devices. A file host, QR code, or delivery service can transport an IPA, but it cannot turn an unregistered device into an authorized one.
The complete authorization chain
An installable Ad Hoc build needs all of these to agree:
- App ID: identifies the app and its enabled capabilities.
- Apple Distribution certificate: identifies the team allowed to sign the build.
- Registered devices: contains every iPhone or iPad that should run it.
- Ad Hoc provisioning profile: binds the App ID, certificate, and selected devices.
- Exported IPA: embeds the current profile and is signed with the corresponding private key.
Keep these three boundaries separate:
| Boundary | What it changes | What it does not change |
|---|---|---|
| Device registration | Adds a device to the Apple Developer team’s registered-device inventory | Does not add it to any existing profile or IPA |
| Profile membership | Adds selected registered devices to a newly generated Ad Hoc profile | Does not sign or update an existing IPA |
| Signing and export | Embeds the selected profile and applies a code signature to the artifact | Does not register devices or make a delivery channel installable |
Registering a UDID is only the first boundary. An IPA exported before that device was added still embeds the old profile and remains unauthorized for the new device.
Step 1: collect and register the target devices
Ask each tester for the device identifier Apple expects, with consent and a label your team can recognize. Validate obvious copy errors locally, then add the device in Certificates, Identifiers & Profiles under the correct Apple Developer team. A device registered to a different team is not available to this team’s Ad Hoc profile.
Apple limits registered devices by product family and membership year. Check available capacity before promising Ad Hoc delivery to a large or frequently changing tester pool. Disabling a device during the membership year does not restore the consumed slot.
Step 2: create or regenerate the Ad Hoc profile
In the Apple Developer account:
- Open Profiles and create a new profile.
- Select the Ad Hoc distribution type.
- Select the intended App ID.
- Select the Apple Distribution certificate whose private key is available to the signer.
- Select every target device.
- Generate and download the profile.
If a profile already exists, edit and regenerate it after adding devices or when its certificate, App ID capabilities, or validity changes. Apple notes that profile regeneration is required after an expiry or certain App ID service changes. Give profiles names that expose the app, environment, and rotation date instead of relying on profile-2.mobileprovision.
Step 3: archive and export the IPA
Create an Xcode archive from the intended commit and configuration. In Organizer, choose distribution to registered devices and export with the matching team and profile. With automatic signing, Xcode can manage the profile; with manual signing, verify the selected profile and certificate explicitly. If an authorized re-sign is necessary, treat it as a new signing event: the re-signer needs an appropriate private key, certificate, profile, and compatible entitlements. Repackaging alone is not re-signing.
Before delivery, inspect the exported artifact rather than the project settings alone. Confirm the IPA embeds the expected profile, application identifier, expiry, certificate, and device list. Nested extensions need compatible signing too.
Step 4: install through a supported path
Apple’s current Xcode help documents installing exported Development or Ad Hoc apps through Xcode or Apple Configurator. A delivery platform may provide a tester-facing link, but hosting does not replace Apple’s signing or device checks. Confirm that the platform explicitly supports the build’s distribution type.
Do not assume that uploading an IPA to ordinary file storage creates an install flow. A direct .ipa download is not the same as installation.
Step 5: verify the artifact, then the delivery path
Record an artifact checksum at handoff so the team and recipient can confirm they are discussing the same IPA. Then test the exact artifact and handoff path a client will receive on a representative registered device. If the build installs on one iPhone but not another, compare the failing device’s UDID with the profile embedded in that delivered IPA. If nobody can install it, inspect certificate/profile alignment, expiry, bundle ID, entitlements, and artifact integrity before changing project settings.
For a focused artifact check, use inspect the embedded profile and inspect the IPA signature. Those pages cover the diagnostic commands; this guide owns the workflow that produces the authorized Ad Hoc artifact.
Use the iOS Distribution Checklist before sending the link. IPAFlow is in Private Beta and is being developed to reduce authorized device-onboarding and delivery work; it does not bypass Apple Developer Program rules.