TestFlight beta testing guide: how to test your iOS app first

TestFlight is Apple's way to put your unfinished app on real phones before the public sees it. It is the best place to find crashes, confusing screens and broken flows, because a bug here costs you an afternoon. A bug in App Review costs you a rejection.

What TestFlight does

According to Apple's TestFlight overview, it lets you distribute beta builds, manage testers and collect feedback. Apple says to keep distributing builds until issues are resolved before you submit for review.

Guideline 2.2 says demos, betas and trial versions do not belong on the App Store. Use TestFlight.

The steps

1. Provide test information. Add a beta app description, an explanation of what to test, and an email address for feedback.
2. Upload your build to App Store Connect. Check Apple's export compliance guidance to see if you need encryption documentation.
3. Create tester groups and assign builds to them.
4. Invite testers. Add up to 100 internal testers (App Store Connect users with access to your content) and up to 10,000 external testers.
5. Testers install TestFlight, then use an email invite or public link to accept and install your app.
6. Collect feedback. On TestFlight 2.3 or later on iOS, testers can send feedback in the TestFlight app or by taking a screenshot inside your beta app. You see it in App Store Connect.
7. Check metrics. You can view sessions and crashes per build, and resend invites to people who have not accepted.
8. Stop testing by expiring the build when you are done.

Rules and limits to know

• Builds last 90 days. A build becomes unavailable to testers after that.
• External testing may need review. When you add the first build to a group of external testers, it goes to App Review. Review is required only for the first build, and later ones may not need a full review.
• Internal testers can start sooner. They are your own App Store Connect users.
• Public links can be limited with criteria, which caps how many external testers join.
• No payment for testing. Guideline 2.2 forbids compensation of any kind, including as a reward for crowd-sourced funding.
• The beta should be a real app. Apple says anything submitted through TestFlight should be intended for public distribution and follow the review guidelines.
• If you do not expire a build and later submit to the App Store, invited testers can still test it after it goes live.

Who should test

Start small. Use your team and two or three friendly outsiders. Then widen it. A good first group is people who match your target user, not just people who like you.

Give each tester a short task list: sign up, do the main action, try to break one thing. Ask for screenshots and the steps to reproduce.

How we do it at SupaKid Studios

For us TestFlight sits in the middle of the QA process. First, agents with their own cloud computers click through the app and record what fails. Tomi's process points a QA agent at the intended behavior, so the failures are reproducible. Fixes go back to the build agent, and the same flows are run again. See how to QA test an AI built app.

Then the build goes to real phones through TestFlight, so a human sees things an agent might not, like a screen that feels confusing. Only after that do we move to App Review. It is part of how we got JetQuest Travel's group travel club app approved and live on the App Store, and what our iOS app team runs for clients, who approve anything that goes out.

When the beta is clean, follow how to submit an app to the App Store.

A simple beta plan

1. Day one: upload the build and invite your internal testers. Ask them to sign up and complete the main action. Fix anything that blocks them.
2. Day two or three: upload the fixed build. Invite a small external group, and remember the first build you add for them goes to beta review.
3. Week one: read the crash and session numbers, group the feedback by screen, and fix the top three problems before anything else.
4. Before you submit: do one clean run on a fresh install with a new account, exactly as a stranger would. Then expire old builds you no longer want people to use.

Keep your notes short. A list of what you tested, what broke and what you fixed is enough to tell you when the beta is done.

What goes wrong

• Testers cannot log in because you did not give them a test account.
• The beta description does not say what to test, so feedback is vague.
• You forget the build expires in 90 days.
• You test only on one phone model.
• You ignore crashes in the metrics view because feedback emails look fine.

Need a hand running a beta?

Book a 30-minute call with SupaKid Studios. We will help you set up a test group and a QA plan.