The app store rejection reasons that actually matter aren't mysterious, they're published. Most app rejections aren't about a bad idea, they're about an incomplete submission. Apple's own 2024 App Store Transparency Report shows Performance issues, crashes, broken builds, missing demo accounts, cited in 1,235,471 rejections, more than every other guideline category combined (Safety, Business, Design, Legal, and Other totaled 1,173,605). Apple reviewed 7,771,599 app submissions that year and rejected 1,931,400 of them, close to one in four. Google Play's process works differently, it leans harder on automated policy checks like the Data safety declaration and sensitive-permissions review, but the underlying pattern is the same: most rejections trace back to something a developer could have caught before submitting, not a judgment call about whether the app should exist.
This guide walks through what actually gets flagged on each platform, using Apple's and Google's own guidelines and data rather than aggregated "top reasons" lists, so you know exactly what to check before you submit and what to do if you get rejected anyway.
What Are the Most Common App Store Rejection Reasons?
Apple groups every rejection under one of five guideline sections, and its 2024 App Store Transparency Report, the most recent edition Apple has published, gives the actual counts: Performance (1,235,471), Legal (445,696), Design (378,300), Business (209,845), Safety (116,105), and Other (23,659). Note that a single submission can be cited for more than one guideline, so these numbers add up to more than the 1,931,400 total rejections, but the ranking is unambiguous: Performance problems are cited more than every other category combined.
That single fact should reorder your pre-submission checklist. Founders tend to worry first about whether Apple will like their business model or their content, that's the Business and Legal buckets, a smaller share of rejections. The bigger, more avoidable risk is a crash, a broken login, or a reviewer who can't get past your sign-in screen because you forgot to include demo credentials.
What Specifically Triggers a Performance Rejection?
Apple's App Review Guidelines, Guideline 2.1 (App Completeness), spell out exactly what reviewers check: your submission should be a "final version with all necessary metadata and fully functional URLs," tested on-device for bugs and stability, and if your app has a login, it must include working demo account credentials with the backend turned on. The guideline is explicit that Apple will "reject incomplete app bundles and binaries that crash or exhibit obvious technical problems."
In practice, this bucket catches three things constantly:
Dead or placeholder content. Empty websites linked from your metadata, "lorem ipsum" screens left in a build, or a support URL that 404s. Guideline 2.1 says placeholder text and temporary content "should be scrubbed before submission."
No way in. If your app requires login and you didn't provide a demo account (or a working demo mode, which needs prior Apple approval), the reviewer is stuck at your sign-in screen. This is one of the single most common, and most avoidable, causes of a Performance rejection.
Crashes on the reviewer's device. Apple reviews on real hardware, not just a simulator. An edge case that never shows up on your test device, a slow network, a specific iOS version, a permission the reviewer denies, can crash a build that works fine for you.
Why Do Apps Get Rejected for Metadata, Minimum Functionality, or Spam?
These three sit under Apple's Design and Business categories, and they're less about bugs and more about honesty and substance.
Accurate Metadata (Guideline 2.3). Your screenshots, description, and previews have to reflect what the app actually does. Guideline 2.3.1 is specific: "Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review." Guideline 2.3.3 requires screenshots to show the app in use, not just a splash screen or login page.
Minimum Functionality (Guideline 4.2). Apple's own language is blunt: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." This is the guideline that catches MVPs that are really just a WebView wrapped around a website, if that's genuinely your architecture, you need enough native functionality (push notifications, offline support, device integrations) to justify being a native app at all.
Spam (Guideline 4.3). Submitting near-identical apps under different names, one map app per city instead of one searchable map, for example, or shipping an app that's "indistinguishable from what's already widely available" in a saturated category (Apple names dating, flashlight, and simple timer apps specifically) will get flagged even if each individual submission is bug-free.
What Are Google Play's Rejection Reasons, and How Is Its Process Different?
Google Play's review model is structured differently from Apple's. Instead of guideline sections tied to a single review pass, Google organizes its Developer Program Policies around categories, Impersonation, Intellectual Property, Privacy/Deception/Device Abuse, Monetization and Ads, Store Listing and Promotion, Spam/Functionality/User Experience, Malware, and Families, and enforces a meaningful share of them through automated scanning rather than a single human reviewer.
The most common friction point for legitimate apps is the Data safety section. Google's own instructions require every developer to declare, in Play Console, what data the app collects, how it's used, and who it's shared with, and that declaration has to match what your app actually does and what your privacy policy says. According to Google's Data safety guidance, the developer is responsible for the accuracy of that label and for keeping it current as the app changes.
Two other categories worth knowing before you submit, straight from Google's Prepare your app for review guidance: any app requesting a high-risk or sensitive permission, SMS or call log access being the named example, may need to clear a separate Permissions Declaration Form, and any app that gates content behind a login must supply working sign-in instructions on the App content page or reviewers can't get past the same wall Apple's reviewers hit.
Google also runs automated pre-review checks in Play Console before a submission ever reaches manual review, catching missing policy declarations and elevated crash rates on specific devices. It's the closest thing Google offers to a self-service pre-flight check, and it's worth running before every submission, not just your first.
Do AI Features Trigger Extra Review Scrutiny?
Yes, on Apple's side specifically, and it's a recent addition worth knowing if your app calls an external LLM or AI service. Guideline 5.1.2(i) of Apple's App Review Guidelines now states plainly: developers "must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so." If your app sends any user data, even a support message or a photo, to an external AI provider (OpenAI, Anthropic, Google, or your own hosted model counts as third-party from the user's perspective if it's off-device), that has to be disclosed and consented to before the data leaves the device, not buried in a general privacy policy you hope nobody reads.
This is a meaningful trap for founders bolting AI features onto an existing app quickly: your original privacy policy and Data collection disclosures may not have anticipated a new AI-powered feature, and shipping the feature without updating both the in-app consent flow and the App Store Connect privacy nutrition label is a straightforward 5.1.1/5.1.2 rejection. If you're building AI features into a mobile app, this disclosure step belongs in your spec from day one, not bolted on after a rejection.
How Do You Avoid Rejection Before You Submit?
Run through this before every submission, first-time or update:
Test the exact build you're submitting, on a real device, on the oldest OS version you still support. Not the simulator, not last week's build.
Include working demo credentials, or a pre-approved demo mode, if your app has a login. Turn the backend on before you submit. A reviewer who can't log in will reject on Guideline 2.1 every time, regardless of how good the app is past that screen.
Match your Data safety label (Google) or App Privacy nutrition label (Apple) to what the app actually does, not what it did three versions ago. Both platforms treat a mismatch between declared and observed behavior as a policy violation, not just a metadata error.
Remove every placeholder. Dead links, "Lorem ipsum," a support URL that doesn't resolve, unfinished settings screens. Guideline 2.1 exists specifically to catch these.
If you added a new AI feature, update your privacy policy and consent flow before you update your metadata. See the AI disclosure section above.
Check your category isn't already saturated with near-identical apps, and if it is, make sure your app's description and screenshots foreground what's genuinely different, not just cosmetically different.
If you're earlier in the process and haven't scoped the build yet, our guide on mobile app MVP development covers how to plan a first mobile release so the store review isn't the first time these questions come up.
What Happens After a Rejection?
On both platforms, a rejection is routine, not a strike against you. Apple's transparency data shows 295,109 apps were approved after being rejected and resubmitted in 2024, and a plain rejection doesn't affect your Apple Developer Program standing on its own; only repeated or egregious violations escalate to account-level action. Google's policy is explicit that rejections "don't impact the standing of your Google Play Developer account," and if an update gets rejected, your previously published version stays live while you fix the issue.
Both platforms also offer an appeals path if you believe the rejection was a mistake, Apple lets you request a call with App Review or file a written appeal, and Google's Play Console has an Appeal action directly on the Policy status page. Appeals make sense when you believe reviewers misread your app; if the guideline citation is accurate, it's almost always faster to fix the issue and resubmit than to argue the case.
FAQ
How long does app review actually take? Apple has stated that most submissions are reviewed within 24 hours, though this isn't a guarantee and can extend around major OS releases or holiday periods. Google Play's review times vary by app risk profile and developer history; new developer accounts and apps requesting sensitive permissions typically take longer than routine updates from an established account. Build a buffer into your launch timeline rather than assuming same-day approval.
Does a rejection hurt my developer account? No, not on its own, on either platform. Both Apple and Google state explicitly that a rejection doesn't affect account standing; it's repeated violations, fraud, or a suspension that escalates to account-level consequences.
What's the single most avoidable rejection reason? Based on Apple's own data, an incomplete or untested build, crashes, missing demo credentials, placeholder content, cited under Guideline 2.1. It's the largest single rejection category, and every cause within it is fixable before you submit.
Do AI-powered app features get extra scrutiny? On Apple's platform, yes, specifically around disclosing and getting consent for any personal data shared with a third-party AI service, per Guideline 5.1.2(i). Build that disclosure into your consent flow from the start rather than retrofitting it.
Can I appeal a rejection? Yes, on both platforms. Apple allows a written appeal or a call with App Review; Google Play has an Appeal action on the app's Policy status page. Appeals are for cases where you believe the review was mistaken, not a way to argue around a guideline you're genuinely violating.
Is Google Play's review process automated or manual? Both. Google runs automated pre-review checks and ongoing scanning (for Data safety mismatches, for example) alongside manual policy review for flagged apps. Apple's process is reviewer-driven, with automated malware and content scanning layered underneath.
Getting Your App Through Review the First Time
The pattern across both platforms is the same: most rejections are caught by the developer's own checklist, not by a reviewer finding something genuinely wrong with the product. A build tested on-device, working demo credentials, an accurate data disclosure, and no leftover placeholders will clear the large majority of what actually gets apps rejected.
If you're planning a mobile launch and want a team that's shepherded apps through both stores before, our mobile app development team handles the store-readiness work, demo accounts, privacy disclosures, permission declarations, alongside the build itself. You can see an example of a native iOS and Android app we shipped in our portfolio, or get in touch to talk through your launch timeline.