Nothing kills launch momentum like a store rejection: 1–3 days lost per round-trip, and some issues (privacy declarations, ad behaviour) can trigger repeat rejections that stretch into weeks. We deal with Google Play and App Store review constantly — for clients and for our own apps — and the same small set of problems causes almost every rejection we see.
The privacy paperwork most teams get wrong
Google's Data Safety form and Apple's Privacy Nutrition Labels must match what your SDKs actually collect — not what you think your app collects. An analytics or ads SDK quietly transmitting device identifiers, while your form says "no data collected", is an instant flag. We audit the SDK list first, then fill the forms from evidence.
On iOS, a vague App Tracking Transparency string is an automatic 5.1.1 rejection. The purpose string must say specifically what tracking enables, with a concrete example — generic "used to improve experience" wording fails.
Ad behaviour that survives review
- No interstitials at app open, right after app open, or immediately after a rewarded ad.
- Frequency caps on app-open ads (we default to one per 5 minutes).
- Consent (UMP/GDPR) shown before personalized ads in required regions.
- No ads that can be triggered accidentally by expected taps.
The rest of the checklist
- Minimal permissions — every extra permission is a question from a reviewer.
- Target API level current, 64-bit only, App Bundle signed correctly.
- Login demo credentials provided in review notes when auth exists.
- Screenshots that show the real app — not device frames full of marketing text.
- Support URL, privacy policy URL live and matching the app's behaviour.
The rejection codes you will actually meet
- Apple 2.1 (App Completeness): crashes, broken links, or a login the reviewer cannot pass — always attach working demo credentials and test on a clean device first.
- Apple 4.3 (Spam/Design): template-looking apps. Differentiated UI, real content and your own assets are the fix — critical for reskins.
- Apple 5.1.1 (Data Collection): vague ATT/permission purpose strings. Be specific and give an example in the string itself.
- Play "Data safety inaccuracy": your form vs actual SDK traffic. Audit SDKs, then declare — not the other way around.
- Play "Broken functionality": ANRs and crashes in pre-launch report. Fix everything the report flags before submitting.
- Play Families/Ads policy: if your app can appeal to kids, ad content ratings and consent handling get stricter — decide your target-audience declaration deliberately.
If you do get rejected
Reply inside the review conversation, be specific, and change something real before resubmitting — repeat identical binaries irritate reviewers and slow you down. For Apple, a clear note explaining exactly where the fix is (screen, flow, build number) regularly turns a second review around in under 24 hours. For Play, fix the flagged policy item everywhere it appears, not just where the bot found it; automated re-checks scan the whole app.
Keep a copy of every form answer you submit (data safety, ATT strings, content ratings). Six months later, when a policy email arrives, knowing exactly what you declared is the difference between a 10-minute fix and a week of archaeology.
Why we publish for clients
This is exactly why our customization and development packages include store submission: the paperwork is where launches stall, and we have already made these mistakes on our own apps so you do not have to make them on yours. If a build we submit gets rejected, fixing it is our job at no extra cost.