You submit.
You wait four days.
You get one line back, and it does not tell you what to fix.
So you guess. You change whatever feels most likely. You resubmit. You wait another four days.
That loop is the single most expensive thing in mobile development, and almost nobody budgets for it.
What I got wrong for years
I treated submission as a formality.
Build it, polish it, do the paperwork at the end.
That framing was my actual bug. Submission is a test with its own preconditions, run once, on a real device, by someone who has never seen your app and has no access to what you intended.
They are not being difficult. They have minutes and no context. If they cannot reach something, it does not exist.
Once that landed, every rejection I had collected stopped looking like bad luck. It started looking like a handful of gaps, repeating.
Rejection repeats
I went back through every rejection pattern I could document across both stores. They collapse into eight root causes, and all eight are process gaps rather than obscure rules.
Invisible feature. Nobody could reach it. No demo account, a backend paused to save cost during review, a flow behind a paywall they did not buy, a region locked screen. You broke no rule. You shipped something unreachable.
Declaration mismatch. Runtime behaviour disagrees with what you declared. Your privacy labels or Data Safety form say one thing, an SDK you never audited does another. A declaration is a contract, and a third party library can break it without telling you.
Payment shortcut. Routing digital goods around store billing. License keys, external checkout, a web link for in app content.
Thin wrapper. A website in a native shell, offering nothing the web version already does.
Spam signature. Near identical apps, duplicate bundle IDs, template builds. This one escalates past rejection into account level action, which is the part people underestimate.
Permission grab. A sensitive permission with no visible core feature behind it. Background location, all files access, call logs. Your real problem is the missing feature that would justify it.
Missing exit. You create accounts and offer no way to delete one. You collect data with no withdrawal path.
Compounding resubmit. Treating rejection as a coin flip and sending the same build back, hoping for a different reviewer. On Google that is the fastest documented route from rejection to suspension.
Read that list again and notice what is absent. None of them need obscure knowledge. Every one is something you would have caught by checking before you shipped rather than after someone told you.
Two of them sink most submissions
Fix nothing else this week. Fix these two.
A working demo account with a live backend at the moment of review. Not staging. Not a seat that expired. Not a flow you assume is obvious.
And a privacy declaration matching actual runtime behaviour, including every SDK you pulled in without reading. Apple wants the privacy manifest and the nutrition labels. Google wants the Data Safety form. Both are now the most common modern upload rejection, and both stay silent right up until they are not.
Boring, both of them. That is exactly why they keep winning.
Android is not Apple with different words
Shipping both, the trap is assuming one checklist covers you.
Apple rejects on discretionary review judgment. Guideline 4.2 minimum functionality and 4.3 spam get read by a person applying taste, so an identical app can pass or fail depending on how clearly you made its value visible.
Google rejects more mechanically and punishes harder. Policy violations stack toward suspension, target API levels run on a clock, foreground service types must be declared and justified, and a new personal developer account carries a closed testing requirement before you can go public at all.
One is a judgment call you have to make easy. Other one is a deadline you have to track. Treating them as a single problem is how you fail both.
What I did about it
I got tired of researching identical guidelines every submission, so I stopped keeping any of it in my head.
Everything I had learned went into an open repository. Rejection patterns mapped to the exact guideline and the exact fix, a pre submission checklist, regional regulatory changes, and a guard that runs against a project and names the risk while fixing it is still cheap.
It lives here if it helps. github.com/mjmirza/app-store-compliance
Free, open, MIT. Nothing sold on top of it. It exists because I did not want anyone else spending a week rediscovering what a one line rejection email refuses to explain.
Take what helps, ignore what does not, and tell me what is missing so I can fix it.
An opinion I will defend
Your submission checklist belongs at the start of a project.
Each of those eight gaps is cheap to design in on day one and expensive to retrofit on day ninety. Account deletion is a two hour feature before you have users and a migration after. A demo account is a config decision early and a scramble late. An SDK audit takes five minutes before you install and becomes archaeology after you shipped.
Most teams know these rules. They lose that week anyway, because rules arrive last.
Your turn
What is the most useless rejection message you have ever received?
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.
Top comments (0)