There is no trick that makes a single TestFlight build last longer than 90 days, because Apple expires each build 90 days after you upload it, by design, and an expired build cannot be extended or reactivated. So the honest way to keep testing past the limit is not to bypass it but to keep uploading fresh builds, which you can automate with Fastlane so a current build is always available. And if what you actually need is long-term distribution of an internal tool rather than beta testing, TestFlight is the wrong tool, and the right answer is a proper distribution channel such as Apple Business Manager custom apps, not a workaround. AltStore is a limited sideloading option that expires even sooner on a free account.
Short answer
You do not extend a TestFlight build; you replace it, or you move to the right distribution method. Per Apple, each TestFlight build is available for up to 90 days and then expires automatically, which cannot be reversed, because TestFlight is for testing recent builds. To keep a beta running, upload new builds before day 90, ideally automated: per Fastlane, you can script uploads and even expire previous builds. For genuine long-term internal distribution, use a channel built for it, such as Apple custom apps through Apple Business Manager, rather than trying to make TestFlight serve a purpose it was not designed for.
What the 90-day limit is
The 90-day limit is TestFlight's build expiration: every build you upload is available to testers for up to 90 days from the upload date, after which it expires and testers can no longer install or launch it. This is intentional on Apple's part, because TestFlight is meant for testing current builds rather than distributing one build indefinitely, so the expiry keeps beta testers on recent versions. It is not a bug or a quota you can raise.
Crucially, an expired build cannot be extended or brought back; there is no setting, request, or workaround that adds days to a build once it is uploaded, and no supported way to make one last beyond 90 days. So framing the goal as bypassing the limit for a single build is a dead end. The productive way to think about it is continuity of testing, keeping a non-expired build available at all times, which is a matter of your upload cadence rather than any trick applied to a build.
Keep testing: automate fresh builds with Fastlane
Because you cannot extend a build, the reliable way to keep a beta going indefinitely is to upload new builds regularly, well before the current one hits day 90, so a fresh build is always available to testers. Doing this by hand is easy to forget, which is exactly how betas lapse, so the practical answer is automation. Fastlane can build and upload to TestFlight for you, and its TestFlight action can also expire previous builds, so a scheduled pipeline keeps a current build live without manual steps.
So the setup that answers the Fastlane question is a continuous integration job that runs your build-and-upload lane on a schedule, for example weekly, using an App Store Connect API key for authentication so it runs unattended. Each run produces a fresh, non-expired build, and testers on the latest version keep working without interruption. This does not bypass the 90-day rule; it makes the rule irrelevant by ensuring the build testers use is never close to expiring, which is the legitimate and durable way to run a long-lived beta.
Is AltStore a bypass?
AltStore is a sideloading tool that installs apps signed with your own Apple ID rather than distributed through TestFlight, and people ask about it as a way around Apple's limits, but for the 90-day question it does not help and often makes things shorter. With a free Apple ID, apps sideloaded through AltStore are re-signed with a development certificate that expires in about seven days, so they must be refreshed weekly, which is a tighter constraint than TestFlight's 90 days, not a looser one. A paid developer account extends the signing period, but with device limits typical of ad hoc distribution.
So AltStore is best understood as a personal or very small-scale sideloading option, not a scalable way to distribute a corporate tool, and it does nothing to make a TestFlight build itself last longer. It also relies on a companion app and periodic refreshes on each device, which does not fit distributing to a team. For anything beyond a handful of your own devices, AltStore is the wrong tool, and the right answer for real distribution is a proper channel, covered next, rather than sideloading.
The right tool for long-term internal distribution
If your real need is distributing an internal app to your organization over the long term, rather than running a beta, TestFlight is simply the wrong tool, and trying to bypass its limit is solving the wrong problem. Apple provides distribution channels designed for this. Apple Business Manager custom apps let you distribute a private app to your organization through App Store Connect, where it installs and updates like a normal app without a 90-day expiry, which is usually the right answer for an internal corporate tool.
There are two other legitimate paths depending on your situation. Ad hoc distribution installs a build on a fixed set of devices you register, with a provisioning profile that lasts around a year, suitable for a known, limited group. The Apple Developer Enterprise Program allows in-house distribution to your own employees, but it has strict eligibility requirements and is only for internal apps, not public or client distribution. Choosing among these by your actual audience and scale is the correct move, rather than stretching TestFlight past its purpose.
Distribution options compared
Matching your need to the method that fits avoids fighting the wrong limit. The table below compares them.
| Method | Longevity | Best for |
|---|---|---|
| TestFlight | 90 days per build | Beta testing recent builds |
| Fastlane automated uploads | Continuous, fresh builds | Long-running betas without lapses |
| AltStore sideloading | About 7 days on a free account | A few of your own devices |
| Ad hoc distribution | About a year, fixed devices | A known, registered device group |
| Apple Business Manager custom apps | Ongoing, no build expiry | Long-term internal organization apps |
Read the last row as the usual answer for a corporate tool: a private custom app has no 90-day expiry because it is real distribution, not beta testing.
About avoiding Enterprise certificate costs
The reason this is often searched is a wish to avoid paying for an Apple Developer Enterprise Program membership for an internal tool, and it is worth being clear about that. The Enterprise Program is intended strictly for distributing apps to your own employees, has eligibility requirements, and using it outside those terms, or buying access to someone else's enterprise certificate, violates Apple's rules and risks the certificate being revoked, which would break every app signed with it.
The good news is that the Enterprise Program is frequently not the answer you need. For many internal apps, Apple Business Manager custom apps distribute privately to your organization through the standard App Store Connect account you already have, without the Enterprise Program, and without a 90-day expiry. So rather than looking for a way to bypass TestFlight or share an enterprise certificate, evaluate custom app distribution, which is both compliant and usually simpler than the paths people try to avoid paying for.
Setup checklist
Working through these steps gives you a durable answer instead of a workaround. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Define the need | Beta testing, or long-term distribution | [ ] |
| For betas, automate | Script builds and uploads with Fastlane | [ ] |
| Schedule uploads | Run the pipeline before day 90, e.g. weekly | [ ] |
| Skip AltStore for teams | Use it only for a few personal devices | [ ] |
| For internal tools | Use Apple Business Manager custom apps | [ ] |
| Stay compliant | Do not misuse or share enterprise certificates | [ ] |
The step teams skip most is defining the need, since a beta and a permanent internal tool call for completely different tools, and confusing them is what leads to fighting the 90-day limit.
Where a scan fits
Whichever channel you use, the build you distribute deserves a security check, and that is independent of how you get it onto devices.
A scanner like PTKD.com analyzes your app build for security issues such as exposed keys, over-broad permissions, and risky third-party code, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not distribute your app or manage TestFlight, custom apps, or certificates, which are your Apple channels. It reviews the same build regardless of whether you ship it through TestFlight, a custom app, or ad hoc, so moving to a longer-lived distribution method does not mean skipping the security review.
What to take away
- A single TestFlight build cannot last beyond 90 days, since Apple expires each build 90 days after upload and it cannot be extended or reactivated.
- To keep a beta running, upload fresh builds before day 90, and automate this with Fastlane so a current, non-expired build is always available.
- AltStore does not help, because a free Apple ID re-signs sideloaded apps that expire in about seven days, which is shorter than TestFlight, and it does not scale to a team.
- For long-term internal distribution, use a channel built for it, most often Apple Business Manager custom apps, which have no 90-day expiry, rather than bypassing TestFlight.
- Do not misuse or share an enterprise certificate, since it violates Apple's terms and can be revoked, and use a tool like PTKD.com to scan whatever build you distribute.
