Among App Store rejections there is a kind that comes with no list of defects: Guideline 5.6 (Developer Code of Conduct), review suspended. It does not point at a line of code. It says the submission does not meet the quality standard for the store, and it gives a date before which replies and resubmissions will not be read. In the case we describe, the date was nine days out, and the standard was worded as "meaningful, polished, reliable".
This is from our own submissions. The most useful thing we learned is how to classify it.
It looks like a rejection, but it is a suspension
An ordinary rejection names something fixable, so the reflex "fix it and resubmit" is right. 5.6 is different. The message states when the restriction ends, which makes it the same shape as a quota reset or a cooldown: until the date, nothing you submit can succeed, and a better build does not get you around it.
Two consequences:
- Do not resubmit before the date. An early resubmission is not read, and it can look like ignoring the suspension. Count "not accepted yet" separately from real failures, otherwise a row of early attempts looks like effort and hides the real signal.
- Do not patch. There is no single bug to patch. Guessing what "not polished" means and changing code is more expensive than doing nothing.
What to do with the window
The standard is a human's impression after a few minutes on a device. Builds, tests and linters measure whether parts work, not whether the whole feels meaningful, polished and reliable, so all of them can be green while the suspension arrives. Spend the window on the thing the verdict is about:
- Audit like a stranger. On a clean device, install the build you last submitted and walk the core path as someone who has never seen the app: first launch, empty data, no network, an interruption and a return. Then look at the surfaces nobody files tickets about: empty states, error messages, the jolt when switching screens.
- Ask the plain questions. Who is it for, and what is it better than what they already have? Would you keep it on your own phone for a week? Show the store page to someone outside the project for ten seconds and ask those two questions. A vague answer means the gap is in the choice of product or how finished it is, not in the build process.
- Freeze automatic submission. Put the stop in front of the final irreversible submit call, not upstream, or another entry point walks around it. If you cannot freeze every submission path with one switch, your suspension is a convention, not a mechanism.
After the date
Resume with one small, controlled submission: the smallest and most confident one first. Resubmitting a whole backlog at once looks, from the other side, like a replay of whatever triggered the suspension. Once that one passes, release the rest.
One-minute check
Install your latest submitted build on a clean device and use only the core flow for five minutes. Count the moments you would not want to demonstrate to anyone. If your confidence rests only on green automated checks, that is exactly the gap this kind of verdict grows in.
These notes are from Obelisk Club's own submissions. Apple's wording and practice change; check the current App Review Guidelines and your own message for the exact terms and dates.