The short version is that "Waiting for Review" means your external build is still in Apple's Beta App Review queue, while "Ready to Test" means it has been approved and testers can install it. Both are normal stages, not errors. An external build has to pass Beta App Review before it becomes Ready to Test, and the first build of a version always needs a full review. If it is stuck in Waiting for Review, the usual answer is to wait within the normal range rather than resubmit.
Short answer
In TestFlight, "Waiting for Review" means your external build is queued for Beta App Review and testers cannot install it yet, while "Ready to Test" means Apple approved it and it is available to your external testers. Apple sends external builds to review automatically when you add them to a group, per its TestFlight page, and the first build of a version needs a full review. Review usually takes a few hours to 48 hours. Resubmitting restarts it, so wait within the normal range first.
The external TestFlight statuses, in order
An external build moves through a fixed sequence, and knowing the order tells you where you are. It starts in Processing while Apple validates the upload, moves to Waiting for Review once it is queued, then In Review when a reviewer opens it, and finally Ready to Test when approved. If Apple finds a problem, it becomes Rejected instead. The table below lays out each status.
| Status | What it means | Typical time | What it needs |
|---|---|---|---|
| Processing | Apple validates the upload | Minutes to 1 hour | Wait |
| Waiting for Review | Queued for Beta App Review | Hours to 48 hours | Wait; first build needs review |
| In Review | A reviewer is evaluating it | Minutes to a few hours | Wait |
| Ready to Test | Approved and available to testers | Final state | Distribute to your testers |
| Rejected | Apple found an issue | Fix and reply | Read the Resolution Center |
Internal testers skip this entirely: their builds become available after Processing, without Beta App Review. Only external builds pass through the review stages, which is why an external group waits while an internal group does not. That single distinction explains most of the confusion around these statuses.
Waiting for Review vs Ready to Test: the key difference
The difference is simple: Waiting for Review means not yet reviewed, and Ready to Test means approved and installable. A build in Waiting for Review is in the queue, and your external testers cannot install it no matter how many times they refresh TestFlight. A build in Ready to Test has cleared Beta App Review and is available, assuming you have distributed it to the group.
This matters because the two statuses call for different actions. If you are in Waiting for Review, the answer is almost always to wait, because the ball is in Apple's court. If you are in Ready to Test but testers still cannot see the build, the issue is on your side: you likely need to distribute the build to the group or enable tester notifications. Confusing the two leads people to resubmit a build that was actually just waiting on a distribution step they control. Knowing which of the two states you are in saves you from taking the wrong action and, worse, restarting a review that was almost done.
Why is it stuck in Waiting for Review and not Ready to Test?
The most common reason is simply that it is the first build of a version, which always needs a full Beta App Review before it can become Ready to Test. Beyond that, Apple reviews one build of each version at a time, so a second upload of the same version waits behind the first. A build can also sit longer during a general slowdown, like the one many developers reported in early 2026 on the Apple Developer Forums.
Submission details can slow it too. An empty "What to Test" field, missing export compliance information, or permissions that need justification can lead to a longer review or a rejection. Filling these in clearly before you submit is the simplest way to keep a build moving toward Ready to Test, because a reviewer who knows exactly what to test spends less time on it. It also helps to double-check that export compliance is answered, since a missing answer there is a frequent and quiet cause of a build sitting longer than expected.
Does resubmitting help?
No, resubmitting almost never helps and usually hurts. Uploading a new build of the same version replaces the one in review and restarts the process, sending you to the back of the queue, so you move further from Ready to Test rather than closer. Apple also caps you at six builds per 24 hours for TestFlight review, so rapid re-uploads simply burn that quota.
Resubmit only when you have genuinely fixed a problem that caused a rejection. Otherwise, leave the build in Waiting for Review and let it finish. If you need to test something immediately, add an internal tester group, which bypasses review and gives you a working build within minutes of processing.
What to do to move it to Ready to Test
Match your action to the current status instead of guessing. The table below maps each state to the right next step.
| Current status | What to do | When to escalate |
|---|---|---|
| Processing over 2 hours | Re-check; a stuck upload may need a re-upload | If stuck for many hours |
| Waiting for Review under 48 hours | Wait, this is normal | Not yet |
| Waiting for Review over 48 hours | Check export compliance and "What to Test" | If several days |
| Ready to Test, testers cannot see it | Distribute the build or enable notify testers | Not needed |
| Rejected | Read the reason and fix | If the reason looks wrong |
The single most common false alarm is a build that is already Ready to Test but that testers cannot see, because it was never distributed or because "Automatically notify testers" was not selected. Before assuming a build is stuck, confirm which status it is actually in, since the fix for Waiting for Review is patience, and the fix for Ready to Test is a distribution step you control.
When to contact support
Contact Apple when a build clearly passes 48 hours in Waiting for Review with no movement, and especially past several days. For a rejection, respond in the Resolution Center. Include the build identifier, the exact submission date and time, and a screenshot of the status, so your case is not delayed for missing information.
Set realistic expectations. During the 2026 slowdown, developers reported slow responses to support. Escalating after several days is correct, but it is not a guaranteed unblock, especially when a general backlog is the cause rather than something specific to your build. Documenting the timeline helps if the case drags on and you need to follow up.
Where a pre-submission scan fits
A rejection keeps a build out of Ready to Test and sends you back to the queue, so avoiding an avoidable rejection is the fastest way to reach Ready to Test. An embedded secret key, a permission with no justification, or an insecure network setting can each cost you a full review cycle and push Ready to Test further away.
A scanner like PTKD.com analyzes your built .ipa before you upload and returns a graded report mapped to OWASP MASVS, so you can fix what would trigger a rejection before the build enters review. It is worth being clear about the limit: a scanner cannot speed up Beta App Review or move a build to Ready to Test, and it does not replace a manual audit for high-risk apps. What it does is remove the avoidable reasons a build gets rejected, which is the thing most likely to keep it out of Ready to Test.
What to take away
- Waiting for Review means queued and not yet installable; Ready to Test means approved and available to testers.
- An external build must pass Beta App Review before Ready to Test, and the first build of a version always needs a full review.
- Resubmitting restarts review and moves you away from Ready to Test; leave the build in place unless you fixed a rejection.
- A build that is Ready to Test but invisible to testers usually needs to be distributed or have notifications enabled.
- Before uploading, scan the build with PTKD.com so an avoidable rejection does not keep it out of Ready to Test.
