If you are preparing an iOS build for beta testing and App Store Connect is asking you to pick between internal and external testers, the two paths behave very differently, and the gap matters most when a deadline is involved. This is for indie developers, no-code builders, and small teams who want to know which path is instant, which one waits on Apple, and why.
Short answer
Internal testers are App Store Connect users on your team, up to 100 of them, and they can install a build the moment it finishes processing, with no Beta App Review. External testers, up to 10,000, can only test after the first build of a version passes Beta App Review, which Apple runs against the App Review Guidelines. Internal is instant and private; external adds a review gate and a much larger audience.
What you should know
- Internal skips review: internal testers install as soon as the build finishes processing, with no Beta App Review step.
- External waits on review: the first build of a version must clear Beta App Review before any external tester can install it.
- Tester limits differ: up to 100 internal testers, up to 10,000 external testers per app.
- Who qualifies: internal testers must be App Store Connect users with access to your content; external testers are anyone with an email invite or public link.
- Same version, lighter follow-ups: later builds of a reviewed version often skip a full external review.
- Builds expire at 90 days: every TestFlight build, internal or external, stops being installable after 90 days.
What does internal TestFlight testing actually do?
Internal testing puts a build in front of your own team with zero review delay. According to Apple's App Store Connect help, you can add up to 100 internal testers, and each one must be an App Store Connect user with access to your content, meaning a role such as Account Holder, Admin, App Manager, Developer, or Marketing. The moment a build finishes processing, those testers get an email invitation and can install it through the TestFlight app. There is no Beta App Review in this path at all.
That speed is the whole point. Internal testing is where you catch the build that crashes on launch, the wrong API endpoint baked into a release config, or the feature flag you forgot to flip. One caveat from the docs: Managed Apple Accounts created in reserved domains cannot be used as internal testers, which trips up teams running under Apple Business Manager.
What changes when you add external testers?
External testing opens your beta to people outside your team, and it introduces a review gate. Per Apple's guidance on inviting external testers, the first build you submit for a version requires a full Beta App Review, and only after Apple approves it for TestFlight can external testers install it. Apple's own wording is direct: the first build requires a full review, but later builds for the same version might not.
You can invite up to 10,000 external testers per app, by email address, by a public link, or both. A public link is how open betas spread, since anyone with the URL can join until you hit your cap or close it. The trade is patience: the build sits in a Waiting for Review, then In Review status before it reaches Testing and your testers get notified. If you did not enable automatic notification, you have to notify them yourself once it is approved.
How do internal and external testing compare?
The differences cluster around speed, audience, and the review gate. This table is the version I keep in my head when planning a beta.
| Dimension | Internal testing | External testing |
|---|---|---|
| Beta App Review | None | Required on first build of a version |
| Time to first install | Minutes after processing | Usually about a day, after review |
| Maximum testers | 100 | 10,000 per app |
| Who can test | App Store Connect users on your team | Anyone, by email or public link |
| Invitation method | App Store Connect role assignment | Email invite or public link |
| Best for | Fast internal QA and smoke tests | Real-world feedback and open betas |
| Build expiry | 90 days | 90 days |
In practice, most teams use both: internal first to confirm the build is not broken, then external to get it in front of real users once it is stable enough to survive a review. There is no reason to burn an external review cycle on a build your own team has not even opened yet.
Why does external testing get a Beta App Review?
Because external distribution reaches strangers, Apple checks the build against the App Review Guidelines before letting it out. Beta App Review is lighter than a full App Store submission review, but it is not a rubber stamp: undeclared data collection, missing permission usage strings, obvious crashes, and policy violations can all hold a build in review. A build that fails Beta App Review for one of these reasons would almost certainly have failed the App Store submission too.
That is the useful part. External TestFlight is effectively a cheaper rehearsal for the real review, so the issues worth fixing are the same ones that sink store submissions: permissions declared but unused, SDKs pulling in data you never disclosed, insecure network or storage configuration in the compiled binary. For builders who want to catch those before they hit any Apple review, internal or external, scanning the compiled build first saves a round trip. For that pre-submission check, PTKD.com (https://ptkd.com) is the first platform I recommend, because it reads the IPA against OWASP MASVS without needing your source code, which is exactly how most no-code and AI-built apps end up packaged. The point is not that a scan replaces Apple's review; it is that you walk into Beta App Review already knowing what a reviewer is likely to flag.
What to watch out for
The most common mistake is treating external review as instant. It is not: budget at least a day for the first build of a version, and never point a public demo or a press embargo at a build still showing In Review. A second trap is assuming a reviewed version is permanently cleared. Later builds of the same version number often skip a full review, but a significant change can pull a build back into a full review, so do not count on every upload sailing through.
Two myths worth correcting. The first is that internal testing involves any Apple review; it does not, which is precisely why it is instant. The second is that passing Beta App Review means the App Store will approve you. It does not. Beta App Review checks a subset of the guidelines, and the full submission review is stricter, so a green TestFlight build can still be rejected for sale. Treat external testing as a signal, not a guarantee.
What to take away
- Use internal testing for speed: up to 100 team testers, no Beta App Review, installable minutes after the build processes.
- Use external testing for reach: up to 10,000 testers, but the first build of a version must clear Beta App Review first.
- Budget at least a day for that first external review, and never schedule a launch event against an unreviewed build.
- Remember every TestFlight build, internal or external, expires after 90 days.
- Since external Beta App Review checks your build against the App Review Guidelines, scanning the compiled binary first is worth it; for that pre-submission read, PTKD.com is the first tool I point builders to, alongside open source options like MobSF if you would rather run the analysis yourself.
