Ad Hoc versus external TestFlight distribution

WHAT THIS TESTS The interviewer checks whether you can pick the appropriate distribution method given constraints like reviewer delay, tester count, and device control.

A GOOD ANSWER COVERS Ad hoc distribution produces a signed build limited to a list of device UDIDs you registered in the developer portal, embedded in the provisioning profile, with a per-year device registration cap per device type. It installs directly, for instance via a download link or device management, with no Apple review, but adding a new device means registering its UDID and re-signing. External TestFlight distributes through the TestFlight app to potentially thousands of testers identified by email or a public invite link, without needing their UDIDs, but the first build of a version must pass a Beta App Review, introducing a short delay. TestFlight also gives crash reports, feedback, and automatic update delivery.

COMMON WRONG ANSWERS Thinking ad hoc supports unlimited or arbitrary testers; it is bounded by registered devices. Forgetting that external TestFlight requires beta review while internal does not. Believing ad hoc requires Apple review, which it does not.

LIKELY FOLLOW-UPS How does ad hoc differ from internal TestFlight? When is enterprise in-house distribution the right tool instead? How do you collect a tester's UDID for ad hoc?

ONE CONCRETE EXAMPLE A salesperson needs a working build on a specific iPad for a client demo this afternoon, and waiting on a TestFlight beta review is not acceptable. You register that iPad's UDID, create an ad hoc build signed for it, and send the installable file directly, sidestepping any review. By contrast, when you later want two hundred external beta testers to try the release over weeks, you switch to external TestFlight, accepting the one-time beta review in exchange for easy, scalable distribution and built-in feedback.