Your first TestFlight build sat in review for the better part of a day, and now you are wondering whether every build will cost you that wait, or whether the first one is a special case. For a team trying to get a beta in front of external testers on a deadline, that distinction decides your release plan.
Short answer
Yes, the first build of each version takes longer because it goes through Beta App Review, and later builds of the same version usually do not. Apple's TestFlight overview states that when you add the first build of your app to a group it is sent to App Review, that a review is required only for the first build, and that subsequent builds may not require a full review. Testing begins once that first build is approved. Internal-only testing does not trigger this review at all.
What you should know
- The first build of a version is reviewed: Apple sends it to Beta App Review against the App Review Guidelines.
- Subsequent builds usually skip it: later builds of the same version may not require a full review and often reach testers quickly.
- Internal testing does not wait: builds for up to 100 internal testers become available after processing, with no Beta App Review.
- A new version restarts the clock: the first build of the next version is reviewed again.
- External testing scales to 10,000: once approved, the build can go to up to 10,000 external testers.
Why does the first build take longer than the rest?
Because the first build of a version is the one Apple actually reviews. When you add that first build to an external group, App Store Connect sends it to Beta App Review, which checks the build against the App Review Guidelines before any external tester can install it. This is a human-gated step, so it inherits the same queue behavior as a normal submission, and testing only starts once the build is approved. The first build carries the full check; the wait you saw is that review, not processing. Processing, the automated step that prepares and validates the binary, finishes in minutes and is separate from Beta App Review, so if your build sat for hours it was waiting in the review queue rather than still processing. That separation is the single most useful thing to understand about TestFlight timing, because it tells you whether to keep waiting or to start looking for a problem.
Do subsequent builds of the same version skip review?
Usually, yes. Apple's wording is that a review is required only for the first build and that subsequent builds may not require a full review, so once your first build of a version is approved, later builds of that same version typically reach your existing external testers within minutes of finishing processing. The phrase "may not" matters: Apple reserves the right to review some later builds, so it is not a guarantee, but the common case is a fast turnaround. The condition is that you are updating an already-approved version for the same testers, not starting a new version or a new group. Adding a build to a brand-new external group can also send it back to review, because that group has not yet seen an approved build, so the fast path applies to existing groups on an approved version rather than to any build you upload.
Does internal testing trigger Beta App Review?
No. Builds distributed only to internal testers do not go through Beta App Review. App Store Connect makes a processed build available to your internal testers, up to 100 App Store Connect users with the right role, as soon as processing finishes. The practical result is that internal testing is the fast path: if you need eyes on a build today, push it to internal testers while the first external build clears Beta App Review in parallel.
When does the first-build review come back?
When you ship a new version. The first-build review is tied to the marketing version, not to every upload. If you increment the build number under the same version string, you are still on an approved version and the fast path applies. If you bump the version string, the first build of that new version goes back through Beta App Review. In Info.plist terms, CFBundleVersion is the build number and CFBundleShortVersionString is the version string, so raising only CFBundleVersion keeps you on the approved version and the fast path. The mistake that causes a surprise wait is raising the version string when only a build-number bump was needed.
How long does Beta App Review take in practice?
Apple does not publish a per-build timer, so treat any number as directional. In developer-reported experience the first Beta App Review often clears within a day, sometimes faster and sometimes longer when the queue is busy, and independent trackers such as Runway's review-time tracker follow the moving average. Subsequent same-version builds usually appear in minutes. An expedited review request exists for urgent cases, but it is granted at Apple's discretion and is not a routine lever. Weekends and holidays lengthen the queue, so a first build submitted late on a Friday can sit until the following week, which is worth planning around when a beta has a hard deadline. The pattern most teams settle into is to submit the first build of a version a day ahead of when external testers actually need it.
What to watch out for
The first build is a full guideline check, not a rubber stamp, so a problem that would fail App Store review can also stall or reject your first beta. A missing Purpose String, a Guideline 4.8 login gap, or an obvious privacy issue surfaces here just as it would at submission, which means a sloppy first build costs you the slowest review you will face in the cycle. Clean the build before that first upload rather than after. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS for the binary-level issues, so the first build that enters Beta App Review is already the one you would ship.
What to take away
- The first build of each version goes through Beta App Review; later builds of the same version usually skip a full review and ship in minutes.
- Internal testing never waits on Beta App Review, so use it as the fast path while the first external build clears.
- Increment the build number rather than the version string for fixes, because a new version restarts the first-build review.
- The first build is a full guideline check, so clean the binary with a pre-submission scan such as PTKD.com before that first upload to avoid the slowest review in the cycle.
