appeal.handled.tools · All rejection guides
Three things produce almost every 2.1, and the notice tells you which one you have.
The rejection carries a crash log plus the device and OS build the reviewer used. That is a finished bug report, better than most you get from users. Symbolicate it first. The cause is usually visible, and replying before you have the fix costs you a full review cycle.
This is the big one. Almost always one of:
App Review works out of California. If your backend geoblocks or rate-limits by IP, that is where you find out.
A dead link, a purchase that did nothing, placeholder copy still in the build. Frequently the real cause is a staging backend that had gone to sleep, or a build pointing at a host that only answers from inside your network. Check what the shipped binary was actually talking to before you write back.
2.1 is rarely an argument. You are handing over the thing they could not get.
Put working credentials in the reply and in App Review Information, both. Give a numbered path to whatever they could not reach, using the screen labels that appear in the app rather than your internal names. For anything unusual, record thirty seconds of it; that closes most of these in a single round.
One detail worth knowing: only upload a new binary if the code changed. A 2.1 caused by a missing password is answerable in Resolution Center against the build already sitting there, which is several days faster than starting a fresh submission.
Paste your rejection and what the app does. You get an appeal letter written for that exact notice, back within an hour, for $29 CAD. A full sample letter is on the front page so you can judge the writing before paying.
It is not legal advice and it is not a promise Apple says yes. When the rejection is one no letter fixes, the letter tells you that and what to change instead.