Shipzen
TestFlight Internal vs External Testers: Limits, Review
Updated July 12, 2026 · by the Shipzen team
TestFlight has two kinds of testers, and choosing wrong costs you either reach or speed: internal testers get builds almost immediately but max out at your own team, while external testers scale to thousands but their first build waits on Beta App Review. Everything below comes from Apple's TestFlight documentation.
The decision table
| Internal testers | External testers | |
|---|---|---|
| Who | Your App Store Connect team, with content access | Anyone with an email or the public link |
| Limit | Up to 100 people, each on up to 30 devices | Up to 10,000 people |
| Review | No Beta App Review — builds available right after processing | First build of an app goes through Beta App Review |
| Best for | Daily builds, smoke tests, pre-release checks | Public betas, waitlists, feature validation at scale |
The catch on the internal side: those 100 people must be actual App Store Connect users on your team (Account Holder, Admin, App Manager, Developer, or Marketing) with access to the app. Internal testing is not a way to sneak friends in — adding someone to your team hands them real account permissions. Friends and beta communities belong in an external group.
Beta App Review is not App Review
When you add the first build to an external group, Apple sends it through Beta App Review, which checks it against the App Review Guidelines before external testing can begin. Subsequent builds may not need a full review, which is why the first external build is the one to plan buffer time around. Passing Beta App Review is not App Store approval — the full review still happens at submission, with metadata and completeness checks TestFlight never looked at (that half is covered by the rejection checklist).
Groups and public links
Builds are distributed through groups, and the group is the unit of control: you create multiple groups (say, "Team", "Beta wave 1", "VIP users") and assign specific builds to each. External groups can invite testers two ways:
- Email invites — you control exactly who gets in.
- Public link — anyone can join until the cap you set; you can also gate enrollment by criteria such as device type and OS version so feedback comes from the hardware you actually need tested.
Feedback, sessions, and crashes
Testers on TestFlight 2.3 or later (iOS, macOS, visionOS) can send feedback straight from the TestFlight app, including screenshots taken inside the beta. On your side, App Store Connect tracks sessions and crashes per build — enough signal to see whether a beta wave is actually exercising the app or just installing it.
Build expiry and beta hygiene
- Builds expire 90 days after upload — an external wave running longer needs a re-up, or testers silently lose access.
- You can share up to 100 builds, and test multiple builds concurrently — useful, but it makes "which build is wave 2 on?" a real bookkeeping question.
- Expire superseded builds deliberately so late joiners never install a known-broken one.
Where Shipzen fits
Beta state lives in a different corner of App Store Connect than the release you are preparing, so the "which group has which build, and who gave feedback" question means tab-hopping. Shipzen, a native macOS App Store Connect client, shows TestFlight builds, groups, testers, and feedback alongside your release metadata — one workspace from beta to pre-submission validation, connected through your own API key.
App Store Connect, the way you need to see it. One email at launch, no spam.
Join the waitlist