A rejected app store submission isn't just a delay — it's a delay you often didn't need to have. Here are the specific, recurring reasons Apple and Google reject apps, and how to catch them before you submit.
A rejected app submission rarely feels like a technical problem when it happens — it feels like a schedule problem, arriving right when a launch date was already public, a marketing budget was already committed, or a client demo was already booked. The frustrating part is that most rejections are avoidable, and they cluster around a small, well-documented set of causes that show up again and again across both Apple's App Store review and Google Play's policy review. Knowing that list before submission turns app store review from a source of anxiety into a routine step.
Why Rejections Happen More Than Teams Expect
Apple's App Store review is a mix of automated checks and human reviewers who spend a genuinely short amount of time per app, testing core flows rather than every screen. Google Play leans more heavily on automated policy scanning with human review reserved for flagged or high-risk categories. Neither process is designed to catch every possible flaw in an app — both are designed to catch a specific set of guideline violations, which means the rejections that happen are rarely random bad luck. They're almost always one of a recognizable handful of issues.
Crashes and Bugs During the Reviewer's Core Flow
The single most common Apple rejection reason has nothing to do with policy interpretation — it's simply that the app crashed, froze, or showed a broken screen while the reviewer was testing it. Reviewers typically go through onboarding, core navigation, and any obvious primary action (checkout, sign-up, the main feature) rather than exhaustively testing every corner of the app, which means the fix isn't "test everything perfectly" — it's "make absolutely certain the primary path a new user would take, start to finish, has zero crashes or dead ends." This includes testing on the actual minimum supported OS version, not just the newest one, since bugs that only appear on an older OS version are a frequent, avoidable cause of rejection.
Incomplete or Placeholder Content
Apps submitted with "Lorem ipsum" text, broken image links, unfinished screens, or features that are visibly still in progress get rejected reliably, because reviewers treat an incomplete-looking app as evidence the submission itself was premature. This extends to demo accounts: if the app requires login to see anything meaningful, Apple explicitly requires a working demo account be provided in the review notes, and a missing or non-functional demo account is one of the most common, entirely preventable rejection reasons for any app with a login wall.
Guideline Violations Around Payments
This is the single area where Apple and Google enforce with the least flexibility. Both platforms require that any digital goods or services consumed within the app — subscriptions, premium features, virtual currency, unlockable content — go through their respective in-app purchase systems, not an external payment link or a "pay on our website" workaround. Apps that sell physical goods or services consumed outside the app (an e-commerce app selling real products, a ride-hailing app, a food delivery app) are the recognized exception and can use standard external payment processing. The mistake teams make is assuming this exception applies more broadly than it does — a subscription-based content or software app trying to route around in-app purchase fees by linking to an external checkout page is one of the most consistently rejected patterns on both platforms, and appeals rarely succeed because it's a firm policy line, not a judgment call.
Privacy and Data Collection Gaps
Both platforms have tightened privacy review substantially over recent years, and this is now one of the fastest-growing rejection categories. Common triggers include a privacy policy link that's missing, broken, or doesn't actually describe what the app collects; requesting a device permission (location, camera, contacts, notifications) without a clear in-context explanation of why the app needs it; and, on iOS specifically, an incomplete or inaccurate App Privacy "nutrition label" that doesn't match what the app's code actually does — Apple has automated tooling that checks declared data collection against actual app behavior, and a mismatch is flagged reliably. The fix is straightforward but requires discipline: request each permission only immediately before the feature that needs it, with a short explanation string that says specifically why, and keep the privacy policy and privacy label in sync with what the app genuinely collects, not a generic template copied from elsewhere.
Misleading Metadata and Screenshots
App store listings get rejected, or approved apps get pulled later, when screenshots show features that don't exist in the actual app, when the app's description makes claims the app doesn't deliver on, or when the app's icon or name is confusingly similar to an established app or brand. This category is worth extra care because it's entirely within a team's control and has zero technical complexity to fix — it just requires the marketing and product teams to align the store listing with the actual, current state of the app rather than an aspirational one.
Insufficient App Functionality ("Minimum Functionality")
Apple in particular rejects apps that feel like a thin wrapper around a website, a single feature that could have been a web page, or content that isn't meaningfully different from a mobile browser experience. This guideline exists specifically to filter out low-effort app-ification of existing web content. The practical implication for scoping an MVP is that the app needs at least one piece of functionality that meaningfully benefits from being a native app — offline access, push notifications tied to real value, camera or sensor integration, or a genuinely app-native interaction model — not just a container displaying a website inside app chrome.
Google Play's Distinct Risk Areas
Google Play review overlaps heavily with Apple's on crashes, privacy, and payments, but has its own areas of particular strictness: permissions that request broad access (like full device storage access, call logs, or SMS) without a clearly justified, narrow use case get flagged hard, since these are commonly abused by malware and Google's automated scanning treats them as high-risk by default. Apps in sensitive categories — anything touching financial services, children's content, or health data — face additional policy requirements and slower review timelines that are worth planning for explicitly in a launch schedule rather than discovering after submission.
Spam, Duplication, and Low-Effort Template Apps
A less obvious but increasingly enforced rejection category covers apps that look templated, duplicated, or minimally differentiated from others already on the store — multiple near-identical apps from the same developer account with only cosmetic differences, an app that's substantially a rebranded template with no meaningful custom functionality, or a listing that appears designed primarily to rank for search keywords rather than to serve a distinct purpose. Both platforms have invested heavily in detecting this pattern because it's a common vector for low-quality or scam listings, and legitimate businesses occasionally get caught by it unintentionally — an agency-built white-label app for multiple clients, for instance, needs each instance to have genuinely distinct branding, content, and where possible functionality, not just a swapped logo and color scheme, or it risks being flagged as duplicate content even when every client relationship behind it is entirely legitimate.
What to Do When a Submission Actually Gets Rejected
The instinct after a rejection is often to resubmit immediately with a minimal fix, but the more reliable path is to read the specific guideline citation in the rejection notice carefully, since both platforms reference the exact policy section that triggered it rather than leaving teams to guess. Apple's Resolution Center allows direct, written back-and-forth with the reviewer, and it's genuinely useful for cases of ambiguity — a reviewer who misunderstood a feature, or a borderline judgment call worth clarifying rather than immediately changing the app to avoid. Appeals through Apple's formal App Review Board exist for cases where a team believes a guideline was misapplied, though it's a slower path best reserved for genuine disagreements about interpretation rather than a substitute for fixing a straightforward, valid finding.
Google Play's appeal process works similarly, through its Developer Console, and tends to move faster for clear-cut policy misunderstandings than for accounts with a history of repeat violations, which is worth knowing because Google in particular tracks developer account history — a first-time, clearly accidental policy miss is treated very differently from a pattern of repeated violations, which can escalate to account-level restrictions well beyond a single app rejection. This is a good practical reason to treat every rejection as worth understanding fully and fixing at the root, rather than patching just enough to get past review this one time and risking the same issue resurfacing on the next update.
Building a Pre-Submission Checklist That Actually Prevents This
The teams that rarely get rejected aren't the ones with the most polished apps — they're the ones with a boring, consistent pre-submission checklist that catches these categories before Apple or Google ever see the build:
- Full core-flow test on the actual minimum supported OS version, not just the latest one
- Working demo account included in review notes if login is required
- No placeholder text, broken links, or visibly unfinished screens anywhere in the shipped build
- Every in-app purchase, subscription, or unlockable feature routed through the platform's official purchase system where required
- Privacy policy live, accurate, and linked; App Privacy label matching actual data collection; every permission request paired with a clear just-in-time explanation
- Store listing screenshots and description matching the actual current app, not a planned future version
- At least one clearly native-feeling capability that justifies the app existing outside a browser
Planning Launch Timelines Around Review Reality
Apple's review typically resolves within a couple of days for most submissions, though it can extend further for edge cases, resubmissions, or apps in more sensitive categories; Google Play's automated-first process is often faster for straightforward apps but can take longer for anything flagged for manual review. Any launch plan with a hard external date — a press announcement, a funding milestone, a client's own launch event — should build in buffer for at least one review cycle beyond the best-case estimate, because a rejection two days before a planned announcement is a scheduling problem entirely within a team's power to avoid by submitting earlier and treating the checklist above as a gate before submission, not a reaction to a rejection after the fact.
