"Developer Rejected" means you rejected it, not Apple

Developer Rejected means somebody with access to your App Store Connect account pulled the version out of the review queue. Apple did not reject it. Nobody at Apple looked at it and said no.

The state value is DEVELOPER_REJECTED, and the word order is what trips everyone up. It is not "Apple rejected the developer". It is "the developer did the rejecting", which in plain English means withdrawn.

If you did not do it, someone on your team did, or a tool connected to your account did.

Why it happens without you noticing

Three routes produce this state, and only one of them involves a human clicking a button in a browser.

Someone used "Remove from Review" in App Store Connect. A developer spotted a bad screenshot, a broken demo account, or a version number mistake and pulled the submission rather than let a reviewer find it.

A tool called the API. The App Store Connect API cancels a review submission with a PATCH to /v1/reviewSubmissions/{id} setting canceled: true. Note the single-l American spelling; it is a real gotcha when you are writing the call yourself. Any CI script, release tool or fastlane lane with that call wired to the wrong branch will withdraw a submission silently.

A submission was replaced. Push a new review submission while one is open and the old one has to go somewhere. Depending on how your tooling handles the conflict, the previous version can land in DEVELOPER_REJECTED rather than being merged.

The API will only cancel a submission that is actually in flight. The states it can act on are WAITING_FOR_REVIEW, IN_REVIEW and UNRESOLVED_ISSUES. Anything already decided is out of reach.

What you get back

Withdrawing returns the version to an editable state. That is the useful part: DEVELOPER_REJECTED sits in the same group as PREPARE_FOR_SUBMISSION, REJECTED and METADATA_REJECTED, so you can immediately change:

  • Description, keywords, promotional text and what's new
  • Screenshots and app previews
  • The attached build
  • Review notes and demo credentials
  • App name, subtitle and category, via the editable App Info record

The version number does not move. You are editing the same version record, not creating a new one. Bumping to a fresh version number after a withdrawal throws away the history for no benefit.

Withdrawing on purpose

Do it when the submission is definitely wrong and you would rather not spend a rejection on it.

  1. Open the version in App Store Connect. It will be in Waiting for Review or In Review.
  2. Use the option to remove it from review. Confirm.
  3. The state changes to Developer Rejected within a minute or two, and the version unlocks for editing.
  4. Fix the thing.
  5. Submit for review again.

Once you have withdrawn, you cannot un-withdraw. There is no "put it back where it was" button. You resubmit, and resubmission puts you at the back of the queue.

Apple publishes nothing about how the review queue is ordered, so treat a withdrawal as starting again from zero rather than keeping a slot. Anyone telling you a withdrawal costs a specific number of hours is guessing.

When withdrawing is the wrong move

If the app is already In Review, a reviewer may be part way through. Withdrawing at that moment does not erase what they saw. Two things follow from that:

  • If they had already found a problem, you may still get a Resolution Center message about it. Read it. It is free information about your next submission.
  • If your reason for withdrawing is a metadata fix, you may not need to withdraw at all. Metadata Rejected and Rejected both unlock the version anyway, and a rejection you were going to get regardless costs you nothing extra.

Withdrawing to dodge a rejection that is coming is not a strategy. Withdrawing because you shipped the wrong build, or your demo account expired last night, is exactly what the button is for.

Resubmitting

Nothing special is required. The version is editable, so:

  1. Make the change. Only the change. A withdrawal is not an invitation to rewrite the description.
  2. If the fix is in the binary, upload a new build with a higher build number and attach it to the same version. The version string stays as it is.
  3. If the fix is metadata or review notes, there is nothing to upload.
  4. Submit for review. Expect a fresh trip through Waiting for Review.
  5. Add a line to the review notes saying what changed, if the reviewer is likely to wonder. It costs you one sentence.

Telling it apart from the real rejections

Four states look similar in an email subject line and mean completely different things.

  • DEVELOPER_REJECTED is you. No reviewer, no message, version unlocked.
  • METADATA_REJECTED is Apple objecting to text or screenshots. No new build needed.
  • REJECTED is Apple objecting to the app. Usually a new build.
  • INVALID_BINARY is Apple's processing pipeline refusing the upload. No reviewer involved at all, and no Resolution Center message to read.

Only one of those four is your own doing, and it is the one whose name sounds most like an accusation.

If a version you were expecting to hear about has quietly gone Developer Rejected and nobody admits to it, check your CI logs and any release tooling with write access to App Store Connect before you start blaming Apple. The API call is a single line, and it does not ask twice.

AppSubmit labels this state "Withdrawn" on the release timeline rather than "Developer Rejected", and records who or what triggered it, because the state name is misleading often enough to be worth translating. App Store Connect's own activity log carries the same fact if you would rather read it there.

Last reviewed 2026-08-17. Apple and Google change their rules without notice, so check anything decision-critical against their live documentation.