Testers report the beta won't open or install? This guide covers the 90-day expiration, invitation issues, device and OS mismatches, and how to get testers back into your build.
Testers tell you the beta will not open, shows as expired, or simply will not install. From your side everything looked fine, so the reports are confusing.
Sometimes the TestFlight app shows the build greyed out with an expired label. Other times a tester taps your invite or public link and gets stuck before install.
A third variation is that some testers succeed while others fail, which points to device or OS differences rather than a problem with the build itself.
Each of these has a clear cause and a clear fix. The first job is to narrow down which one your testers are actually hitting.
The most common reason a previously working beta stops opening is expiration. Every TestFlight build expires 90 days after it was uploaded.
Once a build expires, testers can no longer launch it. The TestFlight app will typically show the build as expired and offer no way to run it.
This is by design. Apple uses the expiration to keep testers off stale code and to encourage steady iteration.
The fix is straightforward: upload a fresh build. A new build resets the clock, and once you assign it to your testers, they can install and run it normally again.
If a tester cannot get in at all, the issue is often with the invitation rather than the build. Email invites can land in spam or be sent to an address the tester does not use on their device.
For public links, confirm the link is still enabled and has not hit its tester limit. A capped or disabled link will turn away new testers even though it looks valid.
Also confirm the tester has installed the free TestFlight app from the App Store first. Without it, the invite or link has nowhere to open.
If an email invite is the problem, you can resend it, double-check the address, or switch the tester to a public link, which sidesteps email delivery entirely.
When some testers succeed and others fail, the difference is usually their device or OS version. Your app declares a minimum iOS version, and devices below it cannot install.
TestFlight itself also requires a reasonably current OS. A tester on a very old iOS release may be unable to use the TestFlight app or your build.
Check your deployment target in Xcode against what your failing testers are running. A mismatch there explains a lot of install failures.
If you must support older devices, lower your deployment target and ship a new build. If not, communicate the minimum requirement clearly so testers on unsupported devices know why they cannot join.
Sometimes testers cannot install because the build was never actually made available to them. Uploading a build is not the same as assigning it to a tester group.
Confirm in the TestFlight tab that the intended build is assigned to the group your testers belong to. An unassigned build is invisible to them.
For external testers, also confirm the build has cleared Beta App Review. Until it is approved, external testers cannot install it even if the group is set up correctly.
This is a frequent source of "my testers can't see the new build" confusion. The build exists, it processed fine, but the final assignment or review step was missed.
Some install failures have nothing to do with your build or your settings and everything to do with the tester's device. A device that is low on storage cannot install a new beta until space is freed.
Flaky connectivity is another culprit. A download that stalls partway can leave the TestFlight app showing an error, and the fix is simply retrying on a stable connection.
Account mismatches also cause confusion. The tester needs to be signed into the App Store with an Apple Account, and the email you invited should match the one they actually use, or they may not see the invitation.
For public links these account issues are rarer, since the tester self-enrolls, but storage and connectivity still apply to everyone.
When a single tester is stuck and everyone else is fine, walk them through these basics before assuming the problem is on your end. Often a retry, a storage cleanup, or the right account is all it takes.
First, ask whether the build was working before and recently stopped. If yes, suspect expiration and upload a fresh build to reset the 90-day window.
If a specific tester cannot get in at all, check their invitation path: resend the email, verify the address, or move them to a public link, and confirm they have the TestFlight app installed.
If only some testers fail, compare their device and OS versions against your deployment target, and adjust or communicate the minimum as needed.
If no testers can see a new build, verify it is assigned to the right group and, for external testers, that it has passed Beta App Review.
Many install problems are really communication problems in disguise. A tester who does not know what to expect is far more likely to report a vague "it doesn't work."
Give testers a short, clear onboarding message. Tell them they need the free TestFlight app, what minimum iOS version your beta requires, and what to do if a build shows as expired.
When you push a new build to replace an expired one, let your testers know it is available. The TestFlight app can notify them, but a quick heads-up in your own channel removes any doubt.
Ask for specifics when something fails. The device model, the iOS version, and the exact message they see turn a confusing report into a diagnosable one.
Good communication does not just resolve issues faster; it prevents many of them, because testers who know the rules rarely hit the avoidable failures in the first place.
Keep a steady upload cadence so builds rarely approach the 90-day limit while still in active testing. Fresh builds keep testers unblocked automatically.
Prefer public links for open betas. They eliminate email-delivery failures and give testers a single reliable entry point.
Document your minimum OS and device requirements wherever you recruit testers. Clear expectations prevent a wave of install-failure reports from unsupported devices.
Finally, build a simple checklist for each release: upload, wait for processing, declare compliance, pass review if external, and assign to the correct group. Following it every time removes most of the install problems testers run into.
Every TestFlight build expires 90 days after upload. Once expired, testers can no longer launch it. Upload a fresh build and assign it to your testers to reset the window and restore access.
Check the email address, look in spam, and resend the invite. Alternatively, switch the tester to a public link, which avoids email delivery entirely. Confirm they have installed the free TestFlight app first.
This usually reflects device or OS differences. Your app's minimum iOS version, set by the deployment target, may exclude older devices. Compare failing testers' OS versions against your deployment target.
The build may not be assigned to their tester group, or for external testers it may not have cleared Beta App Review yet. Verify assignment and review status in the TestFlight tab.
Maintain a regular upload cadence so builds rarely approach 90 days while testing is active. Fresh builds reset the expiration and keep testers continuously unblocked.