TestFlight Internal vs External Testing: A Practical Guide

TestFlight has two kinds of testers, and mixing them up is how a “quick beta” turns into a day of waiting. Internal testing is for up to 100 people on your App Store Connect team and needs no review. External testing reaches up to 10,000 people by email or public link, but the first build you send them goes through TestFlight App Review. Either way, a build can only be tested for 90 days.

Everything below comes from Apple’s TestFlight overview, the external testers help page, and the TestFlight developer page, as of October 2026. If you’re working toward a full App Store launch, our App Store submission checklist tracks the TestFlight steps alongside everything else.

Internal vs external at a glance

	Internal testers	External testers
Who	App Store Connect users on your team	People who aren’t App Store Connect users
Limit	Up to 100	Up to 10,000 per app
Required role	Account Holder, Admin, App Manager, Developer, or Marketing	None, they aren’t App Store Connect users
How they join	You add them to an internal group	Email invite, CSV import, or public link
Review	None	First build goes to TestFlight App Review
Test information	Not needed	Beta App Description, feedback email, review contact
Internal Only builds	Allowed	Not allowed
Build lifetime	90 days	90 days

Apple’s TestFlight page adds two limits that apply to testers generally: each tester can use your betas on up to 30 devices, and you can share up to 100 builds. You’ll sometimes see “100 devices” quoted for internal testers. Apple’s current figure is 30.

Internal testing: the fast lane

Internal testers are people who already have an App Store Connect account on your team. Per Apple’s internal testers page, you create a group under Internal Testing in the TestFlight tab, add up to 100 users, and they get an email as soon as there’s a build to test. If someone you want isn’t in the list, give them a role in Users and Access first.

Tick Enable automatic distribution on the group and every new build from Xcode lands on their devices without you touching App Store Connect. Xcode Cloud builds are the exception: Apple says you always have to add those to groups manually.

There’s no review step. Once a build finishes processing and shows Ready to Submit, Apple’s build status reference says it “can be distributed to internal testers.”

One upload option to know about: if you export a build from Xcode as TestFlight Internal Only, it’s marked internal and can only go to internal groups. You can’t submit it for external testing or to the App Store. That’s handy for debug-flavored builds, and confusing if you picked it by accident and then wonder why the external group won’t accept it.

External testing: the wider beta

External testers are everyone else: friends, customers, a Discord server. They install the free TestFlight app and accept your invite. You can bring them in three ways:

Email, by adding each tester’s address
CSV import of names and emails
Public link, which anyone can open

Apple attaches a few rules you only discover by hitting them:

You need an internal group first. Apple says “to create an external group for external testing, you must first create an internal group.”
Builds go into a group one at a time, and you write a What to Test note for each one.
Only one build of each version can be in review at a time, and you can submit up to six builds for TestFlight App Review in a 24-hour period.
Managed Apple Accounts from reserved domains (Apple School Manager, Apple Business) can’t be used to test.

TestFlight App Review

Apple’s wording: “The first build you submit requires a full review, but later builds for the same version might not.” Note the “might.” Apple doesn’t promise that build 2 skips review, and it doesn’t publish a review time for TestFlight. Plan for the first external build of each new version to wait a bit.

The review covers the build and its metadata against the App Review Guidelines. A beta that crashes on launch or hides everything behind a login with no demo account can be rejected just like an App Store submission. Our guide to common App Store rejections covers the usual causes, and the demo-account advice there applies here too.

A rejected build is done. Apple’s status reference says it “can no longer be used in TestFlight,” so you fix the problem and upload a new build. Rejection details show up under App Review in the sidebar, and Apple says you can appeal by contacting TestFlight App Review.

Test information

Before external testers can see anything, fill in TestFlight > Test Information. Apple’s test information page marks the Beta App Description as required. The Feedback Email is where testers reach you from the TestFlight app. It’s also the reply-to address on invitation emails.

The form also has fields for a marketing URL and a privacy policy URL, plus beta review details: a contact name, email and phone, whether sign-in is required, demo account credentials, and notes for the reviewer. Apple’s help pages don’t spell out which of the URL fields are mandatory. Filling in the privacy policy URL costs nothing, though, and you’ll need one for the App Store anyway. If you don’t have one, our app privacy policy generator writes one you can host.

By default the invite also shows your approved App Store screenshots and app category. You can turn that off with the App Information checkbox under Invitation Experience.

Step by step: your first external build

Set the encryption key before you archive. Add ITSAppUsesNonExemptEncryption to Info.plist (details in the snags section below). This one line prevents the most common TestFlight stall.
Archive and upload. In Xcode, Product > Archive, then Distribute App. Don’t choose TestFlight Internal Only if you want external testers. Apple also supports Transporter, altool, and Xcode Cloud.
Wait for processing. Apple says the build “needs to be processed in Apple’s system before it appears in App Store Connect” and that you’ll get an email when it’s done. Apple gives no time estimate.
Create an internal group if you don’t have one, and test the build there first. Catching a crash now saves a review cycle.
Fill in Test Information: the beta description, the feedback email, and the review contact and demo account if your app needs a login.
Create an external group. In the TestFlight tab, click + next to External Testing and name it.
Add the build to the group and write the What to Test note. Decide whether to tick Automatically notify testers. If you leave it off, you’ll have to click Notify Testers yourself after approval.
Submit for review. The build moves through Waiting for Review and In Beta Review. Apple emails users with the Admin role when it’s approved.
Invite testers by email, CSV, or public link. Once testers are notified, the build’s status changes to Testing.

Public links: options and caveats

Open your external group, go to the Testers tab, and click Create Public Link. You get two choices:

Open to Anyone. Anyone with the link can join.
Filter by Criteria. Limit who can join by device and OS version: a version range, newer than or equal to, older than or equal to, or all supported versions for a platform. Add at least one criterion.

Either way, you can Set Limit to cap how many people join through the link, anywhere from 1 to 10,000. You can change criteria or the limit later with Manage, and you can deactivate the link at any time. Apple’s TestFlight page suggests disabling it once you’re full so people know the beta is closed.

Three things to keep in mind:

Links travel. Apple warns that “anyone can share this link.” Treat a public link like a public post.
Public-link testers are anonymous. Their names and emails don’t appear in App Store Connect, only installation dates, sessions, and crashes. If you need to know who said what, invite by email instead.
Criteria must match your builds. Apple says builds you add to the group must be compatible with the criteria you set. A filter for an OS version your build doesn’t support means nobody can install.

For in-person recruiting, a QR code beats reading out a URL. Paste the public link into our QR code generator: it renders as you type, lets you set the size (128 to 512 px), error correction level and colors, and downloads a PNG. It runs entirely in your browser. Print it on a flyer or put it on a slide, and people can scan it with the iPhone camera.

Feedback, screenshots, and crashes

Testers on TestFlight 2.3 or later can send feedback from the TestFlight app, or take a screenshot inside your beta and annotate it. It shows up in App Store Connect under TestFlight > Feedback, split into Screenshots and Crashes. When the app crashes, testers can add a note about what they were doing. Apple says crash reports stay downloadable for 120 days.

Testers on tvOS, or on older iOS versions that can’t send in-app feedback, are pointed to your feedback email instead. That’s another reason to use an inbox someone actually reads.

Common snags

”Missing Compliance”

This is the classic. Your build has processed, but it shows a Missing Compliance status instead of Ready to Submit. Apple’s build status reference describes it as “missing export compliance documentation. Action is needed.”

The quick fix: in the TestFlight tab, click Manage next to the build (or open the build and click Provide Export Compliance Information) and answer the encryption questions. Apple’s beta export compliance page walks through it.

The permanent fix: declare it in Info.plist so the questions never come up again. Apple’s encryption export documentation says to set ITSAppUsesNonExemptEncryption to NO if your app, “including any third-party libraries it links against,” doesn’t use encryption or only uses exempt encryption. Otherwise, set it to YES.

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Apple says the encryption built into the OS, “for example, when your app makes HTTPS connections using URLSession,” is typically exempt, while proprietary encryption isn’t. If you do need documentation, upload it in App Store Connect. After approving it, Apple gives you a code to put in the ITSEncryptionExportComplianceCode key. Apple also notes that some apps using exempt encryption may still owe the U.S. government a year-end self-classification report. Read Apple’s page if your app ships its own crypto.

Build stuck in processing, or missing entirely

The build only shows up in App Store Connect once processing finishes, and Apple doesn’t publish a time. If it shows Invalid Binary instead, that means the upload failed a requirement and you need a fixed build. A build marked Not Available for Testing is missing an application identifier in its provisioning profile, which Apple says requires a new upload.

External group won’t take the build

Usually it was uploaded as TestFlight Internal Only. Re-archive and distribute it normally.

Testers say the build vanished

Builds expire when their 90-day testing window ends (Apple’s status page calls it a “90-day availability window”). Upload a new one and add it to the group. Apple’s insight cards at the top of a group’s page warn when a build is about to expire, when the public link is full, or when no build is compatible with the link’s criteria.

Testers still have the beta after launch

Apple says that if you don’t expire a build, testers who were invited can keep testing it “even after it goes live on the App Store.” Expire old builds once you ship if you don’t want people on the beta.

What about Google Play?

Android has a close equivalent: internal, closed, and open testing tracks in Play Console. The big difference is that for new personal developer accounts, closed testing is required before you can launch. Our guide to Google Play’s 12 testers, 14 days rule covers that in full. On iOS, TestFlight is optional: a processed build at Ready to Submit can go straight to App Review.

Where TestFlight fits in your launch

TestFlight is the cheapest place to find the crash, broken login, or dead link that would otherwise get your App Store submission rejected. A sensible order: internal testing on every build, one external round with real users before 1.0, then submission. The App Store submission checklist has upload, internal testing, and the optional external beta as their own steps, along with the export compliance key, so nothing gets skipped when you’re rushing to ship.