A TestFlight build stops working after 90 days, and that clock is the same for every tester.

How long does Apple say a TestFlight build stays available?

Ninety days, and the sentence sits in the step about uploading. App Store Connect Help's TestFlight overview puts it in step 2, under uploading your build or assets: you can test a build for up to 90 days. Step 7, about stopping testing, closes the loop with your build becomes unavailable for testers after 90 days. One page, two sentences, one number.

The reference page on app build statuses gives that number a name. A build past the line carries the status Expired, described as a build that cannot be used for testing with TestFlight because it has passed its 90 day availability window. Expired sits in the red group on that page, next to Invalid Binary and Rejected, where red means you have something to do or the build is finished.

So the number everyone repeats is the right one. That is worth saying out loud, because in this corner of the documentation a widely repeated figure is usually a year out of date. Here the documentation agrees with the folklore. Apple states 90 days in three places as of 21 October 2026, and none of those places states a different figure for a platform, a build type or a kind of tester.

What Apple does not write down is the moment the counting starts. The sentence lives in the upload step, and the API field beside the expiration date is called uploadedDate, so the upload is the sensible reading. But none of the pages says in words that the 90 days runs from the upload rather than from the day TestFlight App Review approved the build for external testing. The pages read for this were the TestFlight overview, app build statuses, Add internal testers, Invite external testers, Delete testers from TestFlight and Stop testing a build. If the exact day matters to you, read it off the build rather than counting to it, and the last section says where.

Apple, App Store Connect Help, TestFlight overview, read 21 October 2026

Does the clock differ for internal and external testers?

No. Two separate Apple pages point at the same 90 days and neither carves out an exception for either audience.

The Add internal testers page states it directly, and states it twice in the same words: internal testers can download and test all builds for 90 days. The Invite external testers page is the interesting one, because it never gives a number at all. It covers the 10,000 tester cap, public links, tester criteria and TestFlight App Review, and says nothing about how long a build lasts. An absence there is not a second rule. The general sentence in the overview covers both audiences, and the build statuses table settles the argument.

That table has one column for internal testing and one for external testing, and it marks which statuses appear in each. Ready to Submit is marked for internal testing alone, because a build can go to your own team before any review. Waiting for Review and In Beta Review are marked for external testing alone. Expired is marked in both columns. Read that table in a browser rather than in copied text: the marks are small icons, and they vanish when the page is extracted, which makes the rows look blank.

Everything else about the two audiences does differ, which is probably where the idea of two clocks came from. An internal tester is one of up to 100 App Store Connect users with access to your content. External testers run up to 10,000 per app, and the first build you send to an external group needs a full TestFlight App Review, while later builds for the same version might not. If you are running the Android side in parallel, the nearest equivalents there are google play closed testing and the google play twelve testers rule, and neither of them works anything like Apple's 90 days.

Apple, App Store Connect Help, app build statuses, read 21 October 2026

What happens to your testers on day 90?

The build goes unavailable, and Apple describes the end state as something that happened to the build rather than to the person. An expired build cannot be used for testing with TestFlight. The App Store Connect API reference for a build's attributes says the same about its expired flag: an expired build is unavailable for testing. The page on stopping testing describes that effect when you trigger it yourself, because after you click Expire Build the build no longer allows internal and external testers to install it.

What none of those pages describes is the screen a tester sees, or whether a copy already sitting on a phone keeps launching. Apple documents the build, so do not promise your testers anything about their phone. Promise them a new build, which is the thing you control.

Two second-order effects matter more in practice than the headline date. The first is your tester limit. Deleting someone does not free their slot. Apple's page on deleting testers from TestFlight says deleted testers continue to count toward the tester limit until their build expires, whether manually or automatically. So if you are near 10,000 external testers and clearing out people who never opened the app, those slots come back when the builds age out.

The second is the version you actually shipped. Ship it to the App Store without expiring the beta first and, in Apple's words, testers who received an invitation to test will still be able to test your build even after it goes live on the App Store. The build statuses page repeats it under the Testing status. Your beta therefore runs alongside the public release until the window closes on its own, which is a good reason to expire a build on the day its version goes live.

Apple, App Store Connect Help, app build statuses, read 21 October 2026

Where do you read the real expiry date?

The App Store Connect API holds it exactly. A build resource carries expirationDate, documented as the date and time the build will auto-expire and no longer be available for testing. Beside it are uploadedDate, the date and time the build was uploaded, and a boolean called expired. Two separate date fields and a flag, which is what you want behind a release checklist that warns you a week before a beta goes dark. Apple does not publish the arithmetic between those two fields, so read the expiration date rather than adding 90 days to the upload.

In the interface, the warning Apple documents is a card. On a tester group's details page, the help tells you to check the insight cards at the top to see whether there are no compatible builds, whether the public link is full, or whether a build is about to expire. That is the only expiry warning described in the pages read for this article, and it lives on the group page rather than on the build list, which is why people miss it.

Ending a window early is a deliberate act with a role attached. Apple lists Account Holder, Admin or App Manager, and the path is short: Apps, your app, the TestFlight tab, Builds in the sidebar, the platform, the build, then Expire Build. Removing a build from one group is the softer action and has a different result. Apple notes that testers currently using the build will continue to have access until they switch builds or choose to stop testing your app.

One last framing point, if you are also shipping on Android. Apple gives you one beta pool with a 90 day fuse on each build. Google gives you named tracks that a release moves between, with their own rules and their own promotion path, and nothing in them expires on a clock like this. play console release tracks lays those out, and the two models are different enough that carrying habits from one to the other causes most of the confusion.