App Store & Google Play rejection reasons, mapped to every guideline

We noticed that your screenshots do not sufficiently reflect your app in use.

Why: Screenshots are marketing art — a slogan over a device frame — instead of captures of the real UI. Apple wants the app itself legible and dominant.

Fix: Replace hero art with real screen captures of this build. Frames and short captions are fine; the actual UI has to be the thing shown.

We found that your app includes hidden or undocumented features.

Why: A feature only reachable by a gesture, code or region you didn't disclose in review notes — Apple treats anything undisclosed as hidden functionality.

Fix: Disclose every feature in the App Review notes, remove any that toggles by hidden trigger, and never ship dormant code you plan to switch on server-side after approval.

The app name / subtitle you entered to be displayed on the App Store includes keywords or terms unrelated to your app.

Why: Keyword stuffing in the name or subtitle, or a name over the 30-character limit. The subtitle is 30 characters too.

Fix: Trim the name to ≤30 chars, keep the subtitle a real descriptor (≤30 chars), and move discovery terms into the 100-character keyword field.

Your app's metadata includes references to third-party platforms.

Why: The description, screenshots or keywords mention Android, Google Play, or a competitor — or promote content not available in this app.

Fix: Strip platform names and competitor names from name, subtitle, keywords and screenshots. Describe only what this iOS build does.

Your app or its metadata contains misleading or inappropriate content.

Why: Emoji or promotional text in the app name, a name that misrepresents the app, or an icon that doesn't match the binary.

Fix: Keep the name factual and emoji-free, make the icon match the in-app icon, and cut any claim the app can't back.

Your app violates our Store Listing and Promotion policy: misleading or irrelevant metadata.

Why: Keyword stuffing in the title or short description, an unearned 'Editor's Choice'/'#1' claim, or screenshots that don't show the app.

Fix: Title ≤30 chars, short description ≤80, no repeated keywords, no fake accolades. Screenshots must be the real app; first two carry the most weight.

We found policy violations in your app's metadata (graphic assets, title, description).

Why: Off-topic or sensational imagery in the feature graphic/screenshots, a call-to-action baked into the icon, or a description that promises features not in the build.

Fix: Feature graphic 1024×500, icon 512×512 with corners not pre-rounded, no CTAs or store badges inside assets, description matched to the shipped APK/AAB.

Your app's description mentions a feature or content that is not currently available.

Why: A 'coming soon' in the description, or copy that promises what this version doesn't ship.

Fix: Describe only shipped functionality. Move roadmap language out of the store description entirely.

Your app appears to be a beta, demo, or trial version. Guideline 2.2 — Beta Testing.

Why: The archive shouts 'not production': a get-task-allow entitlement, a 0.9-beta version string, a debug menu, or a '(Dev)' display name.

Fix: Archive from Release, strip debug menus at compile time, set a real version (1.0.0), and confirm get-task-allow is absent from the entitlements.

Your app uses or references non-public APIs. Guideline 2.5.1 — Software Requirements.

Why: A symbol match against Apple's private API list — very often from a bundled SDK, not your own code. Legacy UIWebView triggers it too.

Fix: Audit every third-party SDK, remove or update the offender, and migrate any UIWebView to WKWebView. Name the SDK you fixed in your reply.

Your app installs or launches executable code, which is not permitted. Guideline 2.5.2.

Why: The build downloads and runs code after review — a JS bundle that changes behaviour, a hot-code-push framework, an interpreter fed remote scripts.

Fix: Ship self-contained code. Remote content is fine for data and web views; executable logic that alters the app's behaviour must be in the binary Apple reviewed.

We were unable to review your app as it crashed on launch on iPhone running iOS 18.x.

Why: A fatal error on the reviewer's device that your test phones never hit — a nil unwrap on a fresh install, a denied permission at first launch, an OS version you never ran.

Fix: Symbolicate the attached crash log with the exact dSYM, reproduce on a wiped device with permissions denied, test the OS named in the rejection, then bump the build.

Your app currently targets API level N and must target at least API level M to be published.

Why: targetSdkVersion sits below Play's rolling floor. This is a hard upload gate, not a reviewer judgement.

Fix: Raise targetSdkVersion to the required level (API 35 / Android 15 is the floor since 31 Aug 2025), then work through the behaviour changes for every level you skipped — scoped storage, foreground service types, exact alarms.

Your app is not compatible with 16 KB memory page sizes and cannot be published for devices running Android 15+.

Why: A bundled native library (.so) is still 4 KB-aligned. Google requires 16 KB alignment for apps targeting Android 15+, enforced for new apps and updates from late 2025.

Fix: Rebuild native libraries with NDK r27+ and a 16 KB max-page-size linker flag, bump every prebuilt .so dependency, then verify alignment with the check-elf-alignment script before uploading.

Your app is debuggable. Set android:debuggable to false for the release build.

Why: The manifest ships android:debuggable="true" — a debug build reached production, exposing the app to inspection.

Fix: Build the release variant (Play strips debuggable via the release config), confirm the flag is absent in the merged manifest, and re-upload.

New apps must use the Android App Bundle (.aab). APKs are no longer accepted for new apps.

Why: You uploaded a raw .apk to a new app; Play requires the .aab publishing format.

Fix: Export an .aab (Build → Generate Signed Bundle) and enable Play App Signing. For a fast local audit you can still analyse a universal .apk built from that bundle.

Your app declares support for a device or capability it does not fully support.

Why: UIRequiredDeviceCapabilities or a supported-orientation set that promises hardware the build doesn't actually handle — or an iPad build that ignores iPad layout.

Fix: Declare only capabilities the app truly requires, and test each device family you list. Don't claim iPad support if the UI is iPhone-only.

We were unable to sign in with the demo account provided. Guideline 2.1 — Information Needed.

Why: No demo account, or one that expired, got rate-limited, was wiped by a staging reset, or is gated behind an SMS/email code only you receive.

Fix: Create a permanent account excluded from seed scripts, put it in App Review Information → Sign-In Required, bypass 2FA for it, and pre-load realistic data.

Your app did not load / displayed an error message when we attempted to use it.

Why: The build talked to a server and got nothing back — a staging host firewalled, a free-tier backend cold-starting past the timeout, an IP allowlist without Apple, or an IPv4 literal on Apple's IPv6 network.

Fix: Point the archive at production, remove IP/geo blocks on the US, keep the backend awake for the review window, and test on an IPv6-only network.

Your app or its metadata contains placeholder content. Guideline 2.1 — App Completeness.

Why: A screen, tab or URL still says 'Lorem ipsum', 'Coming soon', 'TODO', or the support URL 404s. Apple requires final content at submission.

Fix: Grep strings and storyboards for lorem/todo/test/placeholder, open every empty state, and confirm the support and marketing URLs resolve to real pages.

We were unable to review the feature as it is behind a paywall we could not activate.

Why: Everything of value sits behind a purchase the reviewer couldn't make — IAPs not attached to the version, or a sandbox purchase that fails.

Fix: Submit IAPs with the build, give a review account already entitled to the paid tier (or a fresh promo code), and verify Restore Purchases works.

Your app doesn't meet our Broken Functionality policy: App installs, but doesn't load / crashes / doesn't provide the functionality described.

Why: The reviewer opened it and got nowhere — usually a login wall with no credentials in App access, a sleeping or geo-blocked backend, or a first screen needing data a fresh install lacks.

Fix: Fill Play Console → App content → App access with working credentials, read the Pre-launch report (the crash is usually in it), and install the exact internal-testing artifact on a clean device.

We discovered one or more bugs in your app when reviewed on iPhone / iPad running iOS 18.x.

Why: Something doesn't work but didn't crash — a dead button, a broken flow, or a layout that falls apart on a screen size you don't own. The named device is the whole clue.

Fix: Reproduce on the exact device and OS in the rejection, walk the app as a brand-new user with no data or network, and ask for a screen recording in the thread if the report is vague.

Your app provides a webview of a website or has minimal functionality (Spam policy).

Why: Play judged the app to be a website in a shell, or content thin enough to have no reason to exist — the same family as Apple's 4.2, applied earlier.

Fix: Add native capability (offline, notifications for real events, camera, a widget), cut tabs that only open external URLs, and prove you own the domain you wrap.

Your app requests permission to access [data] but does not clarify the use. Guideline 5.1.1 — Data Collection and Storage.

Why: A permission prompt whose purpose string is vague, empty, or names the permission instead of the feature.

Fix: Rewrite each purpose string to name the feature: 'Camera access lets you scan a receipt to add an expense', not 'We use your camera'.

Your app does not include a PrivacyInfo.xcprivacy file / does not declare an approved reason for the required-reason API you access.

Why: A missing privacy manifest, or a required-reason API (UserDefaults, file timestamps, system boot time…) you or an SDK call without declaring a reason.

Fix: Ship PrivacyInfo.xcprivacy declaring every required-reason API, and confirm each bundled SDK ships its own manifest and signature.

Your app supports account creation but does not include an option to initiate account deletion.

Why: Users can create an account but can't delete it inside the app — a link to a support form isn't enough.

Fix: Add an in-app path that deletes the account and its server-side data (not just deactivates), easy to find under Settings → Account.

Your app uses the Advertising Identifier but does not use App Tracking Transparency.

Why: The build tracks users across apps/sites (IDFA, an ad or analytics SDK) without calling requestTrackingAuthorization first, or the tracking isn't declared in the privacy labels.

Fix: Call ATT before any cross-app tracking, and make the privacy nutrition labels match what your SDKs actually collect.

The Data safety section in your listing doesn't accurately reflect your app's data collection and sharing.

Why: What the app sends doesn't match the form — almost always an SDK: analytics collecting an advertising ID, a crash reporter shipping device identifiers.

Fix: List every SDK, read each one's data-safety disclosure, re-declare data type + purpose + sharing in Play Console, and keep the privacy policy consistent with the form.

Apps that allow account creation must also let users request account and data deletion.

Why: No in-app deletion path, or no externally reachable URL to request deletion — Google requires both.

Fix: Provide an in-app deletion flow and a web URL that requests account + data deletion, then declare the URL in the Play Console Data deletion section.

Your app accesses personal or sensitive data without a valid privacy policy.

Why: No privacy policy URL in the Play listing (or a dead one) while the app handles personal data.

Fix: Publish an app-specific, working privacy policy and add its URL in Play Console → App content, plus a link inside the app.

Your app requests a restricted permission (SMS, Call Log, background location, All files access) without an approved use case.

Why: A high-risk permission in the manifest without the required Permissions Declaration Form and a core use case that justifies it.

Fix: Drop the permission if it isn't core, or file the declaration with an in-context disclosure and a video showing the feature that needs it.

Your app provides a limited user experience / is not sufficiently different from a mobile web browsing experience. Guideline 4.2 — Minimum Functionality.

Why: A WKWebView pointed at your site with a tab bar bolted on, or a shell whose only feature is a form. Vibe-coded shells land here a lot now.

Fix: Add something a browser can't do — offline data, push tied to real events, Face ID, widgets, Siri shortcuts — and name the native path in your reviewer notes.

Your app duplicates the content and functionality of apps already on the App Store. Guideline 4.3 — Spam.

Why: The app is one of many near-identical builds (a template reskinned per client), or a clone of an existing concept with no distinguishing value. 4.3(a) is the spam variant, 4.3(b) the design-saturation one.

Fix: Consolidate reskins into one configurable app, or add genuinely distinct content and features. If you're a template vendor, the fix is architectural, not a reworded appeal.

Your app appears to be a copycat of another app. Guideline 4.1 — Copycats.

Why: The name, icon or UI mirrors an existing app closely enough to confuse users, or leans on another brand's identity.

Fix: Differentiate the icon, name and layout, and remove any third-party brand assets you don't have rights to use.

Your app uses a third-party login service but does not offer Sign in with Apple. Guideline 4.8 — Login Services.

Why: You offer Google/Facebook social login but not an equivalent privacy-focused option — required when any third-party social login is present.

Fix: Add Sign in with Apple (or another option that limits data to name+email and hides the real email), or drop third-party social login entirely.

Your app impersonates another app, developer, or entity (Impersonation policy).

Why: The name, icon or listing copies another app or brand, or claims an affiliation you don't have.

Fix: Rename, redesign the icon, and strip any brand names or logos you don't own from the app and listing. Impersonation can terminate the whole account.

Your app is highly similar to other apps already on Google Play (Repetitive Content / Spam).

Why: One of several near-duplicate apps from the same account, or a mass-produced template with only cosmetic differences per instance.

Fix: Merge duplicates into one app, or give each a distinct purpose and content. Play's equivalent of Apple 4.3 — the fix is the same.

Your app contains deceptive behavior: fake functionality, misleading claims, or content that mimics system UI.

Why: A fake system warning, a button that doesn't do what it says, an undisclosed feature, or an ad styled to look like an OS dialog.

Fix: Remove fake system prompts and non-functional features, disclose every behaviour to reviewers, and make ads visually distinct from system UI.

Your app uses push notifications for promotions, advertising, or direct marketing without consent.

Why: Marketing pushes sent without an explicit opt-in separate from the app's functional notifications.

Fix: Gate marketing pushes behind a clear, separate opt-in, and keep functional notifications tied to real app events.

Your app uses a purchasing mechanism other than in-app purchase to unlock features. Guideline 3.1.1 — In-App Purchase.

Why: The app lets users pay — or points at paying — outside Apple's IAP for digital content: a Stripe checkout in a webview, a 'subscribe on our website' link, sometimes just a mention.

Fix: Route all in-app digital purchases through IAP, remove external-payment links and copy (including in webviews), and add a visible Restore Purchases control.

Your subscription does not clearly present price, duration, or terms before purchase. Guideline 3.1.2 — Subscriptions.

Why: The purchase screen or metadata omits price, billing period, trial terms, auto-renewal, or a link to Terms and Privacy.

Fix: Show price, period, what's included, trial length and auto-renewal on the purchase screen, and link functional Terms of Use and Privacy Policy.

Your app includes in-app purchases but does not offer a Restore Purchases mechanism.

Why: A non-consumable or subscription is sold with no way to restore it after reinstall or on a new device.

Fix: Add an explicit Restore Purchases button that calls StoreKit's restore flow, and test it on a signed-out device.

Your app uses in-app purchase to sell physical goods or services consumed outside the app.

Why: The reverse mistake — IAP used for a physical good or a real-world service, which must not go through Apple's billing.

Fix: Move physical goods and real-world services to an external payment method, and reserve IAP for digital content used inside the app.

Your app sells in-app digital content without using Google Play's billing system.

Why: Digital goods or subscriptions billed through an external processor where Play Billing is required.

Fix: Integrate Play Billing for digital content; keep physical goods and services on other methods. If an alternative billing program applies in your region, declare it explicitly.

Your subscription offer doesn't clearly disclose price, billing period, or cancellation terms.

Why: The paywall hides the full price/cadence, buries free-trial conversion, or omits how to cancel.

Fix: State full price and cadence up front, explain when a trial converts, and link how users manage or cancel the subscription.

Your app engages in an unacceptable business practice. Guideline 3.2.2.

Why: Artificially manipulating reviews or rankings, misleading pricing, or a tactic Apple deems dishonest to users.

Fix: Remove the practice — incentivised reviews, dark-pattern pricing, misleading trials — and describe the corrected flow in your reply.

Your ads violate our policy: disruptive, deceptive, or shown outside the app.

Why: Full-screen interstitials that can't be closed, ads that mimic the app UI, or ads served on the lock screen / outside the app context.

Fix: Make every ad dismissible, keep ads inside the app, and ensure none imitate system or app controls.

Your app contains content that many users would find objectionable. Guideline 1.1 — Objectionable Content.

Why: Offensive, discriminatory, or explicit content — or, most often, user-generated content with no moderation.

Fix: Remove the flagged content. For UGC, add a filter, a report control, a way to block users, and published contact info before resubmitting.

Your app enables the display of user-generated content but lacks the required safeguards. Guideline 1.2.

Why: A social or UGC app shipped without content filtering, reporting, blocking, or a way to reach the developer.

Fix: Add a content filter, an in-app report mechanism, user blocking, and a published contact method. Act on reports within 24 hours.

The support URL provided for your app does not function properly. Guideline 1.5 — Developer Information.

Why: The support URL 404s, redirects to an unrelated page, or offers no real way to contact you.

Fix: Point the support URL at a live page with a working contact method, and confirm it resolves before resubmitting.

Your app uses third-party intellectual property without authorization. Guideline 5.2 — Intellectual Property.

Why: Unlicensed media, another app's UI copied, or trademarked names/logos used without permission.

Fix: Remove or license the material, and be ready to provide proof of rights if Apple asks. This one often needs documentation, not just a fix.

Your Apple Developer Program account is under review for conduct. Guideline 5.6 — Developer Code of Conduct.

Why: Manipulating reviews or ratings, repeated policy evasion, or dishonest behaviour toward users or Apple — this targets the account, not one build.

Fix: Stop the pattern (bought reviews, fake accounts, ranking manipulation), document what changed, and reply through the standard channel — there's no shortcut here.

Your app does not include enough metadata to be understood. Guideline 2.3.12.

Why: A near-empty description or a listing that doesn't explain what the app does — 'minimal viable metadata' failing.

Fix: Write a description that clearly states the app's core features and value, without keyword stuffing.

Your app was flagged for potentially harmful behavior (Malware / Mobile Unwanted Software policy).

Why: Often a false positive from an obfuscated SDK, a sideloaded update mechanism, or a library Google's scanners distrust — sometimes a genuinely bad dependency.

Fix: Identify the flagged component (Play emails the classification), remove or replace the SDK, disable any self-update mechanism, and appeal with the SDK list.

Your app interferes with the device, network, or other apps (Device and Network Abuse policy).

Why: The app installs other apps from outside Play, drains resources in the background, or modifies system behaviour without disclosure.

Fix: Remove any out-of-Play install flows and undisclosed background work, and disclose every system interaction the app performs.

Your app targets children but does not comply with the Families policy.

Why: A child-directed app using non-certified ad SDKs, personalized ads, or collecting personal data from children.

Fix: Set the target audience correctly, switch to Families-certified ad SDKs, disable personalized ads, and remove data collection from children.

Your app is missing a content rating, or the rating is inconsistent with the app's content.

Why: The IARC questionnaire wasn't completed, or the answers don't match what the app actually shows.

Fix: Complete the IARC rating questionnaire honestly in Play Console → App content; an unrated app can be removed.

You uploaded a version code that has already been used / is not higher than the previous release.

Why: versionCode wasn't incremented above the last upload — a hard Console gate, not a review call.

Fix: Raise versionCode above every previous upload (across all tracks), rebuild, and re-upload.