TestFlight internal testers are up to 100 members of your own team who have a role in App Store Connect, and they receive builds immediately after processing with no Beta App Review, which makes internal testing the fast path for your team. External testers are up to 10,000 people who can be anyone, invited by email or a public link, but the first build of a version you send them must pass Beta App Review before they can install it. So the two key differences are who they are and how many, and whether a review stands between the build and the testers. Use internal testers for quick iteration with your team, and external testers to reach a wider group of real users once you accept the review step.
Short answer
Internal testers are your team and skip Beta App Review; external testers are anyone but their builds need review first. Per Apple's TestFlight documentation, internal testing is for up to 100 members of your team who have an App Store Connect role, and builds are available to them immediately after processing with no Beta App Review. Per Apple's App Store Connect help, external testing supports up to 10,000 testers invited by email or a public link, and the first build of a version must pass Beta App Review before they can install it. Use internal for speed and external for reach.
What internal testers are
Internal testers are members of your own organization who you add to test builds through App Store Connect. To be an internal tester, a person must be a user in your App Store Connect account with a role that has access, such as Admin, App Manager, Developer, or Marketing, so internal testers are people already on your team rather than outside users. You add them by assigning existing App Store Connect users to internal testing, and each can install builds on their devices.
The defining advantage of internal testing is speed, because internal builds do not require Beta App Review. Once a build finishes processing, it is available to your internal testers right away, so your team can start testing without waiting for Apple to review the beta. This makes internal testing the natural choice for rapid iteration during development, where you want your own people trying each build quickly. Because internal testers are limited to your App Store Connect users, the group is small and trusted, which is exactly why Apple lets these builds skip the review gate.
What external testers are
External testers are people outside your App Store Connect team who you invite to test your app, and they can be anyone, not just organization members. You invite external testers by email, adding their addresses to a tester group, or by sharing a public link that lets people join the beta themselves, so external testing is how you reach real users, a wider audience, or the public for feedback before launch. External testers are organized into groups, which lets you manage who gets which builds.
The trade-off for that reach is Beta App Review. Before external testers can install the first build of a version, that build must pass Apple's Beta App Review, which checks the app against a subset of the guidelines to confirm it is functional and appropriate for testing. So external testing involves a review step that internal testing does not, and there is a wait for that review on a new version. This is the price of distributing to people outside your team, and it is why external testing suits a broader, later-stage beta rather than the earliest, fastest iteration.
Review requirements: the key difference
The review requirement is the most consequential difference between the two, and it comes down to internal testing skipping Beta App Review while external testing requires it. Internal builds are available immediately after processing, with no review, so there is no wait between a build finishing processing and your team testing it. This is what makes internal testing fast and why teams use it for quick cycles.
External builds are different: the first build of a given version must pass Beta App Review before external testers can install it, which adds a review wait on each new version. Subsequent builds of the same version often do not need another full review unless you make significant changes, so the review gate is mainly felt on the first external build of a version. Understanding this difference shapes how you plan: if you need testers on a build right now, internal testing delivers it, whereas external distribution means budgeting for the review before your outside testers can get it.
Number of users and devices
The two tiers also differ in scale, which is the other headline difference. Internal testing supports up to 100 testers, drawn from your App Store Connect users, and each internal tester can test on multiple devices. This is plenty for a team but not for a broad beta, so internal testing is capped at a size that matches its purpose of testing within your organization.
External testing scales far larger, supporting up to 10,000 testers, which is what makes it suitable for a real beta with many users. Those 10,000 can be invited individually by email or can join through a public link, so you can grow an external beta to a large audience without adding each person as an App Store Connect user. So the number of users is a clear decision point: if you need more than your team, up to a hundred people, external testing is the only option that reaches thousands, while internal testing keeps a small, trusted group.
How you invite each
The invitation methods reflect who each group is. For internal testers, you add existing App Store Connect users to internal testing, so the person must already have a role in your account, and once added they can access builds through the TestFlight app. There is no email invitation to an outside person for internal testing, because internal testers are by definition part of your team.
For external testers, you have two ways to invite. You can add testers by email address to a group, which sends them an invitation to join your beta, or you can enable a public link that anyone can use to join the external beta up to your tester limit. The public link is useful for open recruitment, while email invitations suit a curated group. Both feed into external tester groups, and both are subject to the Beta App Review requirement for the first build of a version, so the invite method does not change the review gate, only how people join.
Which to use when
Choosing between them follows from their strengths. Use internal testing when you want your own team to test quickly, especially during active development where you push frequent builds and cannot afford a review wait on each one. Its immediacy and its skipping of Beta App Review make it ideal for the fast, iterative phase, and its cap of a hundred team members is rarely a constraint for internal use.
Use external testing when you need feedback from real users or a larger audience, typically later in development as you approach launch, and when you can accept the Beta App Review step. Its scale of up to ten thousand testers and its email and public-link invitations make it the tool for a genuine beta program. Many teams use both in sequence: internal testing for rapid early iteration within the team, then external testing to validate with real users before release. So the decision is less either-or and more which phase you are in.
Internal versus external compared
Setting the two side by side makes the differences clear. The table below compares them.
| Aspect | Internal testers | External testers |
|---|---|---|
| Who they are | Team members with an App Store Connect role | Anyone you invite |
| Maximum number | Up to 100 | Up to 10,000 |
| Beta App Review | Not required | Required for the first build of a version |
| Build availability | Immediately after processing | After Beta App Review passes |
| How you invite | Assign an App Store Connect user | Email invitation or public link |
Read the table by your two questions: who and how many decides eligibility, and the review row decides how quickly testers get a build.
Choosing guide
Matching your need to the tester type keeps testing efficient. The table below maps common cases.
| Your need | Choose | Why |
|---|---|---|
| Fast team testing with no wait | Internal | No Beta App Review, immediate builds |
| A broad beta with real users | External | Reaches up to 10,000 via email or link |
| Frequent builds during development | Internal | Skip the review gate each cycle |
| Public or open recruitment | External | Share a public link to join |
Read the guide by your phase: internal for the fast, in-team iteration, external for the wider, later beta, and both in sequence when you need each.
Secure the build before either
Whichever tester group receives your build, it is a build going onto real devices, so confirming it is secure before you distribute is worthwhile regardless of who tests it. A beta build can carry the same security issues a release build can, and catching them before testers, or later reviewers, do is the productive step.
A scanner like PTKD.com analyzes your build and reports issues such as leaked keys and secrets, over-broad permissions, and insecure data handling by severity, mapped to OWASP MASVS, so the build you send to internal or external testers is checked. To be clear about the boundary: PTKD does not manage your testers, groups, or Beta App Review, which you handle in App Store Connect. It checks the build itself so the version your testers install is one you have verified.
What to take away
- Internal testers are up to 100 members of your team with an App Store Connect role, and they get builds immediately after processing with no Beta App Review.
- External testers are up to 10,000 people who can be anyone, invited by email or a public link, and their first build of a version must pass Beta App Review.
- The review requirement is the key difference: internal skips it for speed, while external requires it for the first build of each version, adding a wait.
- Internal is capped at 100 for team testing; external scales to 10,000 for a real beta, which is the other main decision point.
- Use internal for fast in-team iteration and external for a broader beta, often in sequence, and scan the build first with a tool like PTKD.com.
