TestFlight Beta Testing, Step by Step

The two lanes, and why the order matters

Almost every TestFlight mistake comes from confusing the two tester types, so start here.

Internal testers are people you have added as users on your App Store Connect team, up to 100 of them. They get every processed build within minutes, with no review step at all. This is your fast loop: you, your co-founder, a couple of trusted friends you have added to the team. Use internal testing to catch the obvious breakage before anyone outside sees it.

External testers are everyone else, up to 10,000, invited by email or by a public link. External builds are the real beta, and they carry one gate: the first build of a given version must pass Beta App Review before external testers can install it. That review is lighter than full App Store review and typically clears in around 24 hours, sometimes inside a few hours. Subsequent builds of the same version generally reach external testers without waiting on another full review.

The right order is therefore: push to internal first, fix what breaks, then submit for Beta App Review and open external testing. Doing it the other way means your external testers download your bugs.

Step by step, first beta to public link

1. Upload a build. From Xcode or, if you build in the cloud, via EAS Submit. The build processes in App Store Connect, usually within 10 to 15 minutes. Our own path was cloud builds, and shipping an Expo app with EAS Build and Submit covers that pipeline end to end.
2. Add internal testers. In App Store Connect, add teammates as users, then enable them for TestFlight. They get the build within minutes. Smoke-test the core flow.
3. Fill in the test information. Beta App Review needs a description, contact details, and, if your app has a login, a working demo account. Missing demo credentials is a common, avoidable rejection at this step.
4. Create an external group and submit for Beta App Review. Add the first build to an external group and submit. Expect about a day for the first build of the version.
5. Invite external testers. Once approved, invite by email or generate a public link. Share the public link anywhere you want testers, up to the 10,000 cap.
6. Collect feedback. Testers can send screenshots and notes from inside TestFlight, and crash logs flow back automatically. Triage, fix, upload the next build.

The 90-day expiry will bite you if you let it

Every TestFlight build expires 90 days from upload. After that, testers see an Expired label and cannot open the app, and a beta that went quiet simply dies without warning. The fix is trivial once you know it: upload a fresh build before the 90 days are up to keep the beta alive, and put the expiry date on your calendar the moment you upload. Slow, part-time betas are exactly the ones that hit this, so treat it as a standing reminder, not a one-time note.

Where TestFlight fit into our real resubmission

Our honest experience with TestFlight is a medium one, and here is exactly what it was. When SparkQuest was rejected on the iOS App Store, we used the EAS preview profile and TestFlight to validate the fixes on a real device before resubmitting, so we were not testing the corrections straight into a full App Store review. That resubmission went out at build 62. TestFlight was the safety net between "we think we fixed it" and "we bet the review on it." We did not run a thousand-person public beta, so we are not going to narrate one. What we can say plainly is that using TestFlight to confirm a fix on-device before a high-stakes resubmission is worth the extra day, and the rejection that made us do it is documented in why apps get rejected in 2026.

Use groups to control who gets what

External testers are organized into groups, and groups are more useful than they first appear. You can create a small "trusted" group that gets every build early and a larger "public" group that only gets builds you consider stable, so your loudest feedback comes from people who opted into the rough edges while casual testers see something closer to finished. Each group can have its own public link, which means you can share one link in a private Discord and a different one on X and see, roughly, where your testers come from. When you enable a build for a group, you choose whether distribution is automatic or manual, so you can stage a rollout instead of pushing every build to everyone at once.

Collect feedback the way TestFlight actually supports

TestFlight has feedback built in, and using it beats asking for emails. Testers can take a screenshot inside the app and TestFlight prompts them to send it with a note, and crash reports flow back to App Store Connect automatically with the stack trace attached. That gives you two honest signals for free: what confuses people, in their words and their screenshots, and what actually crashes, with the trace you need to fix it. Check the feedback and crash tabs daily during an active beta rather than waiting for testers to email you, because most never will. The point of a beta is the signal, and the signal is sitting in App Store Connect whether you look or not.

Manage builds and versions before it gets messy

A few habits keep a beta from turning into confusion:

• Bump the build number every upload. Two builds cannot share a build number under the same version, and Xcode or EAS will reject the duplicate. Our own resubmission cycle ran the iOS build number up to 62 for exactly this reason, each fix a fresh build.
• Keep test notes current. The "What to Test" field tells testers what changed. An accurate note gets you targeted feedback; a stale one wastes everyone's time.
• Remember the version-versus-build distinction. The first build of a new version needs Beta App Review for external testers; later builds of that same version usually do not. Plan your version bumps around that so you are not waiting on review mid-sprint.

TestFlight versus Google Play testing

If you ship both platforms, the beta gates are not symmetrical, and planning for the stricter one saves weeks. TestFlight is fast and forgiving: internal builds in minutes, external in about a day after one light review. Google Play's closed testing is the opposite, a hard gate of at least 12 testers opted in for 14 consecutive days before you can even apply for production on a new personal account. That means Android needs its testers recruited and committed nearly two weeks ahead, while iOS beta can spin up in a day. Start the Android testers early and let iOS follow. The Google Play closed testing guide covers that requirement in full.

Recruiting testers without spamming

You need real testers, and the honest sources are the same warm channels that later become your first users: a small trusted circle for internal, then communities you belong to and a public link for external. Recruiting a beta cohort is not wasted effort, it is the start of your audience and your first retention signal, which is why the first-users playbook treats the testing gate as the beginning of growth rather than a hoop to clear.

From TestFlight to the App Store

TestFlight is the rehearsal, not the show. When a build is stable in beta, you submit that same build for full App Store review, which is stricter than Beta App Review and checks the whole set of guidelines. Passing TestFlight does not guarantee passing App Store review, since the two look for different things, so treat the beta as proof the app works and the full review as proof it complies. The complete submission sequence lives in how to ship an app in 2026.

Common snags, quick fixes

• "Missing Compliance" blocks the build. Answer the export-compliance question in App Store Connect; for most apps using standard encryption the answer resolves it in one click.
• Beta App Review rejected with no demo account. Add working login credentials in the test information. Reviewers cannot test behind a wall they cannot pass.
• External testers see nothing. Confirm the first build of the version cleared Beta App Review; internal availability does not imply external availability.
• Beta went dark. Check the 90-day expiry. Upload a fresh build to revive it.

TestFlight is one step on the way to live

Beta testing sits in the launch stage, right before you submit for full App Store review. For the complete sequence from finished build to live on both stores, start at how to ship an app in 2026. If you are shipping Android too, the parallel gate there is Google Play closed testing with 12 testers over 14 days, which is a stricter, longer requirement than TestFlight and worth planning early. And once you are live, turn to the ASO guide and the first-users playbook to actually get downloaded.