What you need to submit for TestFlight external testers

What info do I need to submit when I add external testers in TestFlight

When you add external testers in TestFlight, Apple asks for TestFlight test information first. The required items are a beta app description and a feedback email address. If your app needs sign-in or special setup, you also need demo account credentials and any notes Apple needs for beta review.

Apple’s TestFlight help says the test information is required before you can distribute a build to external testers. The same help page also says you can enter it when you add the app or before you invite testers, which matters if your build is ready but your review details are not.

The beta app description should explain what the tester is supposed to try. Keep it concrete. Say what part of the app is under test, which flow matters most, and what a tester should ignore for now. Apple uses this information in TestFlight review, so a vague description slows the process even when the build itself is fine.

The feedback email is not a decorative field. Apple uses it as the address testers can contact through the TestFlight app, and it also becomes the reply-to address in email invitations. Use a mailbox that someone actually watches, because that is where bug reports, access issues, and acceptance questions will land.

If your app has login, Apple’s beta review can require demo account credentials. Put in credentials that work in the build you uploaded, and make sure the reviewer can reach the key screens without guessing. Apple’s beta app review detail documentation says contact information and demo credentials are part of what is provided for beta app review.

A common mistake is to prepare the tester invite before the review details are complete. That fails because external testing starts only after the build is approved for TestFlight beta testing. Apple’s workflow is: provide test information, upload the build, submit it for review, then invite external testers after approval.

Another mistake is treating TestFlight like a public listing form. The beta app description is not App Store marketing copy, and the review notes are not the place to sell the app. Write for the reviewer and the tester. Say what the app does, what to tap, what matters, and what the reviewer needs to know to get through the beta build cleanly.

If you want a practical checklist, use this order: write the beta app description, choose a feedback email, add demo credentials if the app needs them, and add any notes that explain edge cases or setup. Then upload the build and send it to TestFlight review. If you want a separate place to coordinate testers, DevConnect can handle that part, but the TestFlight submission still needs Apple’s own review fields.

Apple also lets you choose whether approved app screenshots and the app category appear in the invitation experience. That is optional, not the core submission, but it affects what testers see when they receive the invite. If you do not want those details shown, you can deselect the App Information checkbox.

Public links change one detail, not the core requirement. With a public link, you still need the same test information and approved build, but you do not need each tester’s contact information up front. That is useful when you do not have a list yet, because Apple says public links can be used to establish a group without anyone’s contact details.

If the build is being used by a team that already has App Store Connect access, internal testing has a different path. Apple separates internal testers from external testers, and internal testers do not replace the test information required for external review. That split is easy to miss when a team has both kinds of testers in one project.

What people get wrong most often is the assumption that TestFlight only needs an uploaded build. It does not. External testing needs review metadata, a working feedback channel, and enough access information for Apple to verify the app. If any of those are missing, the build is not ready for outside testers yet.

What is inconvenient is that the submission details are often different from the final App Store submission. Apple says the beta information can differ from what you enter later for the App Store, so do not copy the final store text into TestFlight without checking whether it still helps a reviewer test the beta.

A simple example helps. If you are testing a new account onboarding flow, your beta app description should say that clearly, the feedback email should go to the person who can answer setup issues, and the demo account should land the reviewer in a real onboarding state, not on a blank home screen. That is the difference between a review that moves and a review that stalls.

Apple’s own pages are consistent on the core answer: provide test information, upload the build, submit it for beta review if you are adding external testers, then invite those testers after approval. The fields that matter are the ones that help Apple review the beta and help testers report problems back to you.