External builds need Beta App Review, and it can get rejected or stall. Here's how to diagnose common rejection reasons, complete required information, and get your beta approved.
You assigned a build to external testers, but instead of going live it sits in Waiting for Review, or it comes back Rejected.
Internal testing worked fine, which makes this especially confusing. The difference is that external distribution requires Apple's Beta App Review, and internal testing does not.
A rejection usually arrives with a message from App Review explaining the problem. A stalled review, by contrast, may just sit without feedback for a while.
Both situations are common and resolvable. The path forward depends on whether you have an explicit rejection reason or simply a slow review.
Apple reviews external TestFlight builds to keep clearly broken or non-compliant apps from reaching large tester audiences. It is a lighter-touch process than full App Store review, but it is a real gate.
Internal testers, being members of your team, are trusted, so their builds skip this step. The moment you go external, the review applies.
Understanding this distinction reframes the problem. You are not fighting a bug in TestFlight; you are passing a review that has rules.
Knowing the rules up front is the best defense. Most rejections trace back to a handful of avoidable issues that you can address before you ever submit.
A frequent rejection or delay cause is missing or vague test information. Apple wants to know what your beta does and how to exercise it.
If your app has login-gated features, you must provide working demo credentials. A reviewer who cannot get past a login screen cannot evaluate the build.
Fill in the What to Test notes with concrete guidance. Generic or empty notes give the reviewer little to work with and invite a bounce.
Provide a valid contact email and any setup steps a reviewer needs. Complete, honest test information is the single most effective way to smooth the review.
A build that crashes on launch or has obviously broken core functionality will be rejected. Beta review still expects the app to actually run.
Before submitting externally, test the exact build on a real device yourself. Catching a launch crash internally saves you a rejection cycle.
Pay attention to first-run behavior. Reviewers experience your app fresh, with no prior state, so onboarding and permission prompts must work cleanly.
If you fix a crash, remember you will upload a new build with an incremented number and resubmit. The rejected build cannot simply be re-reviewed as-is once you change the code.
Beta builds still need to broadly respect App Store guidelines. Content, functionality, or behavior that would fail full review can also fail beta review.
Metadata matters too. A misleading description, placeholder text, or a beta that does not match what you describe can trigger a rejection.
If your app uses sensitive permissions, make sure your usage descriptions are clear and that the feature requesting them actually works. Reviewers notice permission prompts that lead nowhere.
When a rejection cites a specific guideline, read it carefully. The citation tells you exactly what to change, and addressing it directly is far faster than guessing.
Sometimes the build is fine and the review is simply slow. Review times vary, and there is no fixed guaranteed turnaround.
Resist the urge to cancel and resubmit repeatedly. Churning submissions can reset your place and slow things further rather than speeding them up.
Check Apple's system status for any review-related disruptions. Broad delays are occasionally platform-wide rather than specific to your app.
If a review is stuck for an unusually long time with no movement, you can contact Apple Developer Support or use the resolution center to ask about status. Use that as a measured step, not a first reaction.
Reviewers pay close attention to anything that requests access or blocks the core experience. If your app asks for sensitive permissions, the usage description strings in your Info.plist must clearly explain why.
A permission prompt that appears with no clear reason, or that leads to a feature that does not work, is an easy reason for a bounce. Make sure every prompt is justified and every gated feature behaves.
Account creation deserves the same care. If your app requires sign-up, provide a working demo account so the reviewer never has to create one, and make sure that account reaches the same functionality a real user would.
Third-party logins can be a sticking point too. If a reviewer cannot complete a social or external login, supply an alternative demo path or credentials in your test notes.
The theme across all of these is access: give the reviewer a clear, working path into the parts of your app you want evaluated, and most of these stalls disappear.
If you have a rejection message, read it and identify the cited reason, whether that is test info, a crash, or a guideline issue.
For incomplete information, add demo credentials, clear What to Test notes, and a valid contact, then resubmit.
For a crash or broken build, fix the code, upload a new build with an incremented number, and submit that fresh build for review.
If there is no rejection and the review is just slow, wait a reasonable interval, check system status, and only then reach out through support or the resolution center.
When a rejection arrives, the message itself is your most valuable resource. Apple typically tells you which area failed and, when relevant, which guideline applies.
Resist the urge to immediately re-submit the same build hoping for a different reviewer. Address the cited issue first, because the same problem will usually be flagged again.
If the message is unclear, you can reply through the resolution center in App Store Connect to ask for clarification. A focused question about the specific concern tends to get a more useful answer than a general complaint.
Match your fix to the cause. A test-information or metadata problem can be corrected without new code, while a crash or guideline violation means changing the app and uploading a fresh build with an incremented number.
Treating the rejection as concrete feedback, rather than an obstacle, gets you to approval far faster than guessing or resubmitting blindly.
Build a pre-submission checklist. Confirm the build launches on a real device, demo credentials work, test notes are filled in, and required permissions function.
Keep your first external submission for a new app clean and simple. The first review tends to be the most scrutinized, so put your best, most stable build forward.
Reuse approved test information across builds where it still applies, but update it whenever your features change so it never misleads a reviewer.
Finally, treat beta review as a normal part of the schedule, not a surprise. Building in time for it means a slow or bounced review never blocks a launch you assumed was already locked in.
External TestFlight builds go through Apple's Beta App Review to keep broken or non-compliant apps from reaching large tester audiences. Internal testers are members of your team and are trusted, so their builds skip that review.
Incomplete test information is a frequent cause, especially missing demo credentials for login-gated apps or vague What to Test notes. Crashes and guideline or metadata issues are also common.
If the rejection was about test information or metadata, you can update those and resubmit the same build. If you changed code to fix a crash or guideline issue, you must upload a new build with an incremented build number.
Review times vary and there is no fixed guaranteed turnaround. If a review is stuck unusually long, check Apple's system status and consider contacting Apple Developer Support rather than repeatedly cancelling and resubmitting.
Yes. Beta builds still need to broadly respect App Store guidelines. Content or functionality that would fail full review can also fail Beta App Review, so address any cited guideline directly.