TestFlight Beta Testing: The Complete Walkthrough

TestFlight is Apple’s official way to get your app onto real devices before it hits the App Store, and it’s free with your developer membership. You upload a build to App Store Connect, invite testers by email or a public link, and they install and update your beta through the TestFlight app. Up to 100 internal teammates can test within minutes of upload, and up to 10,000 external testers can join once your build clears a lightweight Beta App Review.

That’s the elevator pitch. The details (which review applies when, why your build says “processing” forever, what expires after 90 days) are where people get stuck, so let’s walk the whole thing end to end. We’ve shipped a lot of betas through this pipeline, and this is the walkthrough we wish existed the first time. It’s part of our App Store Connect series, so if you’re missing certificates or an app record, start with our pillar on App Store Connect from certificates to TestFlight first.

Internal vs external testing: know the difference

TestFlight has two tiers, and mixing them up is the number one source of confusion:

	Internal testing	External testing
Who	People on your App Store Connect team	Anyone with an invite or link
Limit	100 testers	10,000 testers
Review required	No, builds go live in minutes	Yes, Beta App Review for the first build of each version
Best for	Daily team builds, QA, stakeholders	Public betas, waitlists, real-world feedback
Devices per tester	Up to 30	Up to 30

Internal testers must hold a role on your team (Admin, App Manager, Developer, or Marketing). That 100-person cap is per app and includes everyone you’ve toggled on, so agencies juggling client seats need to be a little deliberate about it. External testers just need an Apple Account and the TestFlight app, nothing else.

Step 1: Upload a build

From Xcode: Product > Archive, then in the Organizer hit Distribute App and choose App Store Connect (TestFlight uses the same upload path as a release). If you’re on a CI setup, Xcode Cloud, Fastlane, or the notarytool-era altool replacements all land builds in the same place.

Before you archive, three things that save a rejection later:

• Bump the build number every upload. Same version string is fine, duplicate build numbers are not.
• Answer the export compliance question. You can pre-answer it in your Info.plist (ITSAppUsesNonExemptEncryption) so builds don’t sit in “Missing Compliance” limbo.
• Make sure your app icon and launch experience are real. Placeholder icons are a classic Beta App Review rejection.

After upload, the build shows as “Processing” in App Store Connect’s TestFlight tab. Usually that’s 5 to 30 minutes; occasionally an hour. If it’s been stuck for several hours, check your email, Apple often sends the actual problem (invalid entitlement, missing usage description) there rather than surfacing it in the UI.

Step 2: Add internal testers

In App Store Connect, open your app > TestFlight, create an internal group (or use the default), and toggle on team members. They get an email invite, tap it on their iPhone, and the build appears in the TestFlight app. Turn on “automatic distribution” for the group and every new build reaches them without any clicking on your side. This is the loop you’ll live in daily: archive, upload, testers get a push notification, done.

Step 3: External testing and Beta App Review

External testing is where TestFlight becomes a genuine public beta channel. Create an external group, attach a build, fill in the “What to Test” notes and beta app description, and submit. The first build of each version goes through Beta App Review, which is a lighter cousin of full App Review. In our experience it clears in under a day, often within a few hours. Subsequent builds of the same version usually skip straight through unless you’ve changed something meaningful (entitlements, encryption answers, the beta description).

Two ways to get external testers in:

• Email invites: add addresses individually or via CSV. Good for curated groups, because you can see who redeemed and remove people cleanly.
• Public link: one URL anyone can tap to join. You can cap how many people it accepts and disable it anytime. This is the one you post on your waitlist page, Discord, or social. Fair warning: a public link plus a popular Reddit post can eat hundreds of slots overnight, so set the cap.

Step 4: Collect feedback and crash reports

TestFlight’s feedback loop is genuinely good and weirdly underused:

• Screenshot feedback: testers take a screenshot in your beta, and iOS offers to send it to the developer with annotations and comments. It arrives in App Store Connect under Feedback, tied to the exact build and device.
• Crash feedback: when the beta crashes, TestFlight asks the tester if they want to share it with a comment. Crashes also flow into Xcode’s Organizer with full symbolicated stack traces, so you can jump straight to the offending line.
• Tester metrics: App Store Connect shows sessions, installs, and crash counts per build, handy for spotting “everyone installed build 42 and stopped opening the app” patterns.

One habit worth stealing: write real “What to Test” notes for every build (“try the new onboarding, we rewrote step 3”). Testers who know what changed send feedback that’s actually useful.

The 90-day rule and other limits to remember

• Every build expires 90 days after upload, full stop. Testers see “Expired” in TestFlight and the app stops launching. Ship a fresh build before that or your beta community goes dark.
• Up to 100 internal testers, 10,000 external testers, 30 devices per tester.
• You can test up to 100 apps at a time as a tester.
• Builds live in groups; one build can serve multiple groups, and you can stagger features by giving different groups different builds.

TestFlight for macOS (and beyond)

TestFlight isn’t iPhone-only. There’s a native TestFlight app for macOS (App Store distribution builds only, not Developer ID ones), and the same internal/external structure applies. If you’re shipping a Mac Catalyst or SwiftUI multiplatform app, you can beta both platforms from the same app record. TestFlight also covers iPadOS, watchOS, tvOS, and visionOS. The main practical difference we’ve noticed: Mac testers are rarer, so recruit deliberately if macOS quality matters to you.

Common Beta App Review rejection reasons

Beta review is lenient, but it’s not a rubber stamp. The ones we see most:

1. Crashes on launch. The reviewer opens the app once; if it dies, instant rejection. Test on a clean device first.
2. Placeholder content. Lorem ipsum screens, default icons, “test test test” copy.
3. Broken login with no demo account. If your app needs an account, provide working demo credentials in the review notes.
4. Missing compliance info. Unanswered encryption questions or missing privacy usage strings (camera, location) with vague explanations.
5. Beta description that doesn’t match the app, or promising features that aren’t in the build.
6. Payment funny business. Betas can’t charge real money for unfinished goods; keep IAPs in sandbox behavior.

Fix and resubmit; there’s no penalty for a beta rejection, just lost time.

Where TestFlight fits in your launch

A sane sequence looks like: build the app (our 5-step iOS development guide covers that arc), run internal testing for a few weeks, open an external beta to a few hundred users, then use what you learn to polish both the app and the listing. That last part matters more than people think: while your beta cooks, write an App Store description that converts, because beta feedback is a goldmine for the exact words users use to describe your app. And if you’re still earlier in the journey, the full Apple app development guide maps the whole road from idea to release.

FAQ

How long does Beta App Review take?

Typically a few hours to a day for the first build of a version. Later builds of the same version usually go straight to testers unless you changed entitlements, encryption answers, or the beta description. Full App Review for release is a separate, stricter process.

Do external testers need an invitation email?

No. A public link works with zero email collection; testers tap it, install TestFlight, and join. Email invites are better when you want a curated roster you can prune, and both can run at the same time.

What happens when a TestFlight build expires?

Ninety days after upload the build stops launching and shows as expired. Testers aren’t removed, they just need a newer build. Upload fresh builds on a schedule (we do at least monthly, even quiet months) so long-running betas never lapse.

Is TestFlight really free?

Yes. It’s included with the $99/year Apple Developer Program membership, with no per-tester or per-build charges, which makes 10,000 external testers one of the better deals in mobile development.