Distribution comparisons
TestFlight vs Ad Hoc Distribution
Choose between TestFlight and Ad Hoc iOS testing using audience, review timing, device registration, build cadence, and client-delivery constraints.
TestFlight is usually the better fit for repeated beta releases, a changing audience, and feedback managed through App Store Connect. Ad Hoc distribution is usually the better fit for a small, known set of devices when the team needs direct control and accepts the work of collecting UDIDs, registering devices, regenerating profiles, and exporting a compatible build.
Neither method is a generic shortcut. TestFlight requires an App Store Connect upload and tester workflow. Ad Hoc requires an Apple Developer team, authorized signing assets, and every target device in the embedded provisioning profile.
The core operational difference
TestFlight authorizes testers through App Store Connect. A team uploads a build, assigns it to internal or external groups, and testers install it through Apple’s TestFlight app. Device UDIDs are not the normal onboarding input.
Ad Hoc authorizes specific devices through the provisioning profile. The team registers each device, selects it when generating the profile, and exports an IPA that embeds that exact authorization. The install surface can make delivery easier, but it cannot add a missing device to the artifact.
That distinction determines who performs work whenever a tester or build changes.
TestFlight: internal and external testing are different
Apple currently allows up to 100 internal testers who are App Store Connect users with access to the app. This route suits employees and close collaborators who can legitimately hold an App Store Connect role. Treating clients as internal users just to avoid external testing controls expands account access and is rarely the right default.
External testing supports up to 10,000 people through email invitations or public links. Testers install the TestFlight app, accept the invitation, and receive assigned builds. Apple says the first build of an app added to an external group is sent to App Review; subsequent builds may not require a full review. Testing begins after any required approval.
Each TestFlight build is available for up to 90 days. That expiry is helpful for beta hygiene but unsuitable when a client expects the same build to remain installable indefinitely. A new upload and assignment starts a new test cycle.
Ad Hoc: explicit device control
An Ad Hoc build needs an App ID, an Apple Distribution certificate, registered devices, and an Ad Hoc provisioning profile that joins them. The IPA must embed the current profile and be signed with the corresponding private key.
Adding a UDID in the Apple Developer account does not update an IPA already exported. The team must regenerate or refresh the profile and create a compatible replacement artifact. Apple also applies annual registered-device limits by product family, so a rapidly rotating audience creates capacity and administrative risk.
Ad Hoc does not use the TestFlight external beta review flow. That can help with a tightly controlled deadline, but it transfers more operational responsibility to the developer or agency: device collection, consent, profile maintenance, artifact traceability, delivery, and install support.
Compare the decision dimensions
Audience and onboarding
- TestFlight: invite people as internal App Store Connect users or external testers. External public links can reduce one-to-one invitation work.
- Ad Hoc: obtain each physical device’s correct UDID, register it under the owning team, and include it in the profile before export.
Build cadence
- TestFlight: better for frequent builds because tester groups remain while builds change. Processing and any applicable external review still affect timing.
- Ad Hoc: every device-set or signing change can require a new profile and artifact. It is manageable for a small stable group, but expensive for weekly onboarding churn.
Artifact starting point
- TestFlight: expects an App Store Connect-eligible upload from the app owner’s release pipeline. Possessing a random IPA does not automatically make it uploadable to TestFlight.
- Ad Hoc: an existing IPA may sometimes be re-signed by the authorized app owner when compatible assets and entitlements exist. Rebuilding from source is safer whenever possible.
Tester experience
- TestFlight: testers use Apple’s app, receive updates, and can submit feedback. The build becomes unavailable after its test period.
- Ad Hoc: the experience depends on the supported install path. A link or dashboard may simplify delivery, but the device and profile checks remain.
Compliance and access
- TestFlight: external testers do not need access to the team’s Apple Developer or App Store Connect account. Internal testers do hold App Store Connect roles.
- Ad Hoc: testers do not need App Store Connect access, but the development team must handle their device identifiers carefully and keep Apple credentials private.
Scenario 1: a client needs one build today
Ad Hoc can fit when the client has a known device, the app owner can register it immediately, the team controls current signing assets, and a compatible build can be exported and tested before delivery. The absence of TestFlight beta review does not eliminate signing or installation work.
If the device is not yet known, the signing owner is unavailable, or the existing IPA has uncertain provenance, a promised same-day Ad Hoc handoff is risky. Use the Ad Hoc workflow to check every prerequisite before choosing it.
Scenario 2: weekly QA builds for a stable internal team
TestFlight internal testing is often lower maintenance when the testers are legitimate App Store Connect users. Groups can remain in place while builds are uploaded and assigned, and no per-device profile edit is needed for normal TestFlight onboarding.
Ad Hoc may still fit a device lab or controlled QA fleet, especially when the team needs direct installation outside TestFlight. Expect profile and artifact work whenever the device set changes.
Scenario 3: external beta with hundreds of testers
Use TestFlight unless another Apple-approved distribution route clearly matches the product. Its external tester capacity, invitation controls, public links, metrics, feedback, and update path are designed for this audience size. Ad Hoc device limits and profile churn make it a poor match for an open or rapidly changing beta.
Plan for the first external group build to enter review and for each build’s 90-day availability. Do not promise a review-free launch time.
Scenario 4: an agency hands a controlled build to a client
The choice depends on the relationship after the first demo:
- choose Ad Hoc for a few known devices, a short review window, direct artifact control, and a team willing to own UDID and profile operations;
- choose TestFlight external testing for recurring builds, more stakeholders, lower device-administration work, and an acceptable review/processing window;
- choose TestFlight internal testing only when the people are genuinely part of the App Store Connect team and should have those permissions.
For an agency that receives only an IPA, first establish who owns the App ID and signing assets. Neither method authorizes republishing a third party’s build.
Scenario 5: UAT must stay reproducible
TestFlight provides a managed build record, tester group, and install/update channel, but the 90-day window must be included in the UAT plan. Ad Hoc can pin UAT to a checksummed IPA and explicit device list, but the team must preserve the profile, export evidence, and exact artifact.
Whichever method you choose, record the source commit, app version/build, signing owner, release timestamp, tester audience, and acceptance result. A delivery link alone is not a release record.
A practical decision rule
Choose TestFlight when audience scale and repeated updates matter more than immediate registered-device control. Choose Ad Hoc when a small known device set and direct timing matter more than the cost of UDID, profile, and artifact maintenance.
If the real constraint is “we already have an IPA,” inspect its distribution and signing state before deciding. Review how IPA re-signing works and the guide to sending an IPA to a client. For a recommendation based on your exact audience and deadline, use the browser-local Distribution Method Selector.
IPAFlow is in Private Beta for authorized client delivery. It does not turn Ad Hoc into public distribution, bypass TestFlight controls, or collect Apple signing credentials.