Few things are more frustrating than a launch delayed by an app store rejection. Both Apple and Google review apps against published guidelines, and a rejection usually means fixing something and waiting for another review. The good news is that most rejections fall into a small number of predictable categories. Knowing them in advance lets you catch problems before a reviewer does. Policies evolve, so use this as a checklist of themes and confirm details against Apple's App Review Guidelines and the Google Play Developer Policy Center.
Why app store rejection happens
Store review exists to protect users from apps that crash, mislead, misuse data or exploit them financially, and to enforce each platform's business rules. Apple's review is generally regarded as stricter on design and business model questions, while Google relies heavily on automated checks plus policy enforcement that can also happen after an app is live. Either way, reviewers have limited time with your app. Anything that confuses them, breaks or looks unfinished invites rejection.
1. Crashes, bugs and broken features
What happens: the app crashes on launch, a button does nothing, or a screen shows an error. Reviewers test on current devices and OS versions, which may differ from your test devices.
How to avoid it: test release builds (not just debug builds) on a range of real devices, including the latest OS version. Use beta distribution through TestFlight and Google Play testing tracks. Make sure the backend the app depends on is live, reachable and not rate-limiting reviewers.
2. Reviewers cannot get in
What happens: the app requires a login and no working credentials were provided, or the account has no data so features cannot be seen. Hardware-dependent apps are rejected because the reviewer has no way to test them.
How to avoid it: provide a demo account with realistic sample data, in the review notes. Explain any setup steps. For apps that need special hardware or a location, explain how features work and consider providing a demo mode or a video.
3. Incomplete or placeholder content
What happens: "Lorem ipsum" text, test screens, "coming soon" sections, empty tabs, or links that go nowhere.
How to avoid it: walk through every screen in the release build before submitting. Remove or hide unfinished features entirely rather than leaving them visible.
4. Privacy problems
Privacy is one of the most frequent themes in rejections on both stores. Common issues:
- No privacy policy, or one that does not match what the app actually does.
- Data declarations (Apple's App Privacy details, Google's Data safety form) that omit data collected by third-party SDKs.
- Permission requests without a clear explanation, or for data the app does not obviously need.
- Tracking users across other companies' apps or websites on iOS without asking permission through App Tracking Transparency.
- Apps that let users create an account but give them no way to start account deletion from within the app, which Apple requires. Google Play likewise requires such apps to offer a way to request account deletion, including from outside the app.
How to avoid it: audit every SDK in the app, request permissions only at the moment they are needed with a clear purpose string, and keep the privacy policy and store declarations in sync with the code.
5. Payment rule violations
What happens: the app sells digital content or features, such as premium subscriptions, extra levels or unlocked functionality, using an external payment method where the platform requires its own in-app purchase system.
How to avoid it: understand the distinction both stores draw between digital goods consumed in the app and physical goods or services consumed outside it (such as deliveries, rides or event tickets), which can use ordinary payment gateways. Rules in this area have changed in several countries due to regulation, so check the current guidance for each market you sell in before designing your payment flow.
6. Too little functionality
What happens: Apple in particular rejects apps that offer little beyond a website wrapped in an app shell, or that provide so little value they do not feel like an app.
How to avoid it: make sure the app offers real native value: offline access, notifications, device features, or a genuinely app-like experience. If a mobile website would serve users just as well, consider whether a progressive web app is the better route.
7. Misleading metadata
What happens: screenshots show features the app lacks, the description makes claims it cannot back up, the name is stuffed with keywords, or other brands are referenced without permission.
How to avoid it: use real screenshots of the current version, describe features accurately and keep the name clean.
8. Login and account rules
What happens: the app forces account creation before showing anything useful, or offers third-party social login without meeting the platform's rules about login options.
How to avoid it: let users explore non-personal features before signing up where reasonable, and check the current login services rules in Apple's guidelines if you offer social login.
9. Copycat or spam apps
What happens: many near-identical apps submitted from the same template, or apps closely imitating popular ones.
How to avoid it: businesses that need one app per client or location should consider a single app with multiple accounts or locations inside it instead.
10. Platform-specific technical requirements
Google Play requires apps to target a recent Android API level, and both platforms require builds made with reasonably current SDKs. Sensitive Android permissions, such as background location or access to all files, need a declaration and justification. Check these before every release, not only the first.
A pre-submission checklist
| Check | Done? |
|---|---|
| Release build tested on current OS versions and real devices | |
| Demo account and review notes provided | |
| No placeholder content or dead ends | |
| Privacy policy and data declarations match the app and its SDKs | |
| In-app account deletion available if accounts can be created | |
| Payment flow follows current rules for each market | |
| Screenshots and description reflect the actual app | |
| Backend live with a valid SSL certificate |
For the last item, our SSL checker confirms the certificate on your API domain is valid and complete.
If you are rejected anyway
Read the message carefully; it usually cites the guideline concerned. Reply through App Store Connect or Play Console if something is unclear, or if you believe the reviewer misunderstood the app, explain politely with specifics. Both platforms offer an appeal route. Fix the issue properly rather than working around it, since the same problem may be caught later. Store submission and compliance checks are part of every mobile app development project we run.
Key takeaways
- Most rejections stem from crashes, reviewer access, unfinished content, privacy gaps, payment rules or thin functionality.
- Audit third-party SDKs so your privacy declarations are accurate.
- Give reviewers a demo account and clear notes.
- Policies change; recheck the official guidelines before each submission.