Does replying in Resolution Center put you back at the end of the review queue?
Nobody outside Apple knows, because Apple has never published how the App Review queue is ordered. Any article that tells you a reply costs you 24 hours, or keeps your place, or sends you to the back, is making it up.
What can be nailed down is the difference between two actions people run together in the same sentence, because Apple treats them differently in its own documentation.
Replying in Resolution Center is a message. It is not a resubmission.
Resubmitting creates a new trip through review, and Apple does say what that costs.
Getting those two apart is most of the answer.
What Apple actually documents
On removing a version from review, App Store Connect Help is unambiguous:
"The app, and any other items in the submission, are removed from the queue and the app status changes to Developer Rejected. If you resubmit the review process will start over."
And for cancelling a whole submission:
"Your submission will be cancelled, and any items marked as Accepted must be resubmitted. If the submission includes an app version, its status will change to Developer Rejected. If you resubmit, the review process will start over."
That is the only place Apple uses the phrase "start over", and it is about a withdrawal you performed, not about a reply.
On replying, Apple's help page for App Review messages says something narrower:
"You can correspond with Apple and include attachments, such as screenshots and supporting documents, until you resubmit to App Review."
Note the boundary in that sentence. Correspondence and resubmission are separate events, and the correspondence window closes when you resubmit. Nothing there describes a queue position.
The status reference adds the same shape for a metadata rejection:
"App Review didn't accept your metadata. Read the message from App Review, edit the metadata to resolve the issue, and reply to the message from App Review."
Apple's instruction there is to fix and reply. It does not say resubmit. That is as far as the documentation goes.
The case where a reply alone ends the review
There is one flow Apple documents where a reply, with no new submission, gets your app approved. From the App Review page:
"If you're submitting a bug fix update for your app and we find additional issues during review, you have the option to resolve the additional issues with your next submission, as long as there are no legal or safety concerns. To accept, simply reply to the offer message in App Store Connect and indicate you would like the current submission to be approved."
If you get that offer message, read it before you touch anything else. A reply saying you accept can move a bug-fix update from rejected to approved without a rebuild, without a resubmission and without whatever the queue would have cost you.
People miss this constantly, because it arrives looking like an ordinary rejection.
What Apple has never published
Be clear about the size of the gap:
- Whether review is first in, first out at all
- Whether a resubmission enters at the same point a first submission would
- Whether the reviewer who saw your app sees it again
- How long a reply waits before anyone reads it
- Whether replying without resubmitting is even queued in the same system
None of that is documented, in the guidelines, in App Store Connect Help, or in the App Store Connect API reference. The API exposes a version state and a submission state. It does not expose a position, an estimate or a timestamp for anything except the state changes themselves.
The one number Apple does publish is an aggregate: "On average, 90% of submissions are reviewed in less than 24 hours." That covers submissions in general. It says nothing about replies, and nothing about where a resubmission lands.
What developers report
Worth reading as reports, not as findings, and worth noticing what the pattern looks like.
Forum threads on this question go back years and contradict each other. Some developers describe replies answered within hours and rejected versions turned around the same day. Others describe replies sitting for days on an app that had been reviewed inside 24 hours the first time. The same developer sometimes reports both experiences on consecutive releases of the same app.
That contradiction is itself the useful finding. If there were a stable rule, this many people asking the same question for this long would have found it. What the reports support is a weaker and more honest claim: outcomes vary enough that you cannot plan a release around a reply being fast, and you also should not assume a reply is a week lost.
One more thing developers report consistently enough to mention, and it is unverifiable from outside: a reply that answers the reviewer's actual question tends to end the round faster than one that argues with it. That is what you would expect, and it costs nothing to do anyway.
The practical rules, given the uncertainty
Reply once, completely. One message containing the fix, the evidence and working credentials beats three messages a day apart. Whatever the queue does, a thread with one clear answer in it is easier to close.
Do not reply and then resubmit ten minutes later. Apple's own wording says correspondence runs "until you resubmit", so a resubmission ends the conversation you just started. Decide which one you are doing.
Do not withdraw in order to restart. This is the one move Apple documents as costly: removing the version puts it in Developer Rejected and "the review process will start over". Withdrawing because you shipped the wrong build is sound. Withdrawing to shake the tree is not.
Fix the thing they cited, and only that. A resubmission carrying three unrequested changes gives the next reviewer three new things to have an opinion about.
Stop planning around the wait. Submit early, get approved, and hold the version in Pending Developer Release until your date. That is the only reliable answer to every version of this question.
What a reply that works looks like
Short, specific, and about their question:
"Guideline 2.1: the crash on the Import screen came from an unhandled nil when the file picker returned no selection. Fixed in build 412, attached. Steps: open Library, tap Import, cancel the picker. Demo account: review@example.com / Test-1234, valid until 30 September. Screen recording attached showing the cancel path on iOS 26.1."
That could plausibly close the round without another submission. An argument about whether the reviewer should have found the crash could not.
FAQ
Does replying in Resolution Center put me back at the end of the queue? Apple has not documented it, and developer reports contradict each other. Nobody can answer this with a source. Reply properly and do not plan the release around the timing.
Does resubmitting put me at the back of the queue? Apple says only that "the review process will start over" after you remove a version or cancel a submission. It does not describe a queue position for a resubmission after a rejection. Treat a resubmission as a fresh trip through Waiting for Review of unknown length.
Can I reply and resubmit at the same time? Not usefully. Correspondence runs "until you resubmit". If the fix is in the binary, resubmit with a note. If the fix is information the reviewer asked for, reply.
Does any of this apply to Google Play? No. Play has no reply thread. Its console states say "You can fix the issue and resubmit, or you can submit an appeal", and that is the whole set.
AppSubmit timestamps every state change on a version, including the silent move from Waiting for Review into In Review, so at least your own history of what took how long is recorded rather than remembered. It cannot tell you how Apple orders the queue, because Apple does not tell anyone.