TestFlight beta review: what it actually checks
Passing TestFlight beta review is not a preview of App Review, and treating it as one costs people a release.
Internal testing with your own team needs no beta review. External testing does, and Beta App Review asks a narrower question: is this build suitable for testing. It is not evaluating your listing, your screenshots, your keywords, or every guideline that applies to a product on sale.
What still applies at TestFlight: the automated upload checks. Those run before any review at all, so a missing purpose string or a privacy manifest failure blocks a TestFlight build exactly as it blocks a submission. That is genuinely useful, because it means you discover the four upload blockers days or weeks before you planned to submit.
What TestFlight is actually for, and what people underuse it for: getting the build onto devices that are not yours, in the state a reviewer starts in. Fresh install, no account, no data, offline once, on an older device. Your own phone can never reproduce that, because it has your account, your data and your cache.
What each stage checks
| Stage | Checks | Blocks |
|---|---|---|
| Upload processing | Automated: purpose strings, privacy manifests, required-reason APIs, bundle validity | Everything, including TestFlight |
| Beta App Review | Suitability for external testing | External TestFlight distribution |
| App Review | The full guidelines, plus metadata and listing | Release |
The first row is the one worth exploiting. Push a build to TestFlight early in a release cycle and you learn about ITMS-90683, ITMS-91053, ITMS-91054/5/6 and ITMS-91061 at a point where fixing them costs nothing.
What beta review does not tell you
It does not tell you that your screenshots are acceptable, that your description avoids other-platform references, that your subscription disclosure is complete, that your account deletion flow exists, or that a reviewer will be able to reach the feature they need a demo account for.
Those are all decided later, by a different process, against a longer list. What reviewers actually test. · The first-submission checklist.
Using it properly
Get it onto other people's devices. This is the whole value and it is routinely wasted on colleagues who already have accounts.
Give testers the reviewer's script, not "have a play with it":
1. Install fresh. Do not restore anything.
2. Create a new account, or use the app without one if that is possible.
3. Do the main thing the app is for, once, from cold.
4. Turn airplane mode on. Use the app. Turn it off.
5. Force quit. Reopen. Tell me what state it came back in.
6. If your phone is more than two years old, tell me how it felt.Steps 1, 4 and 6 find most of it. A blank first screen on a fresh install is the single most common cause of a Guideline 2.1 rejection, and it is invisible to everyone on the team.
Watch what testers do, not what they say. "It was fine" from someone who never got past onboarding is the most misleading data available.
The RN and Expo specifics
Test the production build profile, not preview. Different environment variables, different API URL, different update channel. Verifying preview and shipping production means you verified a different app. The EAS submission checklist.
Test with over-the-air updates in their shipping configuration. A build that works because your machine served it a JavaScript bundle is not the build the reviewer gets.
Test an older device. React Native's cold start and memory profile on a five-year-old phone is a different experience, and reviewers do not always use the newest hardware.
What to do with the results
Fix what testers found, then run the full pre-submission pass rather than submitting on the strength of a clean beta. Beta review answered a smaller question, and the gap between the two questions is where the rejections live.
After a rejection. · Review notes that work. · What a rejection actually costs.
shipcheck runs the full-review checks against the project before you submit, rather than the narrower set TestFlight applied, and cites the guideline for each finding. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Does TestFlight require App Review?
Internal testing with members of your team does not require beta review. External testing, with testers outside your team or through a public link, requires Beta App Review, which is a separate and narrower process from full App Review.
Is passing TestFlight beta review a sign my app will be approved?
No, and treating it as one is a common and expensive mistake. Beta review checks whether the build is suitable for testing, not whether it meets every guideline for sale, and metadata, screenshots and several review items are not evaluated at all.
Do upload checks still apply to TestFlight builds?
Yes. The automated checks that reject an upload happen before either kind of review, so missing purpose strings and privacy manifest failures block a TestFlight build exactly as they block a submission.
How long does beta review take?
Apple does not guarantee a time, and in practice it is usually faster than full review. Plan the process, not the number.
Do I need beta review for every build?
The first external build of a version generally goes through it, and subsequent builds of the same version often do not. Changing what the app does is what tends to trigger it again.
What should external testers actually do?
The reviewer's run: fresh install, no account, no data, then offline, then a device that is not the newest. That is the state your build fails in, and it is the one your own device can never reproduce.
shipcheck. “TestFlight beta review: what it actually checks.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/guides/testflight-beta-review/