Another developer here, not Apple, so I can't see the queue. But you can confirm the two things that matter yourself: The resubmission carries the new build. The version page's Build section should show the new build number. Over the API: GET /v1/appStoreVersions/{versionId}/build. Worth reading back even if you are sure you attached it; the attach call (PATCH .../relationships/build) answers 204 whether or not it took. The submission is queued. GET /v1/reviewSubmissions/{submissionId}?fields[reviewSubmissions]=state should read WAITING_FOR_REVIEW, and the version's appStoreState the same. After a rejection, the resubmission reuses the rejected submission's id, so seeing the old id there is expected. If a second, empty submission shows up under Draft Submissions, that is a stray container from an earlier attempt; remove it there. If both read that way, nothing else is needed from your side; the next state is IN_REVIEW. One more thing to check while you wait: which inbox review mail actually goes to (Users and Access → your user → Notifications, plus the Account Holder's address). On one of our apps the verdict went to a mailbox nobody read, and we saw REJECTED in the API four days before anyone saw the email. Free scripts for the read-back checks, MIT: https://github.com/vskromny/appstore-release-kit

Not an Apple answer, but I have hit the edges of this from the API side, so here is what I can confirm and what I can't. What I have seen myself: A reviewSubmission you create and never submit cannot be released over the API. PATCH /v1/reviewSubmissions/{id} with canceled=true answers 409 "Resource is not in cancellable state" for anything that was never submitted, and there is no DELETE on the resource. My own empty drafts from experimenting are still sitting there. A submission that came back rejected (UNRESOLVED_ISSUES) does not accept new items either: POST /v1/reviewSubmissionItems answers 409 "reviewSubmission state does not allow adding more items". So "reuse an existing one" has to be limited to READY_FOR_REVIEW, as you wrote. What another developer reported, not verified by me: unsubmitted drafts do count toward the limit of 5, and the way they cleared theirs was the "Draft Submissions" panel in the App Store Connect web UI, or by adding items into one of the stale drafts and submitting it instead of creating a new one: https://github.com/nulljosh/epiphany/issues/28 So your batching plan looks right to me, with one addition: never create a new reviewSubmission as a retry step. Look up the existing READY_FOR_REVIEW one first (GET /v1/apps/{id}/reviewSubmissions filtered by state) and only create when none exists, otherwise every failed retry leaves a slot-eating draft you can only clear from the browser. What I don't know: whether 5 is fixed or per-account, and whether Apple ever expires unsubmitted drafts on its own. I have not seen one disappear.

The missing + and - is not a UI bug. A version in Ready for Review is already inside a review submission, and its build relationship is frozen while that submission is open. The buttons come back once the version is out of it. Two ways out, depending on what you want. If you want to keep the submission, cancel it first. In the web UI that is "Remove from Review" on the version page; over the API it is PATCH /v1/reviewSubmissions/{id} with canceled=true — note this only works on a submission that has actually been submitted. Then attach the build and submit again. If the version was rejected rather than waiting, just attach the new build. That alone moves the version back to PREPARE_FOR_SUBMISSION and an "Update Review" button appears, which resubmits with the new binary. On your other question, deleting the version: I would not. The review thread hangs off the submission, and Apple exposes no DELETE for reviewSubmissions at all, so deleting the version is a bigger and less reversible move than cancelling the submission. When you do attach the build, read the relationship back rather than trusting the response. PATCH .../relationships/build returns 204 either way; GET /v1/appStoreVersions/{id}/build is the actual check. Script that does both, MIT, no dependencies: https://github.com/vskromny/appstore-release-kit

409 This resource cannot be reviewed, please check associated errors to see why" on the appStoreVersion has, in my case, nothing to do with metadata. It means the version is still inside an existing review submission. After a rejection the version stays a member of the rejected reviewSubmission (state UNRESOLVED_ISSUES), and every path out of it answers 409: POST /v1/reviewSubmissionItems with that version into a new submission: 409, "This resource cannot be reviewed". POST /v1/reviewSubmissionItems into the old submission: 409, "reviewSubmission state does not allow adding more items". PATCH /v1/reviewSubmissions/{old} with submitted=true: the same 409. PATCH /v1/reviewSubmissions/{new} with canceled=true: 409, "Resource is not in cancellable state". Only a submitted submission can be cancelled, so an empty container you create while experimenting cannot be deleted at all — there is no DELETE for it either. Mine are still sitting there. What actually clears it is attaching a new build to the version. That flips the version out of REJECTED back to PREPARE_FOR_SUBMISSION, and then the web UI grows an "Update Review" button on the version page. Pressing it resubmits the same submission with the new build. That is why a new build "fixed" it for davidm230 — the build is not the fix in itself, it is what unlocks the version. As far as I can tell that last step is web-only. I could not find any API path that performs it, and all four calls above fail. Happy to be corrected if someone knows the endpoint. One thing worth checking while you are there: attaching a build does not happen by uploading it. The version keeps whatever build was attached last — mine sat on an old build for three weeks while six newer ones uploaded "successfully". The relationship is PATCH /v1/appStoreVersions/{id}/relationships/build, and it answers 204 whether or not it took, so read it back with GET /v1/appStoreVersions/{id}/build. I wrapped that read-back into a small MIT-licensed script if it saves anyone the typing: https://github.com/vskromny/appstore-release-kit — Node, no dependencies, ASC API key only.