TestFlight beta testing: how to run a beta that actually helps your launch

A good TestFlight beta has one job: find what breaks and what confuses people before strangers on the App Store do. Start small with your own team, move to external testers once Apple approves your first beta build, tell every tester exactly what to try, and plan the whole thing backwards from launch day, because builds only last 90 days.

What TestFlight gives you#

TestFlight is Apple’s free beta tool. You upload a build to App Store Connect, add testers, and they install it through the TestFlight app. According to Apple’s TestFlight overview:

• Internal testers: up to 100 App Store Connect users on your team (people with the Account Holder, Admin, App Manager, Developer or Marketing role).
• External testers: up to 10,000 people, invited by email or a public link.
• Beta review: the first build you add to an external group goes to App Review. Later builds may not need a full review.
• Build life: each build can be tested for up to 90 days.
• Devices: testers can install your beta on up to 30 devices.
• Feedback: testers can send a screenshot with notes from inside your app, and crash reports come with optional comments.

That’s plenty for almost any pre-launch app. The hard part isn’t the tool. It’s running the beta so you learn something.

Step 1: Decide what the beta is for#

Write one or two sentences before you invite anyone. For example:

• “Can a new user get to their first result without help?”
• “Does sync hold up across two devices over a week?”
• “Which of these two onboarding flows do people finish?”

A beta without a question turns into a pile of “looks great!” messages. A beta with a question tells you what to fix before launch.

Step 2: Start internal, then go external#

Internal first. Your team and close collaborators catch the obvious crashes and broken flows. You can set internal groups to receive new builds automatically, so they’re always on the latest one.

External second. Once the basics hold up, add an external group. Fill in the test information Apple asks for (a beta app description, what to test and a feedback email). It’s required before you can share with external testers. Leave time for the first beta review before you need testers in the app.

Step 3: Find testers who look like your users#

Friends are fine for crash-hunting, but they’re polite, and they aren’t your audience. For real signal you want people who have the problem your app solves.

• Your waitlist is the best source: they asked to be told.
• Communities where your users already talk, if their rules allow it.
• A public link in a post, a newsletter or your site. Apple lets you set criteria such as device type and OS version, so the people who join match what you need to test. Turn the link off when you hit your limit so people aren’t left hanging.

Fifty engaged testers who match your audience beat five hundred who installed once and forgot.

Step 4: Tell testers exactly what to do#

Most beta feedback is vague because the ask was vague. Every build should come with:

1. What changed in this build, in one or two lines.
2. Two or three specific tasks: “Sign up, add one item, share it with a friend.”
3. How to send feedback: take a screenshot in the app and add a note. Apple supports this in TestFlight 2.3 and later on iOS, macOS and visionOS.
4. What you don’t need yet, so you aren’t buried in comments about placeholder art.

Step 5: Watch, don’t just read#

Written feedback tells you what people noticed. Watching tells you what they didn’t. Get a handful of testers on a quick call and ask them to share their screen while they try the first-run flow. Don’t help. Note every pause, wrong tap and “wait, where’s…”.

Then check App Store Connect for sessions, crashes and installs per build. If testers install and never open the app again, that’s feedback too.

Step 6: Ship fixes fast and close the loop#

Testers keep testing when they can see their feedback mattered. Reply to reports, ship a fix build and say “this one fixes the thing you found”. Keep a simple list of every issue, its status and the build that fixed it. It doubles as your pre-launch checklist.

Step 7: Plan the beta backwards from launch#

Builds last 90 days, and the first external build needs review, so work back from your launch date:

• Weeks out: internal testing, fix crashes.
• Then: first external build and beta review, recruit testers.
• Then: two or three rounds of build, feedback, fix.
• About a week out: freeze features and submit the build you mean to ship. Our pre-submission checklist covers the last week.

Use the beta to prepare your launch, not just your code#

A beta is also your best source of launch material:

• Your users’ words. How testers describe the app is often a better headline than yours. Use it on your App Store screenshots and landing page.
• Your first reviewers. Testers who loved it are the people to tell first on launch day.
• Real screens. By the end of the beta your UI is stable enough to design screenshots and film a launch video around.

Don’t forget Android#

If you’re launching on Google Play too, check the rules early. Google says new personal developer accounts (created after 13 November 2023) must run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access. That review usually takes seven days or less. Start that clock well before your launch date.

Common mistakes#

• Inviting everyone at once. You only get one first impression per tester. Save your best testers for a build that works.
• No instructions. “Let me know what you think” gets you “nice!”
• Leaving the beta too late. Beta review plus a few fix rounds takes longer than you think.
• Ignoring silence. Testers who stop opening the app are telling you something.

FAQ#

How many external testers can I have on TestFlight?#

Up to 10,000 external testers, plus up to 100 internal testers from your App Store Connect team.

Does a TestFlight build need App Review?#

The first build you add to an external testing group goes to App Review. Apple says later builds may not need a full review. Internal testing doesn’t need beta review.

How long does a TestFlight build last?#

Up to 90 days, after which it’s no longer available to testers.

Should I use a public link or email invites?#

Email works when you know your testers. A public link is easier for a waitlist or a community, and you can set criteria like device type and OS version so the right people join.

How many testers do I need?#

Enough to answer your question. For a first-run flow, a handful of people you watch closely often teaches you more than hundreds who never reply.

Launching soon?#

Ignura is a London launch studio of four people. Once your beta is done, we turn it into a launch: App Store screenshots, a landing page, a launch film, UGC and a launch day we run with you. Book a free 15-min call.