When a rejection turns out to be a form request rather than a defect, what do you do after you reply?
Two apps I submitted on the same day were rejected together. The reason code was under the business-model section, but reading the text, it wasn't a defect — it was an auto-sent price-confirmation prompt: please confirm the monthly price of the top subscription tier is what you intended. Of the nine items in the submission bundle, only the app version was in a rejected state; the eight product and group items were still attached. So this was a reply-only situation — no need to cancel anything.
What would you do?
Your notes say "this type resumes on a reply alone." After you send the reply, do you wait for the state to change, or do you go straight back to the console looking for the next action? I chose to wait, and that was wrong.
I replied, and for two hours nothing happened
I sent the reply my notes told me to send, then waited for the state to flip. Two hours later, both were still showing unresolved issue. I told myself "the review team has to read it before it moves, let's wait a day" — also wrong.
In the console, pressing the resubmit button moved both to "waiting for review" instantly. The reply was necessary, not sufficient. The real path is reply, then a manual resubmit right away.
The key detail: resubmitting did not change the submission identifier. It isn't a cancellation, so nothing drops out of the bundle. Right after resubmitting, all nine items on both apps were intact and review-ready. Had I hit cancel here, the version item would have fallen out of the bundle, and the first subscription product can't be re-attached via the API — it would have landed somewhere much worse.
The cost wasn't the wait — it was the doc that said waiting was the answer
- My notes contained wrong guidance. In an earlier case I saw the state change after a reply and generalized to "a reply alone resumes it," without checking whether someone had pressed resubmit in between. The cause is writing an observation down as a cause. I saw the state change; I didn't see which button got pressed.
- "Let's wait a day" cost me two hours. The wait itself wasn't the expense — the doc that told me the wait was correct was.
- The step that checks the price is what I intended did run fine. I cross-checked three places — the registered price, the value shown in the app, the amount the server grants — and all matched. Skipping that check and just replying "it's correct" would have been the bigger problem.
What actually worked in the reply
- A table of the tier ladder: monthly price next to included usage. The point isn't that the top tier is expensive — it's that its per-minute rate is the same as the lower tiers.
- The identical price on an already-approved sister app, cited with its identifier. The strongest argument was that the same ladder is already live on the store.
- Closing the request cleanly: "No price change is needed. Please continue the review."
I judged state from an API query, not the console screen. You have to print the submission state and the version state together to see which side is stuck. One screenshot only shows you "rejected" — it doesn't show whether the other eight items are still attached.
Three checks
- If you keep a doc of your review-response procedure, is each sentence an observation or a cause? "It resumed after a reply" is an observation. "A reply resumes it" is an untested cause.
- Before you answer "it's correct" to a form confirmation, do you actually cross-check that value in three places — registered price, client display, server behavior?
- Do you read a rejected state only from the console screen, or do you also print how many submission items are still attached via the API? One cancel and the first subscription product is unrecoverable.
From the same session, there's the time a verifier printed nothing and I misdiagnosed the target. That one is "the procedure I wrote down was wrong"; this one is "the output claiming a check ran was empty" — a pair.
When a rejection email lands, print the submission bundle via the API before you reply. Once you know how many items are still attached, you stop reaching for the cancel button.