TestFlight is the distribution channel every iOS release passes through before it reaches the App Store: it puts a build in the hands of real testers, on real devices, without publishing anything to the public. In 2026 the mechanics are stable and fully documented — up to 100 internal testers who can install each build the moment it finishes processing, up to 10,000 external testers who require the first build of the app to be reviewed against the App Review Guidelines, and a hard 90-day window after which a build becomes unavailable to everyone. Tutorials go wrong when they treat TestFlight as file sharing; it is a testing environment that happens to live inside App Store Connect, with its own review gate, its own required information, and its own expiry clock.

This tutorial follows the order Apple documents in App Store Connect Help: provide test information, upload the build and clear export compliance, invite internal testers, invite external testers, pass the review, distribute invitations, collect feedback — and, finally, stop testing deliberately instead of letting the 90-day clock do it for you. Every limit and every step below comes from Apple's own TestFlight documentation, and the numbers are quoted rather than paraphrased.

1. What TestFlight is — and what it is not

TestFlight distributes beta builds of your app, manages beta testers and collects their feedback. Testers install the free TestFlight app on iPhone, iPad, Mac, Apple TV, Apple Vision Pro or Apple Watch, accept an invitation, and then receive the builds you assign to their group. Apple states the goal plainly: keep improving the app and distributing builds until the issues are resolved, then submit it for review.

What it is not: a way to ship a finished product outside the App Store. Beta builds are still subject to the App Review Guidelines, the first build your app receives in a group is reviewed, and an app that exists only as a TestFlight build is not a distribution channel. The mental model that keeps teams out of trouble is simple — TestFlight is a rehearsal room with a doorman, not a side door.

2. Prerequisites — the account, the app record and the build

3. Step 1 — Provide the test information (required, not cosmetic)

Before anyone can be invited, App Store Connect wants the beta information that testers and reviewers will actually read.

Test information can be updated at any time and the changes appear in the TestFlight app. Fill it in properly before the first external review: a thin description is one of the few self-inflicted causes of a slow, confused review.

4. Step 2 — Upload the build and clear export compliance

Upload the build to App Store Connect — Xcode, Transporter, or your CI pipeline — and wait for processing. Uploading and processing are distinct states, and inviting testers to a build that has not finished processing simply does not work.

Then deal with encryption, the step that quietly blocks more first-time TestFlight users than any other. Apple asks, per build, whether your app uses encryption and how. There are three documented ways to answer:

  1. Answer the required questions per build, using Manage beside that build in the TestFlight section.
  2. Upload previously approved app encryption documentation, or follow Go to App Encryption Page, enter the key value Apple provides into Xcode, and stop answering the questions for that app.
  3. Declare in the app's Info.plist that the app does not use encryption, or is exempt from documentation — Apple's stated purpose for the setting is precisely to remove the per-submission question.

A build that sits in review with no reviewer assigned is very often a build waiting on export compliance. Check the build's encryption status before opening a support case.

5. Step 3 — Internal testing: up to 100 testers, no review, live in minutes

Internal testing is the fastest loop in the entire release chain, and the only one with no review gate.

  1. In App Store Connect, open the app and select the TestFlight tab.
  2. In the sidebar, under Internal Testing, create or select a group.
  3. Add up to 100 internal testers — App Store Connect users with access to your content — and click Add.
  4. Assign the build to the group. Testers receive an email invitation and accept it in the TestFlight app, or with the redemption code in the invitation.

Apple's wording on the clock is worth reading twice: internal testers can download and test all builds for 90 days. Note also what removal means: if you remove a build from a group, testers already using it keep access until they switch builds or stop testing. "Removed" is not the same as "revoked".

6. Step 4 — External testing: up to 10,000 testers and the first-build review

External testing is where TestFlight meets App Review. You can invite up to 10,000 external testers per app, from outside your organisation. The trade is a gate:

External review is lighter than App Store review, but it is not a bypass: the same guidelines apply, and a beta build is the wrong place to test whether a policy problem will be tolerated.

7. Step 5 — Invitations: email, redemption codes and public links

Testers install the free TestFlight app first, then accept.

Two practical rules: never park a public link somewhere permanent, because it is a testing channel rather than a download page; and plan the invitation together with the review, because a link pointing at an unreviewed build does nothing at all.

8. Step 6 — Feedback, metrics, and stopping testing on purpose

9. The 90-day clock: how build expiry drives your upload calendar

Every TestFlight build is testable for up to 90 days, after which it becomes unavailable to testers. That single number decides real scheduling questions:

Practical rule: treat day 75 as a deadline. If the release date sits beyond it, upload the next beta build early — the failure mode, testers opening TestFlight to an expired build, is invisible until it is embarrassing.

10. The rules that matter for a beta build

TestFlight is a testing environment inside Apple's ecosystem, and it is governed like one:

11. Where KappS fits in

TestFlight sits at the front of the release chain, which is why an avoidable mistake there is expensive: the developer account, the app record, the signing assets, the tax and banking profile and the submission all have to line up before a build can be tested, let alone published. KappS helps developers prepare and submit compliant material across that chain — checking that the account, the app and the build describe the same real publisher, and fixing the mismatches before a reviewer, or a 90-day clock, finds them.

What we do not do is manufacture a test channel out of someone else's account, or use TestFlight to route around App Review. A beta programme is only as trustworthy as the account behind it, and that account has to be yours.

Sources (Apple official documentation): App Store Connect Help — TestFlight overview; Provide test information; Add internal testers; Invite external testers; Provide export compliance information for beta builds; Stop testing a build; App Review Guidelines. (developer.apple.com)