Seeing one build say Ready to Test and another say Waiting for Review is confusing until you know they are different stages, not different speeds of the same thing. One means testers can install the build now; the other means an external build is sitting in Beta App Review. The reason the two diverge comes down to internal versus external testing. Here is what each status means and why internal testers get a build instantly while external testers wait.
Short answer
In TestFlight, Ready to Test means a build has finished processing and is available to install, while Waiting for Review means an external build is queued for Beta App Review before testers can get it. The split is internal versus external: internal testing skips Beta App Review, so a build is available within minutes of processing, while the first build of a version for external testers goes through review, which can take around a day. Later builds of the same version usually skip the full review, and internal testing runs in parallel as the fast path.
What you should know
- Ready to Test means installable: the build has processed and testers can install it.
- Waiting for Review means queued: an external build is in line for Beta App Review.
- Internal testing skips review: builds reach internal testers within minutes of processing.
- External first builds are reviewed: the first build of a version waits for Beta App Review.
- Later builds are faster: subsequent builds of the same version usually skip the full review.
What does "Ready to Test" mean?
It means the build is past processing and available to install. Once a build finishes the automated processing step, it can be tested, and TestFlight shows it as ready. For internal testers, that happens immediately, because internal builds do not need Beta App Review. For external testers, Ready to Test means the build has cleared review and is now available to the group. So the status is about availability: when you or a tester sees it, the build can be installed, with no further waiting on Apple.
What does "Waiting for Review" mean?
It means an external build is queued for Beta App Review. When you add the first build of a version to an external testing group, TestFlight sends it to Beta App Review against the App Review Guidelines, and while it sits in that queue the status is Waiting for Review. Your external testers cannot install it yet. This status only appears for external testing, because internal testing does not go through review. So Waiting for Review is the external-only waiting room between processing and availability. It is worth noting that the status is per group and per version, so the same build can read Ready to Test for your internal group and Waiting for Review for an external group at the same moment, which is exactly the side-by-side that confuses people.
Why is internal testing instant but external slower?
Because only external testing requires Beta App Review. The table shows the lifecycle and where the wait is.
| Status | What it means | Who and when |
|---|---|---|
| Processing | Automated preparation after upload | All builds, minutes |
| Ready to Test | The build is available to install | Internal immediately; external after approval |
| Waiting for Review | An external build is queued for Beta App Review | First build of a version, external only |
| In Review | Beta App Review is actively checking the build | External, first build of a version |
Internal builds go straight from Processing to Ready to Test, which is why they feel instant. External builds add the Waiting for Review and In Review stages for the first build of a version, which is where the roughly one-day wait comes from. The difference is the review requirement, not the speed of processing. So if internal testers already have the build and external testers do not, nothing is broken; the external build is simply still in the review stage that internal builds never enter.
How do you get from Waiting for Review to Ready to Test faster?
By understanding that only the first build of a version waits. Beta App Review reviews the first build of each version, so once that build is approved and shows Ready to Test, later builds of the same version usually skip the full review and become available quickly. The practical levers are to submit the first build early, increment the build number rather than the version string for fixes so you stay on the approved version, and use internal testing in parallel to get eyes on the build while the external build clears review. You cannot rush Beta App Review itself, but you can avoid restarting it unnecessarily.
What to watch out for
The first trap is expecting external testers to install immediately, when the first build of a version must clear Beta App Review first, so plan for about a day. The second is bumping the version string for a small fix, which sends the new version's first build back to Waiting for Review when a build-number increment would have stayed on the fast path. The first build is also a full guideline check, so a problem that would fail App Store review can stall it; a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS so the build entering Beta App Review is already clean, which is a separate concern from the status itself.
What to take away
- Ready to Test means a build is available to install; Waiting for Review means an external build is queued for Beta App Review.
- Internal testing skips review and is available within minutes, while external testing's first build of a version goes through review.
- Later builds of the same version usually skip the full review, so increment the build number for fixes and use internal testing in parallel.
- The first build is a full guideline check, so confirm the binary with a pre-submission scan such as PTKD.com before it enters Beta App Review.
