How long TestFlight review takes depends entirely on whether your testers are internal or external. Internal builds are not reviewed at all: members of your own team can install them within minutes of processing finishing. External builds go through Apple's Beta App Review, which usually takes a few hours to 48 hours, with the first build of a version taking the longest because it needs a full review. If you need to test something right now, an internal group skips review completely and unblocks you immediately.
Short answer
Internal TestFlight builds are not reviewed, so your team can test them within minutes of processing finishing. External testers require Beta App Review, which typically takes a few hours to 48 hours, based on how Apple handles beta builds on its TestFlight page. The first build of a version needs a full review, while later builds of the same version often do not. Resubmitting a build restarts the review, and there is no guaranteed time, so treat any single number as an average rather than a promise.
Internal vs external: the difference that sets the wait
The biggest factor in TestFlight timing is internal versus external testers, not the size of your app. Internal testers are up to 100 people who hold a role in your App Store Connect account, and their builds skip Beta App Review entirely. As soon as processing finishes, usually within minutes, they can install the build. External testers, up to 10,000 people outside your team, require Beta App Review before they can install anything.
That difference is a practical tool, not just trivia. If you are blocked waiting for external review and need to verify a fix now, add yourself or a colleague as an internal tester and install the same build immediately. Many developers wait days for external review when an internal group would have unblocked their own testing in minutes.
| Aspect | Internal testers | External testers |
|---|---|---|
| Beta App Review | Not required | Required |
| Who can join | Up to 100 with App Store Connect roles | Up to 10,000 outside your team |
| Typical wait | Minutes after processing | A few hours to 48 hours |
| First build of a version | No review needed | Full review required |
The takeaway is simple: use internal testing for speed and your own verification, and external testing when you genuinely need people outside your team, accepting the review wait that comes with it.
How long does external Beta App Review take?
External review usually takes a few hours to 48 hours, with the first build of a version at the longer end. Apple does not guarantee a time, so any exact figure is an average reported by other developers, not a commitment. The table below maps the statuses you will see to what is normal and when to worry.
In App Store Connect, an external build passes through a few statuses. Processing validates the upload and takes minutes. Waiting for Review means the build is queued for Beta App Review, normally a few hours to 48 hours. In Review means a reviewer is actively evaluating it, usually minutes to a few hours. Ready to Test is the final approved state, and Rejected means Apple found an issue you can read in the Resolution Center. Treat more than 48 hours in Waiting for Review, or more than 24 hours In Review, as a signal to check the causes below rather than to keep waiting.
During February and March 2026, a broad slowdown stretched review queues for many developers, as documented on the Apple Developer Forums. In those periods, a long wait can come from volume rather than a problem with your build, but past 48 hours it is still worth checking the concrete causes below.
First build vs later builds: why the first one is slower
The first build of a version is slower because it always needs a full Beta App Review, while later builds of the same version often do not. When you upload a brand-new version number and add it to an external group, Apple reviews it in full: the binary, the metadata, and the beta description. Once that version is approved, subsequent builds of the same version usually clear faster, because the heavy review already happened.
This is why a small fix uploaded as a new version can feel unexpectedly slow, while an iteration on an already-approved version goes quickly. If you are early in a testing cycle and plan several rapid iterations, keep them under the same version number where possible, so you pay the full-review cost once rather than on every build.
What makes external review slower?
Most delays come from Beta App Review rules and your submission details, not code quality. Beyond the first-build rule, Apple only allows one build of each version in review at a time, so a second upload of the same version waits behind the first. Apple also caps submissions at six builds for TestFlight review within a 24-hour period, so rapid re-uploads burn through that quota without helping.
Submission details matter too. An empty "What to Test" field, permissions that need justification, or missing export compliance information all slow a reviewer down or lead to a rejection. A reviewer who cannot tell what to test, or who hits a wall on missing information, will take longer. Filling these fields in clearly before you submit is the simplest way to avoid an avoidable delay.
Does resubmitting reset the clock?
Yes. Uploading a new build of the same version replaces the one in review and restarts the process from the beginning, sending you to the back of the queue. Resubmitting only makes sense if you actually fixed a problem that would have caused a rejection, for example after reading a rejection reason in the Resolution Center.
When a deadline is pressing, resubmitting is almost never the answer, because it discards the progress the current build already made. Bundle your changes into a single clean build and let the review finish, rather than uploading several versions in quick succession that each reset the timer and eat your daily quota.
What to do while you wait
Figure out how long you have been waiting and act on that, instead of resubmitting on reflex. The table below gives a clear route by situation.
| Your situation | What to do first | When to escalate |
|---|---|---|
| Under 48 hours (external) | Wait, this is normal | Not yet |
| Need to test right now | Use an internal tester group | Not needed |
| Another build of the same version in review | Wait for it to finish, do not stack uploads | No |
| Over 48 hours with no change | Check "What to Test", export compliance, permissions | Prepare a case |
| Status is Rejected | Read the reason in the Resolution Center and fix | If the reason looks wrong |
Work the steps in order and note what you find. Many TestFlight delays clear once you fill in the "What to Test" field, complete export compliance, or simply let an already-in-review build finish. These checks are almost always better than another upload that starts over.
When to contact support
Contact Apple when you clearly pass 48 hours with no movement, and especially past several days. For a rejection, respond in the Resolution Center, which is the channel Apple reads for review cases. Include the build identifier, the exact submission date and time, and a screenshot of the status, so your case is not held up for missing information.
Keep expectations realistic. During the 2026 slowdown, developers reported slow responses to support and expedited requests. Escalating is the right move after several days, but it is not a guarantee of an instant unblock, especially when the cause is a general backlog rather than a problem specific to your build.
Where a pre-submission scan fits
A rejected external build sends you back into the queue, so the fastest way to keep your beta on schedule is to not waste a review cycle on a build that was going to be rejected. An embedded secret key, a permission with no justification, or an insecure network setting can cost you a full cycle, which stings when a team is waiting to test.
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 it enters the queue. It is worth being clear about the limit: a scanner cannot speed up Apple's Beta App Review or replace a manual audit for high-risk or regulated apps. What it does is catch the avoidable issues that would send you back to the start, which matters most when review is already slow.
What to take away
- Internal TestFlight builds are not reviewed and reach your team within minutes; external builds require Beta App Review.
- External review usually takes a few hours to 48 hours, and the first build of a version needs a full review.
- Only one build of each version is in review at a time, and resubmitting restarts the clock.
- To test urgently, use an internal group to bypass review entirely instead of waiting on external review.
- Before you upload, scan the build with PTKD.com so an avoidable rejection does not cost you a full review cycle.
