Exercise 3: How Ad Hoc Profiles and TestFlight Solve the Same Real Problem Differently — Possible Solution
================================================================================================================

Chapter 4's Ad Hoc provisioning profile and TestFlight both exist to
answer the exact same real, underlying question: how does a signed
build get installed and run on a real device that isn't the
developer's own Mac? Both are, at bottom, mechanisms for authorized
distribution outside the development machine itself.

They solve it through genuinely different real mechanisms, though. An
Ad Hoc profile works by embedding a specific, named list of registered
device UDIDs directly into the provisioning profile itself - the
device has to be individually known and added to that list before the
build will even install on it, and if the app is rebuilt or a new
tester's device needs adding, the profile has to be regenerated and
the app resigned, exactly as Chapter 4's own beta-tester exercise
described.

TestFlight instead separates the distribution step from the device
registration entirely. A build uploaded to TestFlight doesn't need
every individual tester's device UDID baked into a provisioning
profile at all - testers simply install the TestFlight app, accept an
invitation (or use a public link), and TestFlight itself manages
delivering the build to their device.

The real limitation this removes is exactly the manual UDID-collection
burden the chapter opened by naming directly: with Ad Hoc, every new
tester's device has to be individually registered and the app rebuilt
before they can install it. With TestFlight, up to 10,000 external
testers can be reached with no UDID collection process at all - a
real, practical improvement at any beta-testing scale beyond a small,
fixed handful of known devices.

ANSWER: Both exist to distribute a signed build to a real device
outside the developer's own Mac, but Ad Hoc does it by embedding a
fixed, named device list directly in the provisioning profile - which
must be regenerated and the app resigned every time a new device
needs adding - while TestFlight separates distribution from device
registration entirely, letting up to 10,000 external testers install
a build with no UDID collection required at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the shared underlying problem both
mechanisms solve, explains the real structural difference in how each
one solves it, and names the specific, real limitation (manual UDID
collection and app resigning) TestFlight removes.