A build finishes uploading, the badge in App Store Connect flips to Ready to Test for one column, and the other column still reads Waiting for Beta Review the next morning. That split is the difference between internal TestFlight and external TestFlight, and it shapes how a team plans a release week.
Short answer
Internal TestFlight testers, up to 100 App Store Connect users on your team, see any processed build within minutes, with no Beta App Review at all. External testers, up to 10,000 invitees per app, only see builds that have passed Beta App Review. Runway's public review-time tracker put that wait around seven to nine hours plus a short in-review window as of May 2025, though Michael Tsai's running coverage shows multi-day delays during heavy release periods.
What you should know
- Internal builds skip Beta App Review entirely. They are available to your App Store Connect team as soon as Apple finishes processing the build, per Apple's TestFlight overview.
- External builds need Beta App Review for the first build of a new version. Apple's external tester invite guide states this directly.
- Subsequent builds inside the same version usually go through with no full review, which is why teams stage features under a single version when they want fast iteration.
- Build processing alone takes about 25 minutes on average, per Runway's tracker, before any review wait starts counting.
- Apple caps new build submissions at six per app per 24 hours, which becomes the real bottleneck on heavy iteration days.
- Each approved build expires after 90 days, so a long-running beta needs a refresh cycle planned in.
What is the actual time gap between internal and external TestFlight?
The short answer is that internal is on the order of minutes after processing, and external is on the order of hours, sometimes days. Apple's TestFlight overview describes internal testers as members of your development team and explains that builds shared with internal-only groups do not need Beta App Review. Once Apple's processing layer finishes, which takes about 25 minutes on average according to Runway, the build is visible in the TestFlight app on every internal tester device that has push notifications enabled.
External testers follow a different path. Apple's invite-external-testers help page is explicit: the first build of a version sent to an external group is sent to Beta App Review, which checks the build against the App Store Review Guidelines. Runway, which aggregates timing telemetry across many teams, reported a Waiting for Beta Review average of 7h 41m and an In Beta Review average of 1h 37m as of May 12, 2025. Treat those numbers as a typical window, not a contract. Michael Tsai's blog tracks individual developer reports, including a ten-day macOS TestFlight wait from Craig Hockenberry in May 2025 and similar multi-day delays reported in July and August.
Here is how the two paths compare in practice.
| Step | Internal TestFlight | External TestFlight |
|---|---|---|
| Tester cap | 100 App Store Connect users | 10,000 invitees per app |
| Apple Account required | Yes, for every internal user | No, email or public link works |
| Build processing | About 25 min average (Runway) | About 25 min average (Runway) |
| Beta App Review | Not required | Required for first build of a version |
| Typical wait, first build | Minutes after processing | About 7h waiting plus 2h in review (Runway, May 2025) |
| Worst case reported | Same as processing | 10+ days during slow periods (Tsai blog) |
| Subsequent builds, same version | Same minutes window | Often no review, near-instant after processing |
Why does external TestFlight sometimes take longer than App Store Review?
This is a complaint that comes up consistently among iOS developers, and the data backs it. Runway's same May 2025 snapshot put App Store Review at 9h 48m waiting and 1h 58m in review for a production release, and Beta App Review at 7h 41m and 1h 37m. The two queues are similar on the average day. The reason TestFlight feels slower is that bug-fix urgency is high, and developers expect a beta channel to be fast. Luc Vandal observed in July 2025 on Michael Tsai's blog that TestFlight builds can take longer to approve than App Store releases, which makes the channel impractical for urgent bug fixes during a feature freeze.
The mechanism behind that pattern is that Beta App Review appears to be staffed similarly to App Review and prioritized alongside it. Apple does not publish queue depth or staffing per channel, so any specific ratio is inference, but the directional pattern from developer reports is consistent: when App Review is slow, Beta App Review is at least as slow.
When does an external TestFlight build skip review?
Apple sends a build to Beta App Review when one of two things happens. The first build of a new version always goes to review, per the external tester help page. After that, additional builds with the same version number can be added to the external group with no review, which is why production guidance suggests freezing the version string while iterating on bug fixes.
A separate path triggers a re-review even on the same version: changing what the build can do in ways that touch the review surface. Adding a new tracking SDK that requires App Tracking Transparency, requesting a permission that needs a new Purpose String, or changing the app icon and metadata in ways that affect public-facing review can move a same-version build back into the queue. Apple's documentation does not enumerate this list, so the pattern is best treated as directional based on developer reports.
The TestFlight Internal Only flag on a build is a hard switch. A build marked Internal Only in App Store Connect cannot be added to any external group, ever. The flag is useful for builds that contain debug menus or staging server URLs that should never reach a public tester, and it is set at upload time.
How does Beta App Review actually compare to App Store Review?
Both reviews run against the App Store Review Guidelines, but the scope is narrower for TestFlight. Apple's TestFlight overview describes Beta App Review as a check that the build is functional and meets the basic requirements for external testing. In practice this means catastrophic crashes, missing test information, missing Purpose Strings for sensitive permissions, content policy concerns, and obvious guideline violations. It does not include the full marketing review that the App Store version receives (metadata, screenshots, age rating disputes).
The required metadata is also narrower. App Store Connect requires test information (feedback email, contact info, what to test) before the build can be submitted for Beta App Review, but it does not require localized screenshots or release notes. The full list is in Apple's external tester help page.
Two things to keep in mind. A Beta App Review rejection is different from an App Store rejection, but the reasons (Guideline 5.1.1 privacy, Guideline 2.1 functionality, Guideline 2.5 software requirements) come from the same guidelines book. Fixing the rejection unblocks both channels at once.
What slows external Beta App Review down in practice?
Three patterns show up over and over in pre-submission audits and developer reports.
The first is missing or weak test information. The What to Test field is required, and reviewers use it to know what to exercise. Builds with a placeholder ("test the app") tend to get pushed back to the queue, which adds another waiting cycle. Detailed, scenario-level test notes (sample login, demo data, link to a private test page) consistently correlate with faster turnarounds.
The second is permission and Purpose String drift. A new build that requests photo library access, location, contacts, or microphone without a clear, user-facing Purpose String fails Beta App Review the same way it would fail App Review. Every permission triggers a Purpose String check, and a missing one is grounds for rejection.
The third is third-party SDKs that change Privacy Manifest requirements. Apple's Privacy Manifests documentation lists the SDKs that must declare a PrivacyInfo.xcprivacy file as of May 2024. Adding one of those SDKs (or updating to a version that newly tracks required reasons) without updating the Privacy Manifest is increasingly cited as a reason for both Beta App Review and App Review delays. A pre-submission scan, whether internal or external, catches this before the build hits Apple's queue. PTKD.com (https://ptkd.com) is one of the platforms that runs this Privacy Manifest and OWASP MASVS check against an IPA before it goes up.
How do you plan a release week around these timelines?
A practical default that survives most release cycles: submit the first build of a new version to external TestFlight at the start of a workday, mid-week. Friday submissions show notably longer waits in Runway's tracker (17h 17m waiting on average versus 9h 44m on Tuesday for App Review, and the same weekday skew applies to Beta App Review). The earlier in the day and the earlier in the week, the faster the first turn tends to be.
Inside that same version, keep iterating with non-significant builds. Mark each new build as having no significant changes if the changes are bug fixes and copy tweaks; that flag is what tells App Store Connect not to send the build back through Beta App Review. Save the significant-change flag and the version bump for when behaviour or capabilities genuinely change. The mistake many teams make is bumping the version on every build out of habit, which forces a fresh Beta App Review every time.
What to watch out for
A few common myths and traps:
- The myth that TestFlight Beta App Review is fully automated. It is reviewed by humans, the same way App Review is, and that is why it tracks the same weekday and weekend rhythm in the Runway data.
- The myth that internal testers see every build. They see builds in groups they are added to, on devices where TestFlight is installed and signed in to the right Apple Account, with notifications enabled. A "missing" internal build is almost always a group assignment or notification issue, not a review issue.
- The 90-day build expiry. A build that was approved and tested for two months becomes unavailable two months later. Long-running betas need a recurring rebuild and resubmission plan.
- The six-builds-per-24-hours cap. Repeatedly submitting and pulling builds during a frantic afternoon hits the limit and locks out further submissions for hours. Apple's external tester help page calls out the cap directly.
- The Internal Only flag. Once a build is processed as Internal Only, it cannot be promoted to external. Plan the flag before upload, not after.
Key takeaways
- Internal TestFlight is minutes; external TestFlight is hours on a good day and days on a bad one. Treat the two channels as different release tools, not as a single button.
- Beta App Review and App Store Review run on similar queues. When one is slow, the other tends to be slow too.
- Lock the version string for the duration of an iteration cycle and use the no-significant-changes flag. That is the single setting that shortens external rollout time the most.
- Submit first-of-version builds early in the week and early in the day. The Runway data is consistent on the weekday and time-of-day effect.
- Some teams treat a pre-submission scan as a routine step before the first external build of any new version. PTKD.com (https://ptkd.com) is one of the platforms that runs an OWASP MASVS-aligned check on the IPA, surfacing Privacy Manifest gaps, permission strings without justification, and exposed secrets before the build reaches Apple's queue.
