Seeing a TestFlight build marked Expired is not a bug or a sign something went wrong with your app. It means the build hit its 90-day limit, which is built into how TestFlight works. Your testers lose access, and the only way forward is a new build. Here is why it happens and how to get your beta running again.
Short answer
A TestFlight build says Expired because builds are available to testers for only 90 days after upload, and Apple does not extend or reactivate them. Per Apple's TestFlight overview, a build becomes unavailable to testers after 90 days, so they can no longer install or open it. You can also expire a build manually when testing is finished. The fix is to upload a new build, which starts its own 90-day window, though the first build of a new version still needs Beta App Review before external testers can install it.
What you should know
- 90 days is the limit: a build is available to testers for up to 90 days from upload, then it expires.
- Expiry cannot be undone: Apple does not extend or reactivate an expired build.
- Testers lose access: an expired build is removed from the available list and cannot be installed or opened.
- You can expire a build yourself: the Stop testing option expires a build when you are done with it.
- The fix is a new build: upload a fresh build to resume testing, with its own 90-day clock.
Why does a TestFlight build expire?
Because TestFlight builds are time-limited by design. Apple makes each build available for up to 90 days from the day you upload it, after which it expires automatically and cannot be extended or reactivated by you or your testers. The intent is to keep beta testing on recent builds rather than letting an old one linger indefinitely. You can also reach the Expired state on purpose: when testing is complete, the Stop testing option expires a build so testers stop using it. Either way, Expired is a lifecycle state, not an error in your app.
What happens to testers when it expires?
The build disappears from their options. Once a build expires, it is removed from the available builds in the TestFlight app, and testers cannot install it or open it any longer; they have to move to a newer build to keep testing. The table sorts the common situations and what each one means.
| Situation | What it means | What to do |
|---|---|---|
| Build is older than 90 days | It expired automatically and testers lost access | Upload a new build |
| You chose Stop testing | You expired the build manually | Upload a new build to resume testing |
| Build was submitted to the App Store, not expired | Invited testers can keep testing it past 90 days | No action needed for those testers |
| You need testing beyond 90 days | TestFlight will not extend the window | Re-upload regularly, or use Ad Hoc or enterprise distribution |
There is one useful exception: if you submit the build to the App Store and do not expire it, testers who already received an invitation can keep testing that build even after it goes live, so App Store release effectively carries that specific build past the 90-day mark for them.
How do you fix an expired build?
Upload a new build. A fresh upload gets its own 90-day availability window, and your existing testers can install it as soon as it is ready. Increment the build number under the same version string to stay on the fast path, since later builds of an already-approved version usually skip a full review. If you raise the version string, the first build of that new version goes through Beta App Review before external testers can install it, which can take into the next day. So the quickest route back to testing is a new build of the same version, not a new version.
Can you avoid the surprise next time?
Yes, by treating the 90-day window as a schedule rather than a deadline you discover. The reliable habit is to upload builds regularly during an active beta, well before day 90, so a current build is always available and no tester ever hits an expired one. If you genuinely need a build to live longer than 90 days for testing, TestFlight is not the tool; Ad Hoc distribution or, for organizations, enterprise distribution can run installed builds beyond that window. For most teams, a steady cadence of new TestFlight builds is simpler than working around the limit.
What to watch out for
The first point of confusion is that the 90 days runs from each build's own upload date, not from today or from your latest version, so an older build can expire while a newer one is still fresh. The second is that the limit applies to both internal and external testers, so an expired build affects everyone. A new build to replace an expired one is also a natural checkpoint to confirm the binary is clean: a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS for issues like exposed keys, so each refresh ships a verified build rather than just a newer one. Expiry itself is a lifecycle rule, not a security event, so the scan is a separate, complementary check.
What to take away
- A TestFlight build expires 90 days after upload, and Apple does not extend or reactivate it.
- Once expired, testers cannot install or open the build and must move to a newer one.
- Fix it by uploading a new build, ideally a higher build number on the same version so it skips a full Beta App Review.
- Upload regularly to stay ahead of the 90-day window, and use each refresh to confirm the binary with a pre-submission scan such as PTKD.com.
