Why Your TestFlight Build Isn't Reaching Testers

TestFlight is a state machine with a published list of states, and "my build isn't reaching testers" is always a question about which state you are in — not a question about whether TestFlight is working. The moment you stop treating it as a black box and start reading the status label, the problem usually resolves in minutes.

Apple publishes the full list in its app build statuses reference. Twelve values exist. Five of them account for almost every support thread we have seen:

• Missing Compliance — export compliance documentation has not been supplied. Action is needed from you.
• Ready to Submit — the build can go to internal testers right now, and can be submitted to TestFlight App Review for external testing. It is not stuck; it is waiting for you.
• Waiting for Review / In Beta Review — submitted to TestFlight App Review, and approval is required before external testing can begin.
• Expired — the build has passed its ninety-day availability window and cannot be used for testing.
• Rejected — TestFlight App Review rejected the build, and it can no longer be used in TestFlight at all. You upload a new one.

Two more are worth recognising because they look like platform faults and are not. Invalid Binary means Apple received the upload but it failed the upload requirements. Not Available for Testing means the provisioning profile is missing an application identifier — a signing problem wearing a TestFlight costume.

Across the 300+ apps we have managed since 2013, the pattern is consistent: teams describe a state as a failure when it is a queue position or an unanswered form. Read the label first. It tells you whether the ball is in your court or Apple's, and those two situations call for completely different responses.

Because internal and external distribution are governed by different rules, and only external testing requires TestFlight App Review approval. This single asymmetry produces more confused founders than any other part of the system, because the first person to install a build is almost always a colleague — which makes the build look approved when it is not.

Apple states it plainly in the definition of the Ready to Submit status: the build "can be distributed to internal testers, or can be submitted to TestFlight App Review for external testing". Internal is immediate. External is gated. The status of a build that works perfectly for your team and reaches nobody outside it is doing exactly what it says.

The practical consequence is a planning one. If your launch plan says "upload Thursday, testers Friday", it is only true for the people already inside your App Store Connect account. Everyone else is downstream of a review queue whose duration you do not control. We build beta timelines around the approval, not the upload, and we treat the internal install as a smoke test rather than as evidence that distribution works.

The second consequence is about who you recruit. Because internal testers must be App Store Connect users with access to your content, you cannot quietly promote your fifty most engaged users into that bucket to skip review. The bucket is for your team. If you want strangers testing the app — which is the entire point of a beta — you are on the external path and you will be reviewed. Our note on finding your first 100 app users covers the recruitment side of this in detail.

It is asking whether your app uses encryption, so Apple can satisfy export regulations — and it blocks a build that is otherwise perfectly fine until you answer. It is a form, not a fault, and it is the single most common reason a freshly uploaded build sits there doing nothing.

Apple's guidance on providing export compliance information for beta builds tells you to specify encryption use for your build to avoid the beta being marked as Missing Compliance. You can answer the questions in App Store Connect for each build, or you can specify the encryption settings in the app's Info.plist in Xcode and stop being asked every time.

Do the second one. Answering a modal on every upload is a small tax that eventually gets paid at the worst moment — the Friday evening build, by the one person who does not know the answer. Setting it once in the project means every subsequent upload lands in a usable state without a human in the loop.

Two related statuses are the same story at a later stage. Waiting for Export Compliance Review and In Compliance Review both mean your documentation has been submitted and is being looked at, and Apple's reference explicitly says no action is needed on your end for either. Those are queues, not blocks.

Substantially the same guidelines as a store submission, with two extra rules that catch teams out: betas must be intended for public distribution, and they must never be distributed in exchange for compensation. A TestFlight rejection is not a lighter class of rejection — a rejected build "can no longer be used in TestFlight" at all.

Section 2.2 of the App Review Guidelines is short and worth reading in the original. It says demos, betas and trial versions do not belong on the App Store and that TestFlight should be used instead; that any app submitted for beta distribution should be intended for public distribution and should comply with the App Review Guidelines; that apps using TestFlight cannot be distributed to testers in exchange for compensation of any kind, including as a reward for crowd-sourced funding; and that significant updates to your beta build should be submitted to TestFlight App Review before being distributed to your testers.

Read that last clause again, because it is the one that quietly invalidates a common workflow. Teams learn that "later builds for the same version might not" need a full review and conclude they can ship material changes to external testers indefinitely without review. The guideline says the opposite for significant updates. In our portfolio, the safe reading is: cosmetic and bug-fix builds ride the existing approval, and anything that adds a feature, changes onboarding or alters what a reviewer would have seen goes back through review deliberately.

The compensation rule is the one that ends campaigns. Paying testers, offering credits, or bundling beta access as a crowdfunding reward all fall on the wrong side of it. If you were planning to buy your way to beta feedback, the budget is better spent on the acquisition side of launch — our user acquisition service exists for exactly that, and it does not put your beta at risk.

Supply the test information properly too. Apple's page on providing test information states that the Beta App Description field is required, and that distributing to external testers means entering additional TestFlight test information for review. Thin, placeholder test information is a slow way to fail.

Because ninety days is the hard ceiling on a TestFlight build's life, and the expiry is silent from the tester's point of view. Apple's TestFlight documentation states that your build becomes unavailable for testers after 90 days, and the Expired status says the build cannot be used for testing because it has passed its ninety-day availability window.

For a two-week beta this never matters. For the two situations where it does matter, it matters a great deal.

• The long private beta. A closed group testing an app over a quarter will hit expiry mid-cycle, and the symptom is testers reporting that the app "stopped working" or disappeared, not an alert to you.
• The dormant build. A build kept around as a fallback or a reference is not a fallback after ninety days. If your rollback plan depends on an old TestFlight build, it has an expiry date you did not write down.

The fix is process, not configuration. Ship a fresh build on a cadence shorter than the window — we treat six weeks as the outer limit for any beta expected to run long — and put the expiry date of the oldest active build somewhere a human will see it. App Store Connect surfaces this: its group details page carries insight cards that flag when there are no compatible builds, when a public link is full, or when a build is about to expire. Those cards are the closest thing to a warning you will get, and they only help if somebody looks at the page.

Because apps installed from TestFlight run against the sandbox, and sandbox subscriptions renew on a compressed clock that bears no relationship to your real billing periods. Nothing about your paywall is broken. You are watching a testing environment behave as designed, and the numbers it produces cannot be read as revenue signals.

Apple's guidance on testing subscriptions and in-app purchases in TestFlight sets out the acceleration precisely: subscriptions renew every 24 hours, up to 6 times within a one-week period, regardless of the subscription's actual duration. A one-week plan, a one-month plan and an annual plan all behave identically — six daily renewals, then auto-renewal switches off.

Two things follow, and both have burned teams in our portfolio.

One practical trap: testers must sign in with a Sandbox Apple Account in Developer settings after signing out of their production account under Media & Purchases, and a sandbox account can only be used to test apps within your own developer account. External testers will not do this correctly without written instructions. If purchase testing matters to your beta, write the steps out and send them with the invite. If it does not, tell testers to skip the paywall entirely so you are not fielding confused reports about charges that never happened. Our monetisation work starts from the assumption that the paywall is instrumented and tested before launch, not after.

Up to 100 internal testers and up to 10,000 external testers per app, with a public link you can cap anywhere between 1 and 10,000. The ceilings are generous enough that they are almost never the real constraint — recruitment is.

Apple's TestFlight overview sets the internal ceiling at 100 App Store Connect users with access to your content, and the external ceiling at 10,000 people. On the external side, App Store Connect lets you set a tester limit on a public link — a number between 1 and 10,000 — which is a genuinely useful control that most teams never touch.

Use it. An uncapped public link posted anywhere public is an invitation to fill your beta with people who will install once and never open the app again, and that noise is expensive in two ways: it dilutes your feedback, and it makes your crash and session metrics unreadable. A capped link is a way to run a beta in waves — 200 testers, fix what they find, another 500, fix again — rather than one undifferentiated flood.

The number that actually matters is not the ceiling but the active tester count. We have seen betas with 3,000 accepted invitations and forty people who opened the app twice. TestFlight reports installs, sessions over the last seven days, crashes and feedback submissions per build; those four numbers tell you whether you have a beta or a mailing list. If sessions are flat while invites climb, the recruitment channel is wrong, and no ceiling increase will fix it.

For how this fits a launch plan more broadly, our guides to soft launch strategy and publishing your first app cover the sequencing either side of the beta.

Front-load everything that requires a human answer, and treat the review queue as the only unpredictable step. Almost all TestFlight distress is caused by discovering a form, a missing credential or an expiry in the same hour you intended to distribute.

The step teams skip is the fourth one, and it is the one that costs days. In our portfolio the highest-leverage habit is keeping a permanent reviewer account — a real account, kept working, with its credentials stored where the person doing the submission can find them at 7pm. It costs nothing and it removes an entire category of rejection.

The expensive mistakes are all planning mistakes, not technical ones — they cost days rather than minutes, and none of them produce an error message. The technical states on this page each have a named fix and a short path to resolution. These do not.

There is a sixth that belongs in neither column because it is a measurement failure rather than a distribution one: running a beta without deciding in advance what would make it a success. A beta that produces crash-free sessions and no opinions has told you the app does not crash, which you could have learned from ten internal testers. If the goal is to learn whether the product works for people who do not know you, the recruitment, the questions and the instrumentation all have to be designed before the invite goes out.

That is the part we do with clients before a launch, alongside the store listing itself — see our ASO work and the outcomes we have published. If you want a second pair of eyes on a launch plan before the build goes up, tell us what you are shipping.