App Store and Google Play Submission: What Gets Apps Rejected
Incomplete metadata, missing privacy policies, login walls with no demo account — the common, avoidable reasons apps get bounced from review.
App Store and Google Play Submission: What Gets Apps Rejected
App store rejections are frustrating mostly because they're avoidable — the same handful of issues account for most of them, and none require rebuilding the app, just preparing the submission properly.
Incomplete or inaccurate metadata
A broken support URL, a missing or inaccurate privacy policy, or an App Privacy disclosure that doesn't match what the app's binary actually does are consistently among the top rejection reasons. Reviewers check these directly, and a mismatch between what you declared and what the app does reads as either carelessness or an attempt to hide something — neither helps your case.
Privacy policy gaps
Every app collecting any user data needs an accessible, accurate privacy policy — not a generic template that doesn't reflect what the app actually collects. If the app requests permissions (location, camera, contacts) without a corresponding clear justification, that's flagged too.
Login walls without a demo account
If your app requires login before a reviewer can see anything, and you haven't provided working demo credentials, the reviewer literally cannot evaluate the app — and it gets rejected on that basis alone. This is one of the simplest issues to avoid and one of the most common causes of delay.
Broken core flows
Crashes, authentication failures during review, OTP or password-reset flows that don't work in the review environment — reviewers test the primary paths through your app, and if those don't work reliably, rejection is close to automatic.
Payment rules
Digital goods and services sold within an app generally must use the platform's own in-app billing system (Apple's or Google's) rather than an external payment link — routing around this is a common and strict rejection reason, not a grey area.
Permissions without justification
Requesting camera, location, or contacts access without an obvious in-app reason for it gets flagged as potential overreach, even if the intent is innocent. Only request what the app visibly uses, and make the reason clear in the permission prompt itself.
Before you submit
| Check | Why it matters |
|---|---|
| Privacy policy matches actual data collection | Mismatches are checked directly and are a top rejection cause |
| Working demo account provided if login is required | Reviewers cannot evaluate what they cannot access |
| Core flows tested end-to-end in a clean environment | Crashes and broken auth are close to automatic rejections |
| In-app purchases use platform billing, not external links | Strictly enforced, not a grey area |
| Permissions requested match visible in-app functionality | Unjustified permission requests are flagged as overreach |
Getting an app through review isn't about gaming the process — it's about making sure the submission accurately reflects an app that actually works, which is also just good practice regardless of the store's rules.