Why App Store Rejection Costs More Than You Think
First-time Google Play submissions are rejected 20–30% of the time. App Store submissions fare worse - Apple rejects roughly 40% of new app submissions in the first round. Each rejection adds 3–14 days of delay.
For a startup burning runway, that delay isn't just inconvenient. It's expensive.
After submitting over 40 apps to both stores - and managing the rejections that came with them - here's every reason we've seen, and how to prevent them.
Google Play Rejection Reasons
1. Missing or incomplete privacy policy
Every app that handles any user data (including analytics, device IDs, or Firebase installations) requires a privacy policy. It must:
- Be accessible from within the app on the account creation or settings screen
- Be linked in the Play Console store listing
- Cover what data you collect, how you use it, and how to delete it
A Google Docs link is technically acceptable but looks unprofessional. Build a `/privacy` page into your app's domain.
2. Incomplete Data Safety form
Google's Data Safety section requires you to declare every type of data your app collects, including data collected by your SDKs (Firebase, Crashlytics, Adjust, etc.). Most first-time submissions miss at least one SDK's data collection.
Before submitting, audit every library in your app and cross-reference it with Google's documentation on SDK data disclosure requirements.
3. Screenshot mismatch
Screenshots must accurately represent the current app experience. Using a Figma mockup, a web version, or an older build version will result in rejection.
Capture screenshots directly from a physical device or high-fidelity emulator running the exact build you're submitting.
4. Content rating submitted incorrectly
The IARC content rating questionnaire must reflect every content type in your app. Answering "no" to violence categories when your app has even cartoon conflict, or "no" to user-generated content when you have reviews, will get you rejected or your rating changed post-launch.
For kids apps (COPPA-compliant, targeting under-13s): you must answer the questionnaire accordingly AND enable "Designed for Families" settings.
5. Permissions not justified
Every sensitive permission (camera, microphone, location, contacts, storage) requires a clear in-app rationale before the system dialog appears. If Google's reviewers can't understand why your app needs a permission based on your store description, you'll be asked to justify it or remove it.
6. APK size optimization
Google recommends Android App Bundles (.aab) over APKs (.apk). Apps submitted as APKs larger than 100MB are flagged. Enable R8 full mode and resource shrinking.
7. Impersonation or misleading metadata
App name, icon, and description cannot imply affiliation with brands you're not affiliated with. A teleprompter app named "Apple Teleprompter" or an icon that resembles WhatsApp's will be rejected.
8. Broken or incomplete functionality
Google's reviewers test your app. Crash on launch, login flows that don't work, buttons that do nothing, features listed in the description that are missing - all cause rejection. Test on a stock Android device, not just your development machine.
App Store (Apple) Rejection Reasons
9. Missing "Sign in with Apple"
Guideline 4.8: If your app supports third-party login (Google, Facebook, Twitter, etc.), you must also support Sign in with Apple. No exceptions. Implementing it takes 2–4 hours with the right library.
10. In-app purchases not using StoreKit
Guideline 3.1.1: If your app sells digital goods, subscriptions, or features, they must use Apple's in-app purchase system. You cannot link to a website to complete a digital purchase, prompt users to use a cheaper external option, or even mention a lower price elsewhere in the app UI.
This rule has minor exceptions for "reader" apps (Netflix, Spotify) and user-generated content. For everything else, StoreKit is mandatory.
11. App crashes or has significant bugs
Apple's reviewers test on physical devices. Any crash, hang, or broken primary flow is automatic rejection. Always test on the oldest supported iOS version your app claims to support.
12. Incomplete information for review
If your app requires login, provide Apple with demo credentials. If it requires a specific device (e.g., Apple Watch), say so in the review notes. If there are features only available to certain account types, explain how to access them. Reviewers will not dig - they'll reject.
13. Privacy nutrition label inaccurate
Apple's privacy labels in App Store Connect must accurately reflect all data collection - including what your third-party analytics and crash reporting SDKs collect. Firebase alone collects identifiers and usage data that must be disclosed.
14. Guideline 2.1 - App completeness
Apple will reject apps that look unfinished: placeholder content, "Lorem ipsum" text, missing icons, broken navigation, empty settings screens. Submit when your app is genuinely complete, not when the core flow is done.
15. Kids category violations
If your app is in the Kids category:
- No third-party advertising SDKs (including Firebase Analytics)
- No third-party data collection SDKs
- No in-app purchases without parental gate
- No links out of the app without parental gate
- No social features without moderation
These rules are strictly enforced. The Animal Kingdom Hub app we built is Kids category compliant - it took significant effort to remove every SDK that wasn't compliant.
16. Guideline 4.2 - Minimum functionality
Apple will reject apps that are "not useful" - single-feature apps with no clear value, apps that just display a website, simple timer apps without meaningful differentiation. If your app concept is simple, the execution needs to be exceptionally polished.
17. Screenshots not from a device
App Store screenshots must come from the device/simulator matching the required sizes (6.7", 6.5", 12.9" iPad). Designed screenshots (with marketing frames, text overlays, etc.) are allowed but the underlying screen must be real. Figma mockups are not acceptable.
18. Guideline 5.1.1 - Location data
If you request location permission, your app must explain exactly why within the permission dialog. Generic explanations ("for a better experience") are rejected. "To show restaurants near you" or "to display your location on the map" are accepted.
Both Stores: Universal Rejection Reasons
19. Third-party payment prompting
Neither Apple nor Google allows apps to prompt users to pay outside the store for digital goods. "Save 20% by subscribing at our website" in your app UI is grounds for rejection on both platforms.
20. Inadequate content moderation
Apps with user-generated content must have a content reporting mechanism, a moderation policy, and a way to block users. Speed dating platforms, social apps, and review systems are commonly flagged here.
21. Misleading subscription descriptions
Subscription terms must be clearly stated: price, billing period, and cancellation policy must be displayed before purchase and in the app description. Hiding the price until after signup is rejected on both platforms.
22. Outdated API usage
Both stores retire API support on a schedule. Targeting deprecated SDK versions, using UIWebView instead of WKWebView, or using legacy Bluetooth APIs without justification will result in rejection or removal from store.
23. Invalid binary or build configuration
Common build errors: submitting a debug build instead of a release build, missing required entitlements (push notifications declared but entitlement not added), incorrect bundle identifiers, or code signing errors. Always do a full clean build before submission.
Our Pre-Submission Checklist
Before every submission, we run through:
- [ ] Privacy policy live and linked
- [ ] All permissions have in-app rationale dialogs
- [ ] Screenshots from device matching required sizes
- [ ] Login tested on fresh install with demo account
- [ ] No crashes on oldest supported OS version
- [ ] Content rating questionnaire completed accurately
- [ ] Data safety / privacy label accurate (including SDKs)
- [ ] Sign in with Apple implemented (if any social login)
- [ ] StoreKit implemented for all digital purchases
- [ ] Subscription terms visible before purchase
- [ ] Review notes filled out with demo credentials and any special instructions
- [ ] Release build, not debug
- [ ] App tested on physical device, not only simulator
This list has saved our clients months of delay.