Most Common Reasons Apps Get Rejected from Apple App Store & Google Play Store (2025–2026)

Compiled from official guidelines, developer reports on Reddit, X (Twitter), blogs, Medium-style articles, and industry analyses (RealAppReview, QAwerk, Choicely, LaunchShots, Testers Community, RevenueCat, etc.), and cross-checked against Google Play Help, Android Developers, and Apple's official App Review Guidelines and App Store Connect documentation.

Apple rejects roughly 23–25% of submissions overall (higher for first-time submissions, often cited around 30–40% in community reports). Google Play has a higher first-pass rate but stricter automated enforcement on data safety, permissions, and post-launch compliance. Performance/completeness issues dominate Apple rejections; data declarations and permissions dominate Google Play.

Sources include Apple's App Store Transparency Reports, Google Play policies, Apple's App Review Guidelines, Apple Developer distribution guidance, App Store Connect Help, Google Play Help/Android Developers pages, and aggregated developer experiences (Reddit, Stack Overflow, Apple Developer Forums, practitioner blogs). Evidence snapshot current through mid-September 2026 — always re-check the live consoles/policy pages before submitting, since both platforms treat these as living documents.

A note on rejection vs. removal vs. suspension. These are not the same enforcement action. A rejection means a new app or update was not approved — for an update, the previously published version generally stays live. Removal takes a published app (and prior versions) off the store. Suspension is a stronger, account-level action that counts as a strike and can escalate toward termination on repeat or serious violations. A single rejection does not itself damage your account; how you respond to it can.

---

Apple App Store – Top Rejection Reasons

Apple organizes reviews around five pillars: Safety, Performance, Business, Design, and Legal. Performance (especially Guideline 2.1 – App Completeness) accounts for the largest share of rejections — often over 40% of unresolved issues.

1. Crashes, Bugs, Freezes & Incomplete Functionality (Guideline 2.1 – App Completeness)

Most common reason overall.

• App crashes on launch or during core flows.
• Placeholder text ("Lorem Ipsum", "Coming Soon"), broken links, empty screens, or non-functional buttons.
• Backend/server issues during review — the review window needs a live, stable backend, not just a working build.
• Missing or non-working demo/test account for login-gated apps.
• Features that require hardware/permissions the reviewer can't access without notes.
• Failures that only appear after a permission denial, a purchase interruption/restore, a device rotation, a deep link, a network switch, or at a paywall — not just on first launch.

Why it happens: Reviewers test on real devices (sometimes older models or specific OS versions) and IPv6 networks. Emulators hide many issues. Apple also reviews the exact build selected in App Store Connect — a build that passed in TestFlight can still fail if a different archive was submitted.

Fix: Thorough real-device testing across iOS versions/devices, including clean installs, upgrades, offline/degraded networks, background/foreground transitions, low storage, and permission-denial paths. Provide working demo credentials + clear App Review Notes. Hide unfinished features behind remote flags. Ensure production backend is stable and stays live throughout the review window.

2. Privacy Policy, Data Collection & Account Deletion Issues (Guideline 5.1.1 and related)

• Missing, broken, or incomplete privacy policy URL (must be accessible in App Store metadata and inside the app).
• App Privacy labels ("nutrition labels") do not match actual data collection or third-party SDKs — Apple holds you responsible for partner and SDK behavior, not just your own code.
• No in-app account deletion option when the app allows account creation (required since ~2022, strictly enforced). The action must actually delete or deactivate server-side data (or clearly explain legally required retention) — a "Deactivate" button that leaves the account intact does not satisfy this.
• Collecting data / tracking without proper consent or App Tracking Transparency (ATT) prompt.
• Requesting permissions (camera, location, mic, contacts, photos) too early or without a clear, plain-language purpose string tied to a visible feature.
• Missing Privacy Manifest for third-party SDKs.

Fix: Host a complete, accurate privacy policy. Build a full data-flow inventory (source code, Info.plist, SDKs, network traces) and reconcile it against the App Privacy form — re-run this any time a dependency or feature changes. Implement a real, working, easy-to-find in-app "Delete Account" flow. Use ATT before any tracking. Request permissions only in context.

3. Minimum Functionality / WebView Wrappers / Spam (Guidelines 4.2 & 4.3)

• App is essentially a website in a WebView with little or no native value.
• Too simple (single purpose, static content, or "repackaged website").
• Template/no-code apps that look identical to many others (prayer apps, calculators, wallpapers, etc.).
• Duplicate or near-duplicate apps from the same developer, or a batch of near-identical regional variants.

Important nuance: this is a store-level distinctiveness judgment, not purely a technical one. Original code alone doesn't resolve a 4.3 concern if the submission looks like one of many substantially similar, low-value products. Conversely, a focused wrapper can be approved when it delivers a genuine, reliable mobile experience — approval can't be predicted from architecture alone.

Fix: Add meaningful native features (push notifications, offline storage, camera/sensors, native gestures, personalized content). Make differentiated value reachable in the first review session — use Review Notes or a short review video if a feature is hardware-dependent, notification-driven, or otherwise hard to reproduce on demand. Consolidate near-identical apps rather than shipping many thin variants.

4. Misleading or Inaccurate Metadata (Guideline 2.3)

• Screenshots, description, or preview videos show features that don't exist or are paywalled without disclosure.
• Keyword stuffing, exaggerated claims ("#1 Best"), or competitor names.
• Pricing mismatches.
• Broken support/privacy links in the listing.

Fix: Screenshots and description must accurately reflect the free experience. Clearly label premium features. Use real current screenshots. Compare every locale's listing against the current build before submitting.

5. In-App Purchase & Monetization Violations (Guideline 3.1.1 / 3.1.2)

• Selling digital content, features, or subscriptions outside Apple's IAP / StoreKit.
• Missing "Restore Purchases."
• Unclear subscription terms, pricing, or auto-renewal disclosure.
• External payment links for digital goods used outside a documented, eligible exception.

Fix: Classify every product (digital content/functionality vs. physical good/service vs. regulated service) and route digital purchases through Apple IAP unless a documented exception genuinely applies. Test the full purchase lifecycle: product availability in the review storefront, purchase, restore, renewal, cancellation, interruption, and entitlement delivery. Provide clear restore functionality and subscription disclosures (price, duration, cancellation steps, EULA/privacy links).

6. Design & UI Issues (Guideline 4.0)

• Poor UI that doesn't follow Human Interface Guidelines.
• Icon or launch screen problems.
• Non-standard controls or navigation that confuse users.

7. User-Generated Content, Social Features & Child Safety (Guideline 1.2 and related)

• No report or block mechanism for user-generated content.
• Inadequate content filtering, slow/absent moderation, or unclear abuse escalation.
• Unsafe default visibility settings (e.g., public-by-default profiles for minors).
• Missing support contact or insufficient parental/age controls.
• Apps declaring a child-directed audience while still running analytics, advertising, or identifier-based SDKs that weren't evaluated for that audience — Kids category apps face extra constraints on data collection, analytics, ads, and external links.

Fix: Test with multiple accounts. Verify filtering, per-post report/block flows, moderation response times, abuse escalation, support contact, age/parental gates, default visibility, and remote-content review. Re-audit every SDK for child-directed compliance if targeting a Kids or mixed audience.

8. Intellectual Property, Regulated Content & Legal Requirements (Guidelines 5.2–5.5)

• Using logos, names, characters, fonts, or media without rights clearance.
• Gambling, financial, medical, or other regulated-category features shipped without the required authorization or documentation.
• Medical claims without supporting evidence, or unsafe health guidance.
• Distribution in territories where the service isn't legally permitted.

Fix: Maintain an evidence file (licenses, trademarks, API/data-source agreements, entity ownership) for anything with rights or regulatory exposure. Obtain category-specific approvals before submission — a disclaimer alone doesn't resolve licensing or consumer-protection requirements.

9. Other Frequent Issues

• Sign in with Apple required when offering other third-party logins (Guideline 4.8).
• Executing remote code that wasn't reviewed (Guideline 2.5.2).
• Wrong build selected in App Store Connect (mismatched Bundle ID, version/build number, signing, entitlements, or supported platform configuration).

---

Google Play Store – Top Rejection Reasons

Google relies more heavily on automated scanning + console declarations. Rejections often cite specific policies (Data Safety, Permissions, Metadata, Functionality), and a rejection notice is not guaranteed to name every issue in your app — treat it as a starting point, not a complete list.

1. Broken Functionality / Crashes / Incomplete App

• Crashes, freezes, ANRs (App Not Responding), or core flows that fail.
• Placeholder content or non-working features.
• Login required with no working test credentials provided in the Play Console App access section.

Fix: Real-device testing matrix, not just emulators. Use Play's pre-launch reports and Android vitals as structured signals — Google's technical-quality page lists specific user-perceived crash and ANR thresholds, plus wake-lock and battery thresholds, and notes that poor performance can affect visibility or publishing capabilities. Provide demo accounts and any special instructions in the App access section (Play Console supports multiple instruction sets where needed).

2. Data Safety Form Mismatch or Missing Privacy Policy

Very common and strictly enforced.

• Data Safety declaration does not match what the app + SDKs actually collect/share — this must cover the app itself, controlled webviews, libraries, and every SDK, including ones you didn't write.
• Missing or broken privacy policy URL.
• Incomplete disclosures about data collection, sharing, or third-party SDKs.
• Pseudonymous data that could reasonably be re-linked to a person may still require disclosure — "we don't collect data" is often wrong once every dependency is inventoried.
• Background or unexpected sensitive-data collection without a prominent in-app disclosure and affirmative consent before access — a privacy policy alone is not a substitute for that disclosure.

Fix: Build a full data-flow inventory from source code, manifests, network traces, backend schemas, and every direct/transitive SDK. Record each data type, purpose, recipient, retention, deletion path, and whether it's optional or required. Reconcile this against the Data Safety form and privacy policy, and re-run the audit whenever a dependency or feature flag changes.

3. Sensitive / Restricted Permissions Without Justification

• Requesting SMS, Call Log, Contacts, background location, all-files access, etc., without a clear core use case and the proper declaration form. High-risk permissions (certain SMS/Call Log uses especially) can require a Permissions Declaration Form, a demonstration video, and reviewer access instructions — review of a new permission can take several weeks.
• Asking for permissions at launch instead of in context.
• Missing prominent in-app disclosure before the system permission prompt.
• A permission whose declared use doesn't match the app's actual core functionality (a common, specific rejection pattern: requesting Call Log "to improve onboarding" when the core feature doesn't need it).

Fix: Principle of least privilege — diff your manifest against the previous release and remove anything unused. Tie every remaining permission to a specific, visible feature. Request access immediately before that feature is used, explain it in plain language, and handle denial gracefully. Complete every required declaration with accurate core-functionality reasoning and, where required, a demonstration video.

4. Account Deletion Missing, Nonfunctional, or Hard to Find

• Google requires both an in-app deletion route and a publicly reachable external web page for the deletion request, for apps that support account creation. Account freezing or deactivation is not treated as equivalent to deletion.
• A deletion link that's present but broken, generic, not clearly tied to the listed app/developer, or buried in an obscure menu.

Fix: Test deletion logged-in and logged-out, from a mobile browser, and from each launch region. Make the route prominent, name the app/developer on the external page, and document any legally required data retention. Verify deletion actually removes server-side account data, tokens, and linked identities — not just local app data.

5. Minimum Functionality / WebView Wrappers / Spam

• Apps that are just websites in a frame or offer almost no interactive value.
• Repetitive/templated content or affiliate spam.
• Deceptive behavior: misleading functionality claims, impersonation of another app/developer, or hidden features.

Fix: Provide real app value beyond a browser. Use Trusted Web Activities (TWA) properly if wrapping a PWA rather than a raw webview.

6. Store Listing / Metadata Problems

• Keyword stuffing in title/description.
• Screenshots that don't match the app.
• Misleading claims, unattributed testimonials, or competitor mentions.
• Incorrect content rating.
• Google's Metadata policy is fairly concrete here: titles are capped at 30 characters, and the policy restricts emojis, repeated special characters, and ALL CAPS (except where it's genuinely part of the brand name). It also prohibits unsubstantiated claims about rankings, awards, discounts, or Google Play affiliation.

Fix: Accurate, natural-language descriptions. Real screenshots matching the current build. Correct IARC content rating questionnaire, answered from actual app behavior, not intended behavior.

7. Payment Flow Violations

• Selling digital content, functionality, subscriptions, or cloud services outside Google Play Billing without a documented, eligible exception.
• Directing users to alternative payment methods via listings, promotions, webviews, buttons, links, messages, ads, or account flows, outside an approved alternative-billing/external-link program.
• Alternative-billing and external-link programs are market- and eligibility-dependent — an exception available in one storefront or program shouldn't be assumed to apply everywhere.

Fix: Classify every SKU and map it to Play Billing unless you have retained evidence for a documented exception. Test purchase, acknowledgement, pending/failed states, entitlement delivery, renewal, cancellation, refund/revocation, and cross-device sync.

8. Target API Level / Technical Requirements

• Targeting an outdated SDK/API level. As of the 31 August 2026 snapshot, new apps and updates generally must target Android 16 / API 36 or higher; Wear OS and Android Automotive OS need API 35+; Android TV and Android XR need API 34+ (check for possible extensions and category-specific exceptions before assuming a deadline has or hasn't moved).
• Debuggable release builds.
• Missing 64-bit native support, or native libraries not built for the 16 KB memory-page-size requirement on newer Android.
• SDK Index flags — Google publishes an SDK Index as a decision aid for evaluating third-party SDKs, but a clean SDK Index signal is not itself a guarantee of policy compliance; you're still responsible for what the SDK actually does.

Fix: Always target the latest required API level and re-check the current deadline immediately before submission — these are living requirements, not a fixed schedule. Use release builds only. Rebuild native dependencies for 64-bit and 16 KB page-size compatibility as needed.

9. User-Generated Content, Families & Sensitive Audiences

• Apps hosting or enabling UGC without adequate moderation, reporting, or age-appropriate controls.
• Inaccurate target-audience or Families declarations, content ratings, or sensitive-data handling for a child-directed or mixed audience. Unrated apps can be removed outright.

Fix: Complete App content declarations (target audience, Families, content ratings, ads, Data Safety) accurately, and re-audit analytics/ad SDKs for child-directed use if applicable.

10. Other Common Issues

• Intellectual property violations (unlicensed assets, trademarks, impersonation).
• Content policy violations (restricted content categories, insufficient moderation).
• For new personal developer accounts created after 13 November 2023: failure to complete the required closed test — at least 12 continuously opted-in testers for 14 consecutive days — before production access is granted.

---

Cross-Platform Patterns (Both Stores)

Neither platform's review process reduces to a single checklist — treat this table as a prioritization aid, not a prediction engine. The same broad issue (e.g., "privacy mismatch") can produce different outcomes depending on the app's category, audience, permissions, and the specific evidence available to the reviewer.

---

Pre-Publish Checklist

Use this checklist before every submission. Treat it as a release gate, and audit behavior, binary, dependencies, listing, and declarations as one system — don't treat the privacy form or store listing as paperwork that gets filled in after engineering is done.

Universal (Both Stores)

• App is fully functional on real devices (not just emulators/simulators), on a clean install and an upgrade path.
• No crashes, freezes, ANRs, or broken core user flows — including after permission denial, purchase interruption/restore, deep links, or a network switch.
• No placeholder text, "Coming Soon," or non-functional UI elements.
• All external links (privacy, support, terms, account deletion) work and load correctly, tested from a fresh browser session.
• Privacy policy is complete, accurate, hosted on HTTPS, and linked in the store listing + inside the app.
• Demo/test account credentials are non-expiring, pre-populated with sample data, work from a clean device, and don't depend on a device-bound second factor, biometric-only gate, or an inaccessible subscription.
• Screenshots and description accurately reflect the current build (especially the free tier).
• No keyword stuffing, unattributed testimonials, or misleading claims.
• Intellectual property: no unauthorized logos, names, characters, fonts, or content.
• Content rating questionnaire completed accurately, based on actual (not intended) behavior.
• Backend/servers stable and live during the expected review window.
• Review notes / App access information filled with clear, deterministic, step-by-step instructions for the reviewer.
• Full data-flow inventory built from source code, manifests, network traces, and every direct/transitive SDK — reconciled against your privacy policy and store declarations.
• If UGC or social features are present: report/block controls, moderation process, abuse escalation, support contact, and age-appropriate default visibility are all tested.

Apple App Store Specific

• The intended build is selected in App Store Connect — Bundle ID, version/build number, signing, entitlements, and supported platform configuration all verified.
• App Privacy labels match actual data collection + all third-party SDKs.
• Privacy Manifest included for required SDKs.
• In-app account deletion available if accounts can be created, and it actually deletes or deactivates server-side data.
• App Tracking Transparency (ATT) implemented if tracking/IDFA is used.
• Permissions requested only in context with clear, plain-language purpose strings.
• Sign in with Apple offered if other third-party logins are present.
• All digital goods/subscriptions use StoreKit / IAP + Restore Purchases works; full purchase lifecycle tested (purchase, restore, renewal, cancellation, interruption).
• Subscription terms clearly disclosed (price, duration, cancellation, EULA/privacy links).
• App provides sufficient native functionality (not a pure WebView wrapper) — differentiated value is reachable in the first review session.
• Icon, launch screen, and UI follow Human Interface Guidelines.
• App Review Notes include any special hardware needs, demo logins, region notes, or a short review video for hard-to-reach features.
• For UGC/social or child-directed apps: filtering, reporting, blocking, moderation, and Kids-category data/ad/SDK restrictions all verified.
• Rights and regulatory evidence on file for any code, media, trademarks, financial, health, gambling, VPN, MDM, travel, or third-party-content features.
• Build is production-ready (not debug), tested via TestFlight, with crash/feedback evidence retained.

Google Play Specific

• Data Safety form accurately reflects all data collected/shared by the app, controlled webviews, libraries, and SDKs — including pseudonymous data that could reasonably be re-linked.
• Privacy policy URL works and matches the Data Safety declarations.
• Only necessary permissions requested; restricted ones have proper declarations, demonstration video (if required), and in-app disclosures shown before the system prompt.
• In-app account deletion and a public, working external web deletion page are both present and tested (not just deactivation).
• Target API level meets Google's current requirement (verify the live deadline — API 36+ for most apps as of the 31 August 2026 snapshot; API 35+ for Wear OS/Automotive; API 34+ for TV/XR).
• Release build is not debuggable.
• 64-bit native support and 16 KB memory-page-size compatibility verified if the app includes native code.
• App Bundle (AAB) used correctly.
• Content rating (IARC), target-audience, and Families declarations completed and accurate.
• For new personal accounts: closed testing requirement satisfied (12+ continuously opted-in testers, 14 consecutive days) before applying for production access.
• No deceptive metadata, impersonation, or repetitive/templated near-duplicate listings.
• Title is 30 characters or fewer; no keyword stuffing, ALL CAPS abuse, emoji spam, or unsubstantiated ranking/award/discount claims.
• Digital goods use Google Play Billing where required, or documented exception evidence is retained.
• Every direct and transitive SDK checked against the SDK Index and provider documentation (treated as a decision aid, not a compliance guarantee).

Final Pre-Submit Steps

• Test the exact build you will upload on multiple devices/OS versions, including first launch, upgrade, offline/degraded network, low storage, and background/foreground transitions.
• Have at least one other person (or external tester) walk through the app as a new user with no prior context.
• Double-check every store listing field, in every supported locale, one last time against the current build.
• Prepare clear, polite review notes explaining any complex, hardware-dependent, or non-obvious flows.
• Keep a changelog of what changed since the last submission (helps with appeals and regression tracking).

---

Tips to Reduce Rejection Risk

1. Test like a reviewer — Start from a fresh install with no prior data. Use the exact credentials you provide, from the region the app will be reviewed in.
2. Keep declarations in sync — Every time you add an SDK or feature, update privacy policy, App Privacy labels, and the Data Safety form together, as one change.
3. Document everything — Screenshots of working flows and notes make appeals much easier.
4. Start with TestFlight / Internal testing — Catch issues early, and make sure the exact build you submit is the one that was tested.
5. Read the official guidelines regularly: Apple App Store Review Guidelines and Google Play Developer Policy Center. Both are living documents — re-check immediately before release, especially for dated technical requirements.
6. Treat "value" as more than architecture — a wrapper can be fine if it's genuinely useful; original code isn't automatically enough if the app looks like a thin, low-value variant.

---

If Rejected: A Response Playbook

1. Preserve the record. Save the rejection message, the exact guideline/policy cited, app version/build ID, storefronts, console declarations, reviewer credentials, screenshots, and logs. Don't start by changing several unrelated things at once — that makes the original cause harder to isolate.
2. Classify the issue. Most citations fall into one (or more) of: technical quality, incomplete review access, privacy/data disclosure, permissions, payments, metadata/discovery, UGC/safety, minimum functionality, legal/regulated content, or platform/technical requirements. A single citation can have a cross-cutting cause — e.g., a privacy rejection might need an SDK change, a Data Safety update, and a privacy-policy edit together.
3. Reproduce the reviewer's path exactly — clean device, the submitted artifact, the supplied account, the stated region/OS. If you can't reproduce it, test likely environmental differences: fresh install vs. upgrade, degraded network, permission denial, account state, storefront, locale, or missing seed data.
4. Build a concise evidence packet for your response: the build ID, deterministic repro steps, the affected feature, the specific policy/guideline it maps to, and the correction made. Include a short screen recording when a feature is hard to reach.
5. Fix the actual cause, not just the wording. Remove an unnecessary permission rather than writing a more persuasive justification for it. Replace a noncompliant SDK rather than only editing a declaration. Implement real server-side deletion rather than renaming a deactivation flag.
6. Use the official channel. On Google Play, update the relevant declarations/artifact and resubmit through the publishing workflow; use the official appeal route if you believe the action was mistaken, and check the rest of your catalog — a notice may not name every issue. On Apple, reply directly in the App Store Connect conversation with specific evidence, revise the build if needed, and use a guideline-specific appeal only after answering any information requests.
7. Resubmit with a controlled, documented change set. Record every changed file, dependency, declaration, and instruction. Retest the original failure and adjacent flows.
8. Learn without overgeneralizing. Add the failure to your regression suite. Mark whether it was an explicit policy violation, a review-readiness gap, a technical defect, or just an anecdotal pattern — the goal is a better release system, not a superstition about "what Apple/Google always does."

Most rejections are avoidable with disciplined preparation. The majority of first-time failures come from incomplete testing, mismatched privacy declarations, or thin functionality — not from exotic policy edge cases.

Last updated based on data available through mid-September 2026. Policies evolve — Google in particular publishes future-effective deadlines that shift, and Apple's guidelines are explicitly "living guidance." Always verify against the latest official documentation immediately before submitting.

---

This document aggregates publicly reported common cases from developer communities (Reddit r/androiddev, r/iOSProgramming, r/iosdev, Indie Hackers, X posts, Apple Developer Forums, Stack Overflow), industry blogs, and official policy/transparency data. Community-sourced patterns (credential failures, specific SDK behaviors, wording that "worked") are useful for test design but are anecdotal — they don't establish universal rules or guarantee a specific fix will pass review. It is not legal advice.