TestFlight Beta Testing: Limits and Best Practices

TestFlight is Apple's official way to put pre-release builds on real devices without collecting UDIDs or juggling provisioning profiles. It is free, it ships with App Store Connect, and the rules that govern it (who can test, how many, for how long and after what kind of review) shape how a careful team runs the last weeks before launch.

Internal versus external testers

TestFlight splits testers into two populations with very different rules. Internal testers are people who already hold a role in your App Store Connect team; external testers are anyone else, identified by an email address or a public link ¹.

Sources: Apple's TestFlight documentation ^1,2,3,4,5.

Internal groups come first in the workflow: you cannot create an external group until an internal one exists, and builds uploaded as "TestFlight Internal Only" from Xcode or Xcode Cloud can never be promoted to external testers or customers ^3,4. Each tester, internal or external, can install your builds on up to 30 devices, and you can keep up to 100 builds shareable at once ².

Tester limits in practice

The 10,000 external cap is per app and counts people rather than installs, so a tester on an iPhone and an iPad uses one seat. For most teams the practical ceiling is far lower: the bottleneck is how much feedback you can read, not how many seats are left.

The 100 internal cap is tighter than it sounds because only App Store Connect users with qualifying roles count; if a colleague is missing from the tester picker, the fix is to change their role ³. Managed Apple Accounts in reserved domains cannot test at all ^1,3.

Build expiry and the status pipeline

Every TestFlight build is testable for 90 days from upload. After that it flips to Expired and testers can no longer launch it, which is a frequent cause of "the app stopped working" reports from long-running betas ^1,6. If a build is still active when the same version goes live on the App Store, testers keep access until it expires on schedule ¹.

Builds move through a set of statuses in App Store Connect. The ones that matter most for beta testing are Missing Compliance (you still owe the encryption export answer), Ready to Submit, Waiting for Review, In Beta Review, Ready to Test, Testing, Rejected and Expired ⁶. Yellow statuses mean a process is running; red means it is on you to act or the build is dead ⁶.

Beta App Review

External testing is gated by TestFlight App Review, a lighter cousin of full App Review that checks the build and its test metadata against the App Review Guidelines. A full review is required for the first build of a version; later builds of the same version may be approved with little or no additional review ^1,4. Adding a build to an external group submits it automatically ².

Two throughput rules apply as of October 2026: you can submit at most six builds to TestFlight App Review in any 24-hour period, and only one build per version can be in review at a time ⁴. Apple does not publish a turnaround target; third-party trackers commonly report a few hours to about two days for a first build, with longer waits during backlogs unconfirmed ⁹. A rejection returns the build to the queue, so avoiding one is worth real effort. Before external submission you must supply a beta app description, review contact information and a feedback email, and if the app needs an account to use, a working demo login ^2,4.

Beta App Review is about major issues such as crashes, unjustified permission prompts or incomplete metadata, not polish; third-party trackers also cite embedded secrets and cleartext traffic as common rejection causes unconfirmed ⁹.

Public links

Public links turn TestFlight into an open beta. Under the Testers tab you create a link for a group, choose "Open to Anyone" or "Filter by Criteria", and share it anywhere ⁴. You can cap joins at anything from 1 to 10,000, restrict by device and OS version range, and disable or re-open the link later ⁴. App Store Connect reports how many people viewed the link, installed, or were turned away by your criteria ².

The trade-off is anonymity. Public-link testers appear only as anonymous entries with install date, session count and crash count; you learn their email only if they choose to type one into a piece of feedback ^4,5. Apple's own advice is to disable the link once you have the testers you want, because anyone can forward it ².

Feedback and crash reports

Testers on TestFlight 2.3 or later send feedback by taking a screenshot inside your app, annotating it and adding a comment, or by attaching context to a crash report. It lands in TestFlight > Feedback in App Store Connect, split into Screenshots and Crashes, filterable by platform, version, group, build, OS and device, and can be opened in Xcode or exported as a .zip ⁵. Crash reports stay downloadable for 120 days ⁵. Feedback can be switched off per group, and the App Store Connect API exposes both screenshot and crash submissions so teams can pipe them into their own trackers; webhooks can announce new feedback as it arrives ⁵.

In-app purchases inside TestFlight builds run against the sandbox, so testers are never charged and sandbox transactions do not carry over to production, which makes it safe to let external testers exercise paywalls ⁷.

Using TestFlight before a launch

A pre-launch beta is most useful when it is staged rather than opened all at once.

1. Internal first, with automatic distribution on. Let every CI build reach the team without clicks, and use it to catch obvious regressions before anyone outside sees them ³.
2. Get the first external build reviewed early. Submit a representative build days before you need external feedback, so the one-time full review is not on the critical path ^1,4.
3. Segment external groups. Separate friendly users, press or partners, and public-link joiners so that each group can be given a different build and a different "What to Test" note ⁴.
4. Use link criteria to protect the beta. Restrict public links to the OS versions you actually support, and cap them so you do not blow past your capacity to read feedback ⁴.
5. Keep a release candidate alive. Expire old builds deliberately and make sure the final RC is not within a few days of its own 90-day limit when it ships ^1,6.
6. Pull crash and screenshot feedback into your bug tracker through the API, then triage by build and OS version ⁵.

TestFlight itself keeps evolving: in 2026 alone, 4.2 added eleven languages (April), 4.3 added in-app search (July), 4.4 added iPhone landscape support (September), and App Store Connect 3.3 sped up large internal invitations ⁸.

How this shows up in the charts

TestFlight does not count toward the App Store charts: beta installs are not units in Sales and Trends, and a 10,000-person open beta will not move an app into a top-free list. What it affects is the shape of launch day. A crash-free first version is far more likely to hold a chart position it earns, because the rankings AppWinners tracks reward sustained download velocity, and poor stability shows up quickly as uninstalls and one-star reviews ^5,6. A staged beta also produces a warmed-up cohort of real users who update on day one, write early reviews and tell others, which is where many sudden chart debuts in the data come from. Treat the external beta as a rehearsal for the launch surge, not a substitute for it.