App Rejection Fix
Menu

App Rejection Library

37 structured entries covering the Google Play and App Store rejection messages we see most: what each means, the usual causes, what to check, and whether to fix, reply or appeal. Every entry links its official source and shows when it was last verified.

Showing 21–37 of 37 entries.

Google Play Critical Account termination

Developer account terminated

The developer account was terminated: all apps removed, publishing disabled. Creating a replacement account is treated as evasion.

Open entry ↓

Typical wording

Your Google Play Developer account has been terminated due to prior violations of the Developer Program Policies and Developer Distribution Agreement.

Common causes

  • Multiple suspensions or prior violations
  • Association with another terminated account
  • Serious deceptive or fraudulent findings

What to check

  • The cited clause and any appeal window in the notice
  • Enforcement timeline across all apps
  • Relationships with other accounts (payment, devices, code, identity)

Fix / reply / appeal guidance

  • Do not open a new account
  • Reconstruct the enforcement history and gather real evidence
  • Submit one complete appeal within the stated window
Policy / guideline:
Developer Distribution Agreement — account termination
Category:
Developer account terminated
Last verified:
Detailed guide: Developer Account Terminated Full entry page Get this rejection reviewed
Google Play High Removal Technical review likely

App removed from Google Play

A published app was removed for a policy issue. Usually recoverable by fixing the issue and submitting a compliant update.

Open entry ↓

Typical wording

Your app has been removed from Google Play due to a policy violation. You can resubmit your app after addressing the issue.

Common causes

  • A policy that changed after publication
  • An SDK update that introduced non-compliant behaviour
  • A rights-holder or user complaint

What to check

  • The specific policy and element cited
  • Whether the issue exists in other apps in the account

Fix / reply / appeal guidance

  • Fix and submit a compliant update
  • Do not create a duplicate listing
  • Appeal only if the finding is factually wrong
Policy / guideline:
Enforcement Process — removal
Category:
App removed
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection Technical review likely

Deceptive behaviour or misleading claims

Google judged the app or its listing misleading: functionality that differs from the description, unverifiable claims, or manipulated ratings.

Open entry ↓

Typical wording

Issue found: Deceptive Behavior. Apps that attempt to deceive users or enable dishonest behavior are not allowed.

Common causes

  • Listing claims the app cannot deliver
  • Behaviour changes not disclosed
  • Incentivised or purchased reviews

What to check

  • Every claim in the listing against the app
  • Any remote configuration that changes behaviour
  • Review sourcing practices

Fix / reply / appeal guidance

  • Make the listing and the app describe the same product
  • Remove unverifiable claims
  • Never buy or incentivise reviews
Policy / guideline:
Deceptive Behavior policy
Category:
Deceptive behavior / misleading claims
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection Technical review likely

Digital goods sold outside Google Play billing

In-app purchases of digital content or features used an external payment method where the Payments policy requires Google Play billing.

Open entry ↓

Typical wording

Issue found: Violation of Payments policy. Apps offering in-app purchases of digital goods or services must use Google Play's billing system.

Common causes

  • External checkout for digital features
  • Links to buy digital content on a website
  • Physical-goods exception applied to digital items

What to check

  • Which items are digital versus physical
  • Any alternative-billing eligibility in your regions
  • Purchase flows and links in the app

Fix / reply / appeal guidance

  • Use Google Play billing for digital items
  • Keep external payments for physical goods and services
  • Review regional alternative-billing programmes if applicable
Policy / guideline:
Payments policy
Category:
Payments policy
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection Technical review likely

Families policy or target-audience mismatch

The app appeals to children or declared a mixed audience, and its content, ads SDKs or data practices do not meet Families requirements.

Open entry ↓

Typical wording

Issue found: Target audience and content policy. Your app's declared target audience does not match its content, or it does not meet the Families policy requirements.

Common causes

  • Declaration inconsistent with content
  • Ads SDKs not self-certified for families
  • Data practices not allowed for children

What to check

  • Target audience answers versus the app
  • SDK list against the families self-certified list
  • Content rating questionnaire

Fix / reply / appeal guidance

  • Correct the declaration
  • Use compliant SDKs for family-directed builds
  • Adjust content and data handling for the declared audience
Policy / guideline:
Families policy and Target Audience declaration
Category:
Families / target audience
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection

Impersonation or intellectual property issue in the listing

The name, icon, listing or content resembles another brand or uses protected material without authorisation.

Open entry ↓

Typical wording

Issue found: Impersonation. Your app or store listing impersonates another entity or uses intellectual property that belongs to a third party.

Common causes

  • Third-party brand in the title or icon
  • Copyrighted media without rights
  • Listing implying an official relationship

What to check

  • Every brand name and logo in the listing and app
  • Licences for media
  • Wording that suggests affiliation

Fix / reply / appeal guidance

  • Remove or license protected material
  • Rename or re-brand where needed
  • Provide authorisation documents if you appeal
Policy / guideline:
Impersonation and Intellectual Property policies
Category:
Store listing / impersonation / IP
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection Technical review likely

Permission requested without a qualifying use case

A restricted permission or API (SMS, Call Log, background location, accessibility, all-files access, package visibility) was requested without an eligible core use case or declaration.

Open entry ↓

Typical wording

Issue found: Violation of Permissions policy. Your app requests permissions that are not necessary for its core functionality.

Common causes

  • Library added a permission through manifest merging
  • Permission left over from a removed feature
  • Background location where foreground suffices

What to check

  • Merged manifest, not just your own
  • Which feature genuinely needs each permission
  • Whether a declaration form is required and completed

Fix / reply / appeal guidance

  • Remove unnecessary permissions and use privacy-friendly alternatives
  • Complete the declaration form only for eligible use cases
  • Update the SDK or remove it
Policy / guideline:
Permissions and APIs that Access Sensitive Information
Category:
Permissions / sensitive APIs
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play High Rejection Technical review likely

Personal or sensitive data collected without prominent disclosure

The app collects personal or sensitive user data (often via an SDK) without the in-app prominent disclosure and consent the User Data policy requires.

Open entry ↓

Typical wording

Issue found: Violation of User Data policy. Your app is collecting personal and sensitive user data without a prominent disclosure and runtime consent.

Common causes

  • Data transmitted before any disclosure is shown
  • Disclosure buried in the privacy policy only
  • Sensitive data (contacts, location, device identifiers) sent to third parties

What to check

  • When the first data transmission happens relative to the disclosure
  • Which SDKs transmit on initialisation
  • Whether the disclosure names the data and the purpose

Fix / reply / appeal guidance

  • Implement an in-app prominent disclosure with an explicit consent action before collection
  • Delay SDK initialisation until consent
  • Align the privacy policy and the Data safety form
Policy / guideline:
User Data policy — prominent disclosure and consent
Category:
User Data policy
Last verified:
Detailed guide: Data Safety Rejection Get this rejection reviewed
Google Play Medium Rejection Technical review likely

App account deletion requirement not met

Apps that allow account creation must offer in-app and web account deletion and declare it in the Data safety form.

Open entry ↓

Typical wording

Issue found: Account deletion requirement. Your app allows users to create an account but does not provide an option to delete it within the app and via a web link.

Common causes

  • No deletion option in the app
  • No web URL for deletion requests
  • Deletion exists but is not declared

What to check

  • In-app path to delete the account and its data
  • Public web page for deletion requests
  • Data safety form account-deletion answers

Fix / reply / appeal guidance

  • Implement real deletion (backend data removed or anonymised)
  • Publish a web deletion page
  • Update the Data safety declaration
Policy / guideline:
User Data policy — account deletion requirement
Category:
Account deletion requirement
Last verified:
Detailed guide: Data Safety Rejection Get this rejection reviewed
Google Play Medium Rejection Technical review likely

Data safety declaration does not match app behaviour

Google found a discrepancy between the Data safety form and what the app or its SDKs collect or share. The declaration and the real data flows must agree.

Open entry ↓

Typical wording

Issue found: Data safety section discrepancy. Your app is collecting or sharing user data that is not accurately declared in the Data safety section of your Play Console.

Common causes

  • Analytics, ads, crash or auth SDK collecting identifiers not declared
  • Location or contacts accessed by a library
  • Privacy policy contradicts the declaration
  • Account deletion not offered or not declared

What to check

  • Every SDK in the build and its published Data safety guidance
  • Merged manifest permissions
  • Network traffic from a release build
  • Privacy policy text versus declared types and purposes

Fix / reply / appeal guidance

  • Audit real data flows first, then correct the declaration or the app
  • Remove SDKs and permissions the core feature does not need
  • Implement account deletion and declare it
  • Do not over-declare data the app does not collect
Policy / guideline:
User Data policy — Data safety section
Category:
Data safety rejection
Last verified:
Detailed guide: Data Safety Rejection Full entry page Get this rejection reviewed
Google Play Medium Rejection Technical review likely

Disruptive or non-compliant ads

Ad behaviour, placement or the ads declaration violated the Ads policy.

Open entry ↓

Typical wording

Issue found: Ads policy violation. Your app displays ads in a manner that is disruptive or interferes with the app's usability.

Common causes

  • Full-screen ads at unexpected moments
  • Ads that cannot be dismissed or mimic system UI
  • Ads present but declared absent

What to check

  • Every ad placement and trigger
  • Ads declaration in App content
  • Ad SDK configuration

Fix / reply / appeal guidance

  • Fix ad implementation to meet the policy
  • Make the ads declaration accurate
Policy / guideline:
Ads policy
Category:
Ads policy
Last verified:
Detailed guide: Policy Violation Get this rejection reviewed
Google Play Medium Rejection Technical review likely

Invalid or unreachable privacy policy URL

The privacy policy URL in the store listing or the app is missing, unreachable, blocked, or does not describe the data the app actually handles. It is one of the fastest rejections to get and one of the easiest to fix properly.

Open entry ↓

Typical wording

Issue found: Invalid privacy policy URL. Your app's privacy policy link is not valid or does not lead to a privacy policy that covers your app.

Common causes

  • The URL 404s, redirects to a home page, or sits behind a login, consent wall or region block
  • The policy is a generic template that never names the SDKs, data types or purposes in the build
  • The policy belongs to the company rather than the app, and does not mention the app at all
  • The policy contradicts the Data safety form (collection, sharing, deletion, encryption)
  • The policy is a PDF or a document-sharing link rather than a public web page
  • The in-app link and the listing link point at different documents

What to check

  • Open the URL in a private window from a different country and device — it must load without login or consent gate
  • Does the policy name the data types, purposes, third parties and retention the app actually uses?
  • Does it describe account deletion, including the web deletion request path, where accounts exist?
  • Does it match the Data safety declaration line by line?
  • Is the same URL used in the store listing and inside the app?

Fix / reply / appeal guidance

  • Host the policy on a stable public URL under your own domain, with no login or interstitial
  • Write it from the app's real data flows — inventory the SDKs first, then describe collection, sharing, purpose and deletion
  • Reconcile it with the Data safety form before resubmitting; the mismatch is what triggers repeat rejections
  • Link the same URL in the listing and in the app, and keep it current when SDKs change
Policy / guideline:
User Data policy — privacy policy requirement
Category:
User Data policy
Last verified:
Detailed guide: Data Safety Rejection Full entry page Get this rejection reviewed
Google Play Medium Access denied

Production access application not approved

Your closed test met the minimum requirement but Google did not approve the app for production. The application answers, tester engagement or app readiness did not convince the reviewer.

Open entry ↓

Typical wording

Your application for production access has not been approved. Please continue testing your app and reapply when you have addressed the feedback in the application.

Common causes

  • Testers opted in but barely used the app
  • Application answers were generic and did not describe the testing process
  • Core features were never exercised during the test
  • The app still looks unfinished (placeholders, broken links, crashes)

What to check

  • Analytics or logs showing tester activity per feature
  • The answers you gave on the application form
  • Feedback you actually collected and the changes you shipped
  • Whether the store listing, privacy policy and Data safety form match the current app

Fix / reply / appeal guidance

  • Do not simply repeat the same 14 days; design a test that produces evidence
  • Reapply with specific, truthful answers backed by data
  • Fix readiness issues before reapplying
  • Never fabricate feedback or engagement
Policy / guideline:
App testing requirements for new personal developer accounts
Category:
Production access rejected
Last verified:
Detailed guide: Production Access Rejected Full entry page Get this rejection reviewed
Google Play Medium Rejection Technical review likely

Repetitive content / limited functionality: the app is not different enough

Google rejected or removed the app because it repeats content already on Play, offers too little functionality of its own, or is a thin wrapper around a website. This is a product judgement, not a configuration error, and cosmetic changes rarely clear it.

Open entry ↓

Typical wording

Issue found: Repetitive content. We don't allow apps that provide a repetitive or low-value experience, including apps that are duplicative of other apps already on Google Play.

Common causes

  • A website packaged in a WebView with no native capability the browser does not already provide
  • A template or white-label build published alongside near-identical apps from the same or related accounts
  • Several apps from one developer that differ only in branding, content feed or configuration
  • Content aggregated from other sources without permission, editorial value or attribution
  • A single-purpose utility whose whole function is one link, one PDF or one embedded feed

What to check

  • What can a user do in the app that they cannot do on your mobile website?
  • How many near-identical apps exist under your account or your clients' accounts?
  • Are the differences between variants real features, or only colours, names and content?
  • Do you have the rights to the content the app republishes?
  • Does the listing promise features the build does not contain?

Fix / reply / appeal guidance

  • Add capability that only an app can provide: offline use, notifications tied to real events, device integration, background sync, account-specific workflows
  • For white-label portfolios, consolidate into one app with accounts or configuration rather than one app per client, or give each variant genuinely distinct functionality
  • Remove republished content you cannot justify and replace it with your own
  • Align the listing with what the app actually does before resubmitting
  • Appeal only when the finding is factually wrong — for example when the reviewer matched you with an unrelated app; otherwise the fix is product work
Policy / guideline:
Spam, Minimum Functionality and Repetitive Content policies
Category:
Broken functionality / minimum functionality
Last verified:
Detailed guide: Policy Violation Full entry page Get this rejection reviewed
Google Play Low Access denied

More testing required before production access

Google asked for additional closed testing. The count or duration may have been met, but the test did not demonstrate meaningful engagement or readiness.

Open entry ↓

Typical wording

Based on your responses and the testing data available, more testing is required before your app can be released to production.

Common causes

  • Testers dropped out before the end of the period
  • Only the first screen was used
  • No feedback collected or acted on

What to check

  • Opt-in retention across the whole period
  • Feature usage per tester
  • Changelog of builds pushed during the test

Fix / reply / appeal guidance

  • Recruit engaged testers who match your audience
  • Give testers tasks that cover the core flows
  • Collect feedback in a quotable form and fix what it surfaces
  • Prepare a testing evidence summary before reapplying
Policy / guideline:
App testing requirements for new personal developer accounts
Category:
More testing required
Last verified:
Detailed guide: More Testing Required Get this rejection reviewed
Google Play Low Rejection Technical review likely

Reviewer could not access the app (login or credentials)

The reviewer could not sign in or reach restricted features. App-access instructions were missing, incomplete or no longer worked.

Open entry ↓

Typical wording

Issue found: Unable to access app. We were unable to access all or some of the functionality in your app. Please provide valid credentials and instructions in the App access section.

Common causes

  • Demo credentials expired, rotated or single-use
  • OTP or SMS verification with no reviewer path
  • Social login only
  • Backend blocking the review region

What to check

  • App access section in Play Console matches the current build
  • Review account reaches every restricted feature
  • A cold tester can follow the instructions on a clean device

Fix / reply / appeal guidance

  • Provide durable review credentials with an OTP bypass for that account
  • Add an email/password path alongside social login
  • Allow-list the review path on the backend
  • Write instructions as a step-by-step script
Policy / guideline:
Prepare your app for review — app access
Category:
Reviewer / app access
Last verified:
Detailed guide: Reviewer / App Access Rejection Full entry page Get this rejection reviewed
Google Play Low Warning / notice

Version code already used: Play Console refuses the bundle

Play Console rejects the upload because an app bundle with that version code was uploaded before. Version codes are consumed permanently across every track, including builds that were later deleted or never released.

Open entry ↓

Typical wording

Version code 42 has already been used. Try another version code.

Common causes

  • The same bundle was uploaded earlier to internal, closed or open testing
  • A previous upload was deleted or superseded — the version code stays consumed
  • CI produces the version code from a value that does not increase (a date component, a branch counter that reset)
  • Several build flavours or ABIs share one version code, or a flavour was bumped while another was not
  • A Flutter, React Native or Unity project where the version is set in two places and they disagree

What to check

  • Play Console → App bundle explorer: the highest version code that exists in any track
  • Where versionCode is actually set: build.gradle(.kts), pubspec.yaml (build number after the +), Unity Player Settings, or a CI variable
  • Whether an ABI split or flavour strategy multiplies the version code
  • Whether the previous upload was a manual one-off that the pipeline does not know about

Fix / reply / appeal guidance

  • Raise the version code above the highest ever uploaded — not above the highest released
  • Derive the version code from a monotonic source (a CI build counter or a timestamp with enough resolution), so it can never repeat
  • Keep the user-facing version name separate from the version code; only the code must increase
  • Document the version scheme so manual builds and the pipeline cannot collide
Policy / guideline:
Play Console release requirements (version codes)
Category:
Target API level requirement (update blocked)
Last verified:
Detailed guide: Google Play Submission Checklist Full entry page Get this rejection reviewed

Your message is not in the library?

Send it to us. Classifying unfamiliar notices is how the library grows — and how you get a specific answer instead of a category.

What happens next: an engineer on our technical team reads the notice you send — not an autoresponder. We work out what it most likely means and what we would check, and reply with that assessment and a recommended next step.

Initial rejection review is free. Technical implementation, if required, is quoted separately.

Get My Free Rejection Review

Free initial review · No payment required · No source code required initially