What gets a TestFlight beta rejected

Internal testing skips review. External testing does not. What Beta App Review actually checks, the builds Apple will not accept at all, and how to keep a beta out of the queue.

September 2, 2026 · 6 min read

People are often surprised that a TestFlight build can be rejected at all. It can — but only on one of the two paths, and knowing which is which saves days.

Internal and external are different products

• ·Internal testing — up to 100 members of your own team, added by Apple ID. No review. A build is testable minutes after processing finishes.
• ·External testing — up to 10,000 testers, anyone with an email address or a public link. Beta App Review applies before the first build of a version reaches them.

So the fastest loop by a wide margin is internal: add yourself as an internal tester and every build lands on your phone without a queue. Use external testing when you actually need strangers, not before.

What Beta App Review actually checks

It is lighter than App Store review but it is the same guidelines, applied to obvious problems. In practice, the rejections cluster:

• ·It crashes on launch. The single most common one, and it is usually environmental — a missing API key, a debug-only server, a first-run path nobody tried on a clean install.
• ·It is visibly unfinished. Placeholder screens, dead buttons, lorem ipsum. Guideline 4.2 applies to betas too.
• ·Missing sign-in credentials.If the app has a login and you did not provide a demo account, review cannot get in, and “we could not review it” is a rejection.
• ·Missing permission usage strings. An empty NSCameraUsageDescription is an automatic bounce anywhere it appears.
• ·Content problems. Anything that would fail the store fails here too.

The builds Apple will not accept at all

Two hard rules that produce confusing failures because they happen before review, not during it:

• ·Builds made with a beta Xcode or beta SDK cannot go to external testers. They work for internal testing, which is exactly why this catches people — the internal build worked, so the toolchain looks fine.
• ·Builds expire after 90 days. An expired build is not testable and cannot be revived; upload a new one.

Keeping the queue short

Beta review is per version, not per build. Once a version is approved for external testing, subsequent builds of that same version go out without waiting. This is the single most useful fact about TestFlight scheduling: get version 1.2 approved once, then iterate on 1.2 (1), 1.2 (2), 1.2 (3) freely. Bumping the marketing version starts a new review.

Turnaround is usually within a day, sometimes hours, and it is slower when a queue backs up around OS releases in September. Plan the first external build of a version away from those weeks if you can.

What testers send back

TestFlight collects screenshot feedback and crash reports, and both are readable through the App Store Connect API — which means they can reach your agent instead of your inbox. That is the part worth wiring up: a crash from a tester becomes a fix and a new build without anyone transcribing a stack trace. See give your coding agent TestFlight.

Before the first external build

• ·Install from TestFlight on a device with no development history and launch it cold.
• ·Fill in the test information: what to test, and a demo account if there is a login.
• ·Check every permission prompt has a specific usage string.
• ·Confirm the build came from a release Xcode, not a beta.
• ·Ship the version once; iterate on builds within it.

And when you are ready for the real thing, the store bar is higher — why App Review rejects AI-built apps covers what changes.