Do I need to resubmit a rejected TestFlight build?

Do I need to submit my build again before external TestFlight testers can see it after rejection

Yes. If Apple rejects a TestFlight build, external testers cannot keep using that build, and you must submit a new build for TestFlight App Review before external access returns. Apple says a rejected build can no longer be used in TestFlight, and for TestFlight you must submit a new build for review before inviting external testers again.

The part people get wrong is the word “resubmit.” You do not reopen the old rejected build and expect it to become visible again. Apple treats the rejection as a stop signal for that build. The fix is a new upload, usually with a new build number, followed by another TestFlight review cycle. Apple’s own guidance for beta distribution says to upload a new build after you incorporate changes, and its tutorials say to update the build number and repeat the archive, upload, and distribution steps.

External testers are different from internal testers. Internal testing can use builds without the same public beta review flow, but external testing starts with TestFlight App Review. Apple’s TestFlight pages say you need an external group, you add builds to that group, and the first build for external testing goes through review before you can invite external testers. Once a build is rejected, that specific build is no longer available for TestFlight distribution.

The inconvenient part is that a rejection does not just pause new invitations, it removes the build from usable external testing. Testers who already had the rejected build do not get a special exception, because Apple’s status page says the build can no longer be used in TestFlight. If you want external testers back on track, the practical sequence is: fix the issue, increment the build number, upload the new archive, submit the new build for beta review, then re-add or re-notify the external group after approval.

Do not confuse this with later builds of the same version. Apple says TestFlight App Review is required for the first build of a version, and later builds may not need a full review. That is a separate rule from rejection. A later build can still need review if Apple asks for it, but once a build is rejected, the old build is dead for external testing and a new build is the only path forward.

A simple example helps. If build 41 is rejected for a crash on launch, build 41 stays rejected. Build 42 is the repair path. You upload build 42, attach the required TestFlight test information, send it to review, and wait for approval. After approval, external testers can install build 42. Build 41 does not come back, even if the code changes in your source tree are minimal.

If you are trying to save time, the wrong move is to keep inviting people to the rejected build or to assume App Store Connect will “unstick” it on its own. That build is already marked rejected and can no longer be used in TestFlight. The right move is to submit the corrected build again, because Apple’s review status is tied to the specific build you uploaded, not to the app in the abstract.

The part that slows teams down is that a rejected external beta can interrupt testing even when the code change is small. Apple’s docs explicitly tell you to review tester feedback, fix the issue, upload a new build, and continue testing. That means a rejection is not the end of the beta, but it is a hard cutoff for that build. If your release process depends on external testers, build numbering and resubmission discipline matter as much as the code fix itself.

If you want to keep the beta moving, use this checklist: read the rejection message in App Store Connect, fix the issue, create a new archive, increase the build number, upload the build, submit it for TestFlight review, and only then invite external testers again. Apple’s TestFlight help pages and tutorials all point to that same workflow.

DevConnect exists for the part before and after this step, not for bypassing it. If you need reciprocal testers while you wait on review, you can use your own testing workflow and your own app presence on DevConnect, but the App Store Connect review decision still controls when external TestFlight testers can see the build.

FAQ

Can I keep the same build number after a rejection No. The practical fix is to upload a new build. Apple’s tutorial tells you to update the build number before creating a new archive and distributing the updated build. Reusing the rejected build number keeps your process unclear and does not restore external access by itself.

Do internal testers lose access when an external build is rejected Apple’s public status pages focus on the rejected build no longer being usable in TestFlight for testing, and they distinguish internal and external workflows. If you need certainty about a specific tester group, check the build status and group assignment in App Store Connect, because the external review failure is the blocking step for public beta access.

Do I need to submit a new build for every fix When the fix changes the binary, yes, upload a new build. Apple’s docs say to incorporate changes, upload a new build, and continue testing. Later builds of the same version may not always need full review, but a rejected build never becomes usable again on its own.

Can external testers see the old build again if I just edit metadata No. Metadata edits do not revive a rejected build. Apple says rejected TestFlight builds can no longer be used in TestFlight, and the remedy is to upload a new build. If App Store Connect rejected the beta for missing or incorrect test information, update the required TestFlight fields and then submit the new build.

What should I do after the new build is approved Add the approved build to your external group if needed, then notify testers again. Apple says external testers get access by being added to an external group and invited by email or public link. Once the new build is approved, that is the point where your beta resumes.