An app is most often rejected for these reasons: it crashes or shows obvious bugs during review (Apple Guideline 2.1); it has a missing or unreachable privacy policy and its declared data collection does not match its actual behavior; it does not provide a working demo/test account for the reviewer; its store metadata and screenshots are misleading; or it is a "wrapper" app that merely mirrors a website without adding value. The good news: almost every rejection reason can be fixed and resubmitted — and most can be prevented up front with a proper pre-launch checklist. Below we break down the most common rejection reasons for the App Store and Google Play, and how to prevent each one.
The most common App Store rejection reasons
Apple’s review is the stricter of the two stores and is carried out by human reviewers. The most frequent reasons map to specific sections of the App Store Review Guidelines:
- Guideline 2.1 — App incomplete or buggy: crashes, blank screens, non-working buttons or "coming soon" sections during review. This is the single most common rejection reason.
- Guideline 5.1.1 — Privacy: a missing privacy policy link, requesting permissions without explaining why, or an App Privacy ("Nutrition Label") declaration that does not match real data collection.
- Guideline 2.3 — Misleading metadata: screenshots, description or app name that do not reflect what the app actually does.
- Guideline 3.1.1 — Payments: selling digital content/subscriptions through an external payment flow instead of Apple’s In-App Purchase.
- Guideline 4.2 — Minimum functionality: "wrapper" apps that only display a website and add no app-specific value.
- Missing demo account: apps that require login but do not include a working test account and, where needed, instructions — if the reviewer cannot get in, the app is rejected outright.
A significant share of apps submitted to the App Store are rejected on first review — but a rejection is not a permanent block. It does not mean "no"; it means "fix this first." Once the issue is resolved and resubmitted, the app is usually approved.
The most common Google Play rejection reasons
Google Play review is largely automated and focuses on policy violations. The most common suspension and rejection reasons are:
- Data Safety form vs. real behavior mismatch: the data the app actually collects differs from what the form declares.
- Missing or invalid privacy policy: an accessible privacy policy URL is mandatory for any app that collects personal data.
- Permission misuse: requesting sensitive permissions such as SMS, call log or "all files access" without justification.
- Deceptive behavior and content: fake functionality, spam, copycat apps, trademark/copyright infringement.
- Outdated target API level: Google Play requires new apps to target a recent Android API level; an old target version blocks the upload.
- Ads and monetization policy violations: deceptive ads or unauthorized use of personal data.
The shared rejection reason: privacy and permission declarations
For both Apple and Google, the fastest-growing rejection category is privacy. Each store wants you to declare what data your app collects and why, and to match that against real behavior. On iOS, for example, an app that accesses the camera must explicitly state why it requests the permission in Info.plist; if that purpose string is missing, the app is rejected:
<!-- iOS: Info.plist — a missing usage-purpose string triggers rejection -->
<key>NSCameraUsageDescription</key>
<string>Camera access is needed to take your profile photo.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Access is needed so you can pick a photo from your gallery.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>We use your location to show you the nearest branch.</string>The same logic applies to Android’s "Data Safety" form: you must correctly mark every data type you collect and its purpose. Your privacy policy page is also mandatory, both for the stores and for KVKK/GDPR compliance.
A checklist to avoid app rejection
- Test on all devices and screen sizes; never submit a review build with crashes or bugs.
- Add an accessible privacy policy URL and match the data declaration forms (App Privacy / Data Safety) to real behavior.
- For apps that require login, provide a working demo account and test instructions where needed.
- Make sure screenshots, description and app name match the real functionality exactly.
- Write a clear justification for every permission you request; remove permissions you do not use.
- If you sell digital goods, use the store’s own payment system (IAP / Google Play Billing).
- Make sure the app offers more than a website — that it adds real app value.
My app was rejected — what now?
A rejection is not the end; it is a fix-and-resubmit loop. The store tells you the reason and usually the specific guideline. What to do: read the reason carefully, fix the issue and resubmit. If you believe the rejection is unfair, you can appeal and add an explanation via Apple’s Resolution Center or the Google Play Console. On resubmission, review is usually faster than the first time. We walk through the entire publishing process — from account setup to assets and review cycles — step by step in our mobile app publishing guide; for developer account fees, see our app publishing fees article.
Conclusion
Almost every reason an app gets rejected is predictable and preventable: leave no crashes, fill in the privacy declarations correctly, provide a working demo account and follow store policies. These steps raise your chance of first-pass approval and prevent the fix-and-resubmit cycles that can add weeks to your launch schedule. If you want your app developed and published smoothly on both stores end to end, take a look at our mobile app service or request a free quote for your project.