How to reject an App Store binary

Rejecting a binary removes that build from the version so you can attach a different one. It is a controlled reset, not a punishment. Use it when the attached build is wrong, broken, or no longer the candidate you want reviewed. This guide covers when to reject, what to expect, and how to do it in App Store Connect or Helm releases.

When rejecting is the right move

Reject when:

• You attached the wrong build (old commit, wrong scheme, missing fix)
• A critical bug appeared after you selected the build
• Export compliance or signing issues make that build unusable
• You need to swap candidates before or during a review cycle where Apple allows a replacement path

Do not reject casually after a version is live for customers. Live problems usually need a new version or a phased-release pause, not a binary reject on a shipping storefront state. See manage a phased release when the issue is rollout blast radius.

When to fix forward instead

Sometimes shipping a new build as a new submission is clearer than thrashing the current one:

• Review already returned notes that you will address in a fresh binary anyway
• The version metadata also needs a large rethink
• Multiple teammates are unsure which build was canonical

Pick one owner. Binary thrash with three “latest” builds is how teams lose a day.

What happens when you reject

Exact states depend on where the version sits (prepare for submission, waiting for review, in review, and so on). In practice:

1. The build is no longer the selected binary for that version.
2. You select a replacement build that has finished processing.
3. You re-check What’s New, screenshots, and review notes for consistency with the new binary.
4. You submit again if you had already entered the review queue.

Rejecting does not delete the build from your account’s build list. It detaches it from this version’s selection.

How to reject in App Store Connect

1. Open the app version that has the bad build selected.
2. Find the build section for that version.
3. Choose the reject / remove build action Apple shows for the current state.
4. Confirm.
5. Select the correct processed build.
6. Recheck compliance answers and review information.
7. Submit when the launch checklist is green again.

If the version is already in review, read the current ASC messaging carefully. Some states require waiting or a formal removal from review before you can swap.

How to reject in Helm

From Helm’s release workflow on Mac, iPhone, or via the CLI where supported:

1. Open the version.
2. Reject the binary from the same place you manage submit and release actions.
3. Attach the replacement build (or let auto-select fit your flow if you use it carefully).
4. Run through the launch checklist: What’s New, encryption, review info, screenshots, listing fields.
5. Submit when ready.

Helm is a native companion to the App Store Connect API. You can still deep-link or jump to the web version when you need ASC’s full page context.

Prevent the bad attach next time

• Name builds clearly in CI (version, build number, commit)
• Only promote builds that passed the smoke suite you trust
• Write What’s New after scope is frozen, then confirm it still matches the binary
• Keep one “candidate” build per version in team chat, not three
• Use the launch checklist before every submit (prepare guide)

Checklist after a reject

• Replacement build processed and selected
• Compliance answered for the new build
• Review notes and demo account still valid
• Screenshots still match the UI
• What’s New still accurate
• Team notified so nobody re-attaches the bad build

Related reading

• Releases in Helm
• Submit an app for review
• Prepare a launch checklist
• Export compliance and encryption
• Schedule an App Store release