Archiving and uploading a build to TestFlight

WHAT THIS TESTS The interviewer wants to confirm you have shipped a build and understand the sequence from local archive to a tester's device through TestFlight.

A GOOD ANSWER COVERS First set the run destination to a generic Any iOS Device or a connected physical device, because archives are built for device architectures, not the simulator. Ensure the version and build number are set, incrementing the build number so it is unique. Choose Product then Archive, which builds in the Release configuration and produces an archive that opens in the Organizer. In the Organizer select the archive, click Distribute App, choose distribution to App Store Connect, validate, and upload. Xcode signs the upload using a distribution certificate and an App Store provisioning profile. After upload, App Store Connect processes the binary; once processing completes the build appears under TestFlight. Internal testers, who are members of your team with the right role, can install it immediately, while external testers require a Beta App Review.

COMMON WRONG ANSWERS Trying to archive while a simulator is the destination, which Xcode does not permit. Forgetting to increment the build number, causing an upload rejection for a duplicate. Confusing internal testers, who get builds immediately, with external testers, who need review.

LIKELY FOLLOW-UPS What is the difference between internal and external TestFlight testers? Why must the build number be unique? What signing assets does the upload require?

ONE CONCRETE EXAMPLE You set the destination to Any iOS Device, bump the build to 42, and run Product then Archive. The Organizer opens with the new archive; you click Distribute App, pick App Store Connect, and upload. A few minutes later App Store Connect shows build 42 finishing processing under TestFlight. Your QA teammates, added as internal testers, open the TestFlight app and install build 42 right away to begin verification, with no external beta review required.