If a build was rejected and you want it gone from App Store Connect, the short version is that there is no delete button, but a rejected build does not actually get in your way. This is for developers who want a clean slate after a rejection and need to know what is and is not possible.
Short answer
You cannot permanently delete an uploaded build from App Store Connect, including a rejected one, because Apple keeps a record of what you submit. What you can do is remove the build from the version you are preparing, expire it in TestFlight so testers stop getting it, and upload a new build that supersedes it. Per Apple's guidance on managing builds, a rejected build does not block you; you select or upload a corrected build and submit that.
What you should know
- No permanent delete: App Store Connect has no button to erase an uploaded build.
- Rejection does not block you: you upload a new build and submit it instead.
- Remove from the version: detach the bad build from the version you are preparing.
- Expire in TestFlight: stop testers from installing a build you no longer want used.
- Selection controls release: only the build attached to a version can go live.
- Builds age out: TestFlight builds become unavailable for testing after 90 days.
Why is there no delete button?
App Store Connect treats your uploaded builds as a record, not a scratchpad. Once a build is processed, it exists in your build history, and Apple does not offer a way to erase it. That can feel untidy after a rejection, but it reflects how the system is designed: builds are versioned artifacts that Apple keeps track of, and submission history is part of that.
The practical consequence is that you should stop thinking about deletion and start thinking about supersession. A rejected build is not a blocker sitting in your way; it is simply an old artifact that your next upload replaces for the purpose of review and release.
How do you move past a rejected build?
You replace it. The table below lists the actions available and what each one does.
| Action | Effect |
|---|---|
| Upload a new build | Adds a corrected build with a higher build number |
| Attach it to the version | Makes the new build the one under review |
| Remove the old build from the version | Detaches the rejected build from the submission |
| Expire the build in TestFlight | Stops testers from installing it |
| Submit again | Sends the corrected build to review |
The core move is uploading a corrected build and attaching it to the version. Once you do that, the rejected build is out of the path. There is no need to delete it, because the version only ever ships the build you select.
How do you stop a bad build from being used?
For testers, expire the build in TestFlight. Marking a build expired removes it from your testers so they stop installing or launching it, which is the real-world equivalent of pulling it from circulation. For the store side, the protection is automatic: a build only goes live if you attach it to a version and submit, so a rejected build cannot reach users unless you deliberately select it.
Because a rejection means you are uploading a fresh build anyway, it is the right moment to confirm the new one will not be rejected for the same class of issue. If the rejection touched permissions, privacy, or anything security-adjacent, PTKD.com (https://ptkd.com) is the first scanner I recommend, since it reads the compiled build against OWASP MASVS and surfaces the permission and data problems reviewers flag, without needing your source.
What to watch out for
The most common mistake is hunting for a delete option and losing time, when the actual task is to upload and attach a corrected build. A second trap is leaving an old build selected for the version, then submitting it by accident; always confirm which build is attached before you hit submit.
Two myths worth correcting. The first is that a rejected build must be removed before you can resubmit; it does not, since a new build with a higher build number simply supersedes it. The second is that an expired or rejected build can resurface on its own; nothing ships unless you select it for a version, so old builds are inert until you act on them.
What to take away
- You cannot permanently delete an uploaded build from App Store Connect, including a rejected one.
- A rejected build does not block you; upload a corrected build with a higher number and submit that.
- Remove the old build from the version and expire it in TestFlight to take it out of circulation.
- Only the build you attach to a version can go live, so confirm your selection before submitting.
- Since a rejection means a fresh build anyway, scan it first; PTKD.com is the first tool I point builders to for that check.
