"Waiting for Review" means your build is in Apple's Beta App Review queue and testers cannot install it yet. "Ready to Test" means the build has been approved and is available to install. The two are consecutive steps: a build for external testers moves from Waiting for Review to In Review to Ready to Test. Internal testers skip review and go straight to Ready to Test. Waiting for Review normally lasts a few hours to 48 hours for the first build of a version.
Short answer
"Waiting for Review" is a queue state: your build finished processing and is lined up for Beta App Review, but a reviewer has not opened it yet. "Ready to Test" is the finished state: the build passed review, or skipped it for internal testers, and testers can install it. According to Apple's TestFlight page, only external testers require Beta App Review, so an internal build reaches Ready to Test in minutes. Waiting for Review normally lasts a few hours to 48 hours. Resubmitting restarts the review. If you pass 48 hours with no change, check the submission details and contact support.
What does "Waiting for Review" mean?
"Waiting for Review" means your build finished processing and is now in the queue for Beta App Review, but a human reviewer has not started on it yet. It is a normal, expected step for external testing, not an error or a penalty on your account. Apple submits the build to review automatically when you add it to an external group.
The detail that trips people up is that only the first build of each version needs a full review. Later builds of the same version often skip it. That is why the first submission of a new version almost always sits in Waiting for Review longer than the ones that follow, and why a small fix on an already-approved version usually clears much faster.
What does "Ready to Test" mean?
"Ready to Test" means the build is approved and available for testers to install right now. For external testers, it appears after Beta App Review approves the build. For internal testers, it appears within minutes of processing, because the internal channel skips review entirely.
Reaching Ready to Test is the goal of the whole flow. Once a build shows this status, you can assign it to a tester group, and testers can update to it in the TestFlight app. If an approved build later expires, which happens 90 days after upload, it leaves this state, and you upload a fresh build to continue testing.
Waiting for Review vs Ready to Test at a glance
The two statuses are consecutive stages of the same pipeline, so it helps to see them side by side. The table below shows how they differ in practice.
| Aspect | Waiting for Review | Ready to Test |
|---|---|---|
| Meaning | In the Beta App Review queue | Approved and available to testers |
| Applies to | External testers, first build of a version | Both internal and external, after approval |
| Can testers install? | No | Yes |
| Normal duration | A few hours to 48 hours | Final state until a new build or expiry |
| Your next action | Wait, then check submission details | Assign to a group and notify testers |
One point worth stressing: Ready to Test does not mean your app is approved for the App Store. Beta App Review is a lighter check than full App Review, so a build that testers can install may still need changes before public release. Treat Ready to Test as clearance for testing, not as a green light for the store.
In short, Waiting for Review is a "not yet" and Ready to Test is a "go." Everything you do while waiting is about moving the build from the first to the second without wasting a review cycle.
How long should each status last?
Waiting for Review normally lasts a few hours to 48 hours for the first build of a version, and is often much faster for later builds that skip review. Ready to Test is a final state, so it stays until you upload a newer build or the build expires. Apple does not guarantee a review time, so treat any figure as an average, not a promise.
During February and March 2026, a wider backlog stretched the queue for many developers, as noted in an Apple Developer Forums thread. In those periods, a long Waiting for Review does not always signal a problem with your build, though past 48 hours it is worth checking the submission details.
Should you wait or resubmit?
For the first 48 hours, wait. Resubmitting a new build of the same version replaces the one in review and restarts the process from zero, so you lose your place in the queue. Resubmit only if you fixed a real problem that would have caused a rejection, for example after reading the reason in Resolution Center.
If you need to test immediately while the external build waits, add an internal tester. The internal channel skips review and reaches Ready to Test in minutes, without spending your limit of six builds per 24 hours. That is almost always a better move than resubmitting out of impatience. The one case where resubmitting helps is a genuine defect: if you already know the current build is broken or would be rejected, a corrected build is worth the reset. Outside of that, patience keeps your place in line and usually gets you to Ready to Test sooner.
Step by step: unblock a stuck status
Act based on how long you have waited, not on nerves. The table below gives a clear path for each situation.
| Situation | What to do first | When to escalate |
|---|---|---|
| Under 48 hours in Waiting for Review | Wait, it is the normal range | Not yet |
| Need to test right now | Add an internal tester | Not needed |
| Another build of same version in review | Wait for it to finish | No |
| Over 48 hours with no change | Check "what to test" and export compliance | Prepare a case |
| Status shows Rejected | Read the reason and fix it | If the reason looks wrong |
Before you escalate, confirm three things: export compliance is complete, the "what to test" field is not empty, and no other build of the same version is blocking the queue. These three points resolve a large share of the cases that look like a stall but are really a missing detail on your side. Fixing one of them yourself is far faster than waiting on a support reply that would only point you to the same field.
When to contact support
Contact support when you clearly pass 48 hours with no movement, and especially after several days. For a rejection, reply in Resolution Center. Include the build number, the date and time of the submission, and a screenshot of the status, so your case does not stall for lack of information.
Keep expectations realistic. During the 2026 backlog, support responded slowly. Escalating after several days is the right move, but it does not guarantee an instant release, especially when the cause is a general backlog rather than a problem specific to your build.
Check the build before you upload
The safest way to avoid losing time is to not spend a review cycle on a build that was going to be rejected. Each rejection sends you back to the queue, so an avoidable problem, such as an embedded secret key, a permission with no justification, or an insecure network setting, can cost you another full cycle right when a team is waiting on the beta.
A security scanner like PTKD.com analyzes the .ipa before you upload and returns a report ordered by severity and mapped to OWASP MASVS, so you fix what would trigger a rejection before you enter the queue. To be honest about its limits: a scanner does not speed up Apple's Beta App Review, and it does not replace a manual audit for high-risk or regulated apps. What it does is remove the predictable rejections that repeat the wait, which is exactly what you want when review is already slow.
What to take away
- "Waiting for Review" is a queue state; "Ready to Test" is the approved, installable state.
- External testers pass through review; internal testers reach Ready to Test in minutes.
- The first build of a version needs full review, normally a few hours to 48 hours.
- Resubmitting restarts the review; to test now, use an internal tester instead.
- Before uploading, check the build with PTKD.com so a preventable rejection does not cost you a cycle.
