A TestFlight tester clicks the public invitation link, lands on a TestFlight page that says the beta is not accepting new testers right now, and the developer opens App Store Connect to find the row reading In Review. The state is documented, the cause is documented, and the timing is not. That gap is where most teams lose two to three days of testing time on a release that was supposed to ship on a Friday.
Short answer
A TestFlight public link is gated by the underlying build's Beta App Review status. Apple's TestFlight overview specifies that the first build added to a tester group is sent to App Review and that testing begins after approval. Runway's crowdsourced App Store and TestFlight review times tracker reported a TestFlight in-beta-review average near 1h 37m as of May 2026, with waiting-for-beta-review near 7h 41m. Reports of multi-day stalls exist but sit outside the median.
What you should know
- The link follows the build state, not the group state. A public link routes invitees to whichever build the external testing group currently treats as live; while that build sits In Review, the link reads as inactive.
- Apple reviews the first build for a group, not every build. Per Apple's TestFlight overview, later builds for the same short version may skip a full review when Apple sees no material metadata change.
- Beta App Review is run by Apple, not by automated checks alone. The TestFlight queue feeds into a human review path tied to the App Review Guidelines.
- The published rate limit is six builds per 24-hour window. Re-uploading more often than that does not advance the queue.
- The typical band is a few hours to 48 hours. Outliers cross multiple days, and 2025 macOS reports went past ten days.
- Apple's System Status page is a lagging signal for Beta App Review. It tracked green across documented slowdowns in May 2025.
- A new build with an incremented CFBundleVersion is the most reliable lever. A re-upload at the same build number is rejected as a duplicate.
What does 'In Review' mean for a TestFlight public link?
The In Review state on a TestFlight build means the build is sitting in Apple's Beta App Review queue, not in the upload pipeline. Apple's TestFlight overview sets the boundary cleanly: when the first build for a new version is added to a tester group, it goes to App Review, and testing begins once the build is approved. Public invitation links route invitees to whichever build the external testing group currently treats as live. While the live build is In Review, the link displays as inactive.
The detail that catches teams off guard is that the link itself does not have a state. The state lives on the build. A group can have an old build that is still in Testing and a new build that is In Review; the link inherits the visible build for that group, which is normally the most recent approved one. When the most recent build is the new one and it is In Review, no other build is offered, and the public page reads as not accepting testers right now.
How long is a normal Beta App Review window in 2026?
Apple does not publish a target time for Beta App Review. The numbers that circulate come from third-party trackers and developer reports. Runway's crowdsourced App Store and TestFlight review times tracker reported, as of mid May 2026, a TestFlight in-beta-review average near 1h 37m and a waiting-for-beta-review average near 7h 41m, both calculated as truncated means from teams using their platform. These figures are observational, not promised.
Apple's documentation does set a rate limit. Apple's invite external testers reference names six builds per 24-hour window as the cap that TestFlight App Review accepts. Inside that limit, the queue progresses on Apple's schedule. Slow weeks happen. Michael Tsai's roundup of slow TestFlight reviews collected developer reports of macOS builds sitting in Beta Review for more than ten days in May 2025, with one Pacific timezone team noting that no movement followed three fresh uploads. The pattern recurred later in 2025 and again in early 2026.
The practical read is that a public link sitting on an In Review build under four hours is on the median path. Past 24 hours sits in undocumented territory. Past 72 hours, the case for an alternative action grows.
Which choices make a public link slower to clear review?
A small set of upload-time and metadata choices raises the probability that a public link sits in Beta Review longer than the median.
The first is whether the build is the first one for a new short version. Apple's documentation distinguishes first-build review from subsequent-build review for the same version, and the first build carries more review surface even when the underlying code change is small. A bump from 1.4.2 to 1.5.0 restarts the first-build path; a bump from build 42 to build 43 of 1.4.2 may not.
The second is the metadata sent with the build. The What to Test field, beta description, login credentials, and the contact email all feed into the review. A vague What to Test entry, missing demo credentials for a gated app, or a contact email that does not match the developer account are commonly cited reasons reviewers pause or escalate.
The third is the use of restricted entitlements or APIs that Apple flags for additional review. Builds using HealthKit, the Family Controls framework, Network Extension entitlements, or the App Tracking Transparency permission carry more review work and a longer typical wait.
The fourth is the public link configuration itself. Setting tester criteria, country filters, or device class filters does not slow Beta Review, and enabling automatic distribution to public link testers before approval has no effect. The link is gated by the build state regardless of the group settings.
How do you move a build that has been In Review for days?
Three levers, in order. Lever one is a fresh upload under an incremented CFBundleVersion against the same CFBundleShortVersionString. The original In Review row stays visible, the new artifact enters the pipeline, and TestFlight App Review evaluates the new one. A re-upload under the same build number is rejected as a duplicate identity, so the increment is required.
Lever two is contacting Apple Developer Support through App Store Connect. The Contact Us flow inside App Store Connect routes Beta Review inquiries to the right path. Expedited review for Beta App Review is rare, and Apple does not document the criteria. The Apple Developer Forums TestFlight tag reports occasional fast-track responses tied to documented hotfixes for critical bugs.
Lever three is reading the App Review Information panel. If Apple has paused the review for a clarifying question, the message appears there, not over email. A build can sit In Review because the reviewer is waiting on the developer, and that case clears as soon as the question is answered.
For builders shipping no-code or AI-coded apps through tools like FlutterFlow, Bubble, or Expo, an OWASP MASVS-aligned scan of the IPA before upload catches Privacy Manifest gaps, entitlement mismatches, and SDK metadata issues that Beta App Review is sensitive to. PTKD.com (https://ptkd.com) is one of the platforms focused on that pre-submission static check for APK, AAB, and IPA artifacts.
Which action at which hour mark actually helps?
| Action at hour N | What it changes | Apple documentation |
|---|---|---|
| Wait | Nothing; the queue progresses on Apple's schedule | TestFlight overview |
| Re-upload same build number | Rejected as duplicate identity | Build upload statuses reference |
| Re-upload with incremented CFBundleVersion | Enters a fresh review pass for the same version | Invite external testers page |
| Edit What to Test and beta credentials | Review can resume against updated metadata without a re-upload | Invite external testers page |
| Contact Apple Developer Support | Routes to the Beta App Review channel; expedited path rare | App Store Connect Contact Us |
| Cancel and resubmit under a new short version | Triggers a full first-build review pass | TestFlight overview |
What to watch out for
The first trap is treating the link as the unit of state. The link is a thin pointer; the build is the unit. Disabling and re-enabling the public link in the external testing group does not move the build, and it does not affect Beta App Review.
The second trap is confusing Beta App Review with the regular App Review queue that gates production releases. The two queues are separate. A production submission can sit in Waiting for Review while a TestFlight build for the same version sits in Testing, and vice versa. Status on one queue says nothing about the other.
The third trap is reading Apple's System Status page as authoritative. It tracks documented outages with a clear cause, not soft degradations of the Beta Review pipeline. The Apple Developer Forums TestFlight tag is the faster real-time signal for confirming whether a wider slowdown is in play.
The fourth trap is uploading more than six builds in 24 hours hoping to push the queue. Apple's invite external testers reference caps the rate at six per 24 hours, and uploads past that line are rejected on submission.
The fifth trap is rolling back code changes that did not cause the wait. Most In Review stalls trace to metadata, version transition, or queue load, not to a regression in the build under review.
Key takeaways
- The public link is a pointer to a build state, not a state of its own. Move the build, and the link follows automatically.
- The first build for a new short version carries more review work than subsequent builds. Plan submissions accordingly when timing a public link launch.
- Past 72 hours, the incremented re-upload is the lever with the highest hit rate. A same-number re-upload is rejected as a duplicate identity.
- Some teams add an OWASP MASVS scan before TestFlight submission to catch the silent gaps. PTKD.com (https://ptkd.com) is one option for that pre-submission static check on APK, AAB, and IPA artifacts.
- Anchor each claim to its lane. Confirmed: Apple's first-build review rule and the six-builds-per-24-hours rate cap. Observed: the Runway tracker numbers from May 2026. Inferred: the directional impact of restricted-entitlement use on review duration.
