Quick answer
Using Google's 2025 Annual Transparency Report, the Google Play submission rejection ratio is about 7.89%: 1,692,467 rejected submissions divided by 21,461,250 reviewed. This is a calculation from Google's published counts, not a 2026 full-year rate and not the probability that a new app will fail its first attempt. Google's separate enforcement figures measure different outcomes.
Source: 2025 Google Play Annual Transparency Report (PDF), published March 31, 2026, global scope. The 2024 report gives 10.13% on the same basis.
This guide explains Google's recent submission and enforcement figures, their limits, and the practical checks that help you respond to a rejection. The annual transparency dataset, the safety reviews and every policy page linked at the point of use were reviewed on September 12, 2026.
How to read the labels in this guide
- Google reportA figure printed in a Google transparency report or annual safety review, cited beside the number.
- CalculationArithmetic this guide performs on Google's published counts. Google does not print the result.
- Google policyA requirement or process described in Play Console Help or the Developer Program Policies.
- Practical checkA test we recommend from the submissions we support. Not a Google rule, and not a measured rejection frequency.
- ExampleAn illustration built to show the shape of a record. Not a client case and not a platform statistic.
On this page
What is the Google Play app rejection rate in 2026?
Google does not publish a percentage labelled “rejection rate”. It does publish, once a year, the two counts needed to calculate one: how many app submissions it reviewed and how many it rejected. The latest complete year is 2025, reported on March 31, 2026, so a 2026 guide works from 2025 activity.
The latest complete annual submission data
Google report| Activity year | Reviewed submissions | Rejected submissions | Rejected ÷ reviewed | Report published |
|---|---|---|---|---|
| 2024 | 19,292,647 | 1,955,305 | 10.13% | March 31, 2025 · report |
| 2025 | 21,461,250 | 1,692,467 | 7.89% | March 31, 2026 · report |
Source locations: 2025 report, printed page 3; 2024 report, printed pages 3-4. Percentages are calculated from the published counts (rejected ÷ reviewed × 100) and rounded to two decimals. Both reports describe their coverage as global. Data reviewed September 12, 2026.
See the calculation by year
Rejected share of all reviewed submissions
About 8 in every 100 reviewed submissions were rejected in 2025.
How the ratio is calculated and what it cannot predict
The ratio compares Google's reported global annual counts of reviewed and rejected app submissions. The reports do not provide a defined first-attempt cohort or a detailed breakdown by submission attempt, so this aggregate should not be used to predict a particular new app's outcome.
What the ratio does not establish
- Your app's odds. The complement (about 92%) is not a first-pass approval probability for a new app.
- A 2026 figure. Full-year 2026 data are not yet available. Label the number as 2025 data available in 2026.
- An eventual approval rate. The 2025 report also lists approvals after rejection, but not the cohort accounting needed for an approval-after-correction rate, so this guide does not compute one.
- A closed-testing or production-access approval rate. Access decisions for new personal accounts are a different process and are not reported in these tables.
- A trend in strictness. The fall from 10.13% to 7.89% is a change in the ratio, not proof that policy got easier, that review quality changed, or that an individual developer's risk fell.
Why websites quote different figures
Some pages say Google publishes no denominator; that was true of the safety-review series, not of the transparency reports. Others divide a safety-review “apps prevented” count by a transparency-report denominator, which mixes two series.
Google's rejection and enforcement statistics
Google reports platform safety in two places that are easy to confuse: the Annual Transparency Report, a table of submission and enforcement counts, and the annual safety review on Google's blogs, a narrative with rounded headline figures.
Reviewed and rejected submissions
Google reportBeyond the reviewed and rejected counts in the table above, the 2025 transparency report lists 2,012,981 removals and 125,550 terminated developer accounts. A removal acts on an app that was already available; a rejection is a decision about a submission before it goes live.
Source: 2025 Annual Transparency Report, printed page 3.
Apps prevented from publication, 2023 to 2025
Google report| Activity year | Policy-violating apps prevented from publication | Bad developer accounts banned | Source |
|---|---|---|---|
| 2023 | 2.28 million | 333,000 | 2023 safety review (April 29, 2024) |
| 2024 | 2.36 million | More than 158,000 | 2024 safety review (January 29, 2025) |
| 2025 | More than 1.75 million | More than 80,000 | 2025 safety review (February 19, 2026) |
The same reviews add context that is not a rejection count. In 2023, nearly 200,000 submissions were rejected or remediated over sensitive permissions such as background location and SMS. In 2024, 1.3 million apps were stopped from getting unnecessary or excessive access to sensitive user data; in 2025 that figure was more than 255,000, alongside 160 million spam ratings and reviews blocked. These measures are not additive with each other or with the table.
Google also describes running more than 10,000 safety checks on apps before and after release. The count does not mean every small defect is an automatic rejection, or that all of those checks are pre-publication gates.
Why rejection, removal, and prevention counts differ
| Source | Metric | Unit | Period | What it does not cover |
|---|---|---|---|---|
| Annual Transparency Report | Rejected submissions | Submissions, not a stated unique-app cohort | Calendar year | Whether the same app was later approved |
| Annual Transparency Report | Removals | Apps removed after publication | Calendar year | Submissions that never went live |
| Annual safety review | Apps prevented from publication | Apps, rounded | Calendar year | A denominator; it cannot be turned into a rate |
| Annual safety review | Developer accounts banned | Accounts | Calendar year | Individual app rejections |
Google's annual transparency report and annual safety review use different metric labels and report different totals. Keep each number attached to its source and definition. The reviewed reports do not explain a direct conversion between the two series, so they should not be combined to calculate one rejection rate.
A platform aggregate and a provider's measured outcome can both be true. PrimeTestLab's managed test-completion rate describes closed tests it runs and keeps staffed to their end date; Google's ratio describes the reported app-submission counts. Neither predicts the other.
What kind of Google Play decision did you receive?
Before fixing anything, identify which decision you are looking at. “Rejected” is used loosely for at least five situations, and the next step differs for each. The status in Play Console and the email to the account owner name it.
Google policyTap the notice you received
| Decision or blocker | Your situation | Next step |
|---|---|---|
| App or update rejected | The submitted changes were not accepted. An ordinary update rejection leaves the earlier published version available while you correct it. | Read the notice, correct the affected submission, and resubmit. See after a rejection. |
| Production access refused, or “More testing required” | Your application to move a new personal account's app into production needs further work; it is a readiness decision about the closed test. | Follow the testing and readiness steps, then fix a production-access testing refusal. |
| App removed | The listing is no longer available. The app had been published, and enforcement acted on it after the fact. | Follow the enforcement notice and submit a compliant update through the route it names. |
| App suspended, or account terminated | Stronger app-level or account-level enforcement, each with its own notice and consequences. | Use the appeal process named in the notice. Do not open another account to republish; that is treated as a violation. |
| Upload or compatibility blocker | The submission cannot proceed as prepared: for example a target API level below the current floor, or a bundle the Console will not accept. | Resolve the stated technical requirement, then submit again. No review has happened yet. |
Status meanings: Play Console Help, Publish your app and Enforcement process.
What a status does not tell you
An unavailable app was not necessarily policy-rejected: it may have been unpublished by you or held back by a compatibility rule. And a production-access refusal can have more than one cause, so the row above is a route, not a diagnosis. A closed-track release can itself undergo policy review; a production-access application is the separate testing-readiness decision.
Documented rejection risks and practical fixes
Google does not publish a ranked list of rejection reasons, and this guide does not invent one. The eight checks below run in the order you can perform them, from the build outward, each with its policy source. Closed-testing items live in the testing section: they are eligibility conditions for new personal accounts, not policy rejections.
Stability and useful functionality
Crashes, freezes, and failed installs
- The problem
- Google's functionality policy prohibits apps that crash, force close, freeze, or otherwise function abnormally, including apps that do not install, install but do not load, or load but do not respond.
- One observable test
- Fresh install of the exact release candidate on two physical devices: open, sign in, complete the core flow, background and resume. Then read the pre-launch report for crashes and ANRs (application not responding).
- The correction
- Fix startup crashes and ANRs before submitting, then repeat the same flow on the rebuilt binary.
Static content without app-specific functionality
- The problem
- The same policy covers limited functionality or content: static content with no app-specific utility, very little content, or an app designed to do nothing. The format alone does not determine compliance; the app still needs adequate utility and content.
- One observable test
- Demonstrate the app's core function and explain the useful outcome it provides. Check that it has adequate content and meaningful functionality rather than merely displaying static material.
- The correction
- Add the functionality or content that gives the app adequate utility for its intended use.
Reviewer access
The reviewer cannot reach restricted or core functionality
- The problem
- Google asks for working sign-in details and instructions for any feature behind a login, a location restriction, or unusual authentication. Without them the reviewer meets a wall, and an app that cannot be reviewed is not approved.
- One observable test
- Install the release you are submitting on a device with no history, and use only the credentials and instructions in the App content page. If you needed anything else to get in, the reviewer does too.
- The correction
- Provide a dedicated review account that does not expire, and step-by-step instructions for every gated feature. Not every app needs a login; and a working account is a precondition for review, not a guarantee of approval.
Source Prepare your app for review
Permissions, privacy, and Data safety
Permission scope and declarations
- The problem
- Sensitive permissions such as background location and SMS need a use case the app visibly delivers, and where a declaration form exists it must match what the app does. Google's 2023 safety review reported nearly 200,000 submissions rejected or remediated over exactly this.
- One observable test
- List every dangerous permission in the manifest and, for each one, name the screen where the user sees why it is needed.
- The correction
- Remove anything without a visible use case, and make the Console declarations describe the behaviour the reviewer will observe. A feature-related reason is not sufficient by itself: check the applicable permission restrictions and any required prominent disclosure and consent before access.
Source User Data policy · 2023 safety review
Privacy policy and account deletion
- The problem
- Provide the privacy-policy URL in Play Console and a link or the policy text inside the app. The page must be public, not geofenced, not a PDF and not editable by visitors, identify the app or developer, and describe the data actually collected. If users can create an account from within the app, provide discoverable ways to request deletion from within the app and externally, and disclose necessary retention.
- One observable test
- Open the URL from a logged-out device, from another country if you can, and read it against the Data safety form.
- The correction
- Publish a policy page you control, provide it in Play Console and in the app, and add the deletion-request routes where the app creates accounts.
Source User Data policy
Data safety and SDK consistency
- The problem
- The Data safety declaration must reflect what the app and every third-party SDK inside it collect and share. Advertising, analytics and crash-reporting SDKs can collect or share data without a runtime permission, so a “no permissions” app is not automatically a “no data” app, and a live privacy page does not establish that the form is accurate. Check the specific SDK version, configuration and actual behaviour.
- One observable test
- Export the release's dependency list, look up each SDK's data disclosure, and compare it with every answer on the form. Watch the network on first launch to see what leaves the device before the user does anything.
- The correction
- Correct the form to match observed behaviour, or remove the SDK. You are responsible for the declaration, including for code you did not write.
Listing, declarations, and payments
Store listing, ads, audience, and content declarations
- The problem
- The App content section asks whether the app contains ads, which audience it targets, and for the content ratings questionnaire and other applicable declarations. A listing that shows features the build lacks, or a declaration that disagrees with the app, is a rejection on its own.
- One observable test
- Walk each App content answer with the release open beside you, and check every screenshot against the current interface.
- The correction
- Update declarations and listing assets with the build they describe; a listing correction may not need a new binary.
Source Prepare your app for review
Payments and applicable program conditions
- The problem
- Google Play's billing system is required for certain in-app purchases of digital goods and services. Physical goods, real-world services and some other categories are excluded, and alternative-billing or external-offer programs apply in specific regions under their own conditions.
- One observable test
- For each purchase flow, decide whether it sells digital content consumed in the app; if so, confirm it runs through Play Billing or a program you are actually enrolled in.
- The correction
- Move digital purchases to Play Billing, or document the program enrolment. Do not treat a regional program as a global exemption.
Source Payments policy
Pre-review checks are not the review
Play Console's pre-review checks flag some of these before you submit (missing credentials, permission declarations, a broken privacy link), and the pre-launch report exercises the app on test devices. Both are worth running; passing them does not guarantee approval in formal app review, and neither measures how a closed test's participants used the app.
Sources: Detect app issues early with pre-review checks · Use a pre-launch report to identify issues
How closed testing affects production access
Who needs to meet the testing requirement?
Google policyPersonal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for the last 14 days before they can apply for production access. Meeting the minimum makes you eligible to apply; it does not approve the app. Organisation accounts and personal accounts created before that date are not subject to the requirement.
Internal testing does not substitute for the closed test, however long it runs: the 12 testers have to be opted in on a closed track. Setup detail lives in the Google Play closed-testing requirements guide.
Source: App testing requirements for new personal developer accounts.
Evidence, readiness, and the next step
From qualifying test to production release
- 1Complete the qualifying closed test. At least 12 testers, opted in for the last 14 days without interruption.
- 2Apply for production access. The application asks how testers used the app, what feedback you received, and what changed as a result.
- 3Google reviews the application, usually in 7 days or less, sometimes longer, and either grants access or asks for more testing. That estimate belongs to this review, not to your whole launch timeline.
- 4With access granted, prepare the production release. Its review and its rollout are separate steps from this decision; access is eligibility, not publication.
If one tester opts out, that tester's qualifying period is interrupted and their days no longer count. The other testers are unaffected. What matters at application time is whether you still have 12 who qualify, not whether anyone ever left.
Google asks what you learned; it does not set a minimum number of updates. The readiness statement to be able to make honestly is: I reviewed tester feedback, addressed issues where needed, and can explain what I learned and why the app is ready. If the honest answer is that nobody used the app, the review is likely to reach the same conclusion.
A few testers above 12 give you a buffer against drop-outs and broader feedback; we do not claim a measured lift in approval from it. Cover representative physical devices as a QA choice. The published criteria say nothing about how emulators are counted, so this guide makes no claim either way. Related: plan a tester buffer, the production-access application questions, and what to check after a refusal.
What to do after an app or update is rejected
The notice names the decision, the affected submission, and the policy or requirement involved. Work from it, in this order.
Google policy- 1Read the exact decision and the affected submission. Which release, which track, which policy or requirement.
- 2Reproduce or inspect the cited problem on the build that was reviewed, not the one on your desk.
- 3Correct the issue and check the related requirements in the same area, so the next review does not find the neighbour.
- 4Validate the affected build or declaration: rerun the observable test from the relevant check above.
- 5Submit the appropriate correction, or use the appeal route if you believe the decision is mistaken. Where required, open Publishing overview and select Send for review; saving a correction does not always submit it automatically.
- 6Keep the evidence and monitor the result. Notice, version, issue, correction, validation, decision.
Correct and resubmit, or appeal
If the finding is right, correct it and resubmit. Google's enforcement guidance is explicit that resubmitting without fixing the violation is itself a problem. Do not resubmit while the cited violation remains unresolved; some fixes change the listing or declarations without changing the binary. If you believe the decision is mistaken, follow the appeal instructions in the notice and include the package name, affected version, cited policy, why you believe the decision is mistaken, and screenshots or reproducible steps that demonstrate compliance. Do not attempt to republish through another account.
Sources: Enforcement process · Control when app changes are reviewed and published.
Binary fix or declaration fix?
A listing or declaration correction may not require a new binary. A new build is needed when the fix changes packaged code, assets, permissions or configuration. Website or server-side corrections can sometimes resolve the issue without rebuilding. Follow the notice and validate the affected submission.
Google describes general app-change processing as a few hours to seven days, sometimes longer. That is not a guaranteed resolution time for your rejection or appeal, and production-access review is a separate process; see Google Play review time. No number of permitted rejections or appeal success probability is published, and none is promised here.
What a useful rejection record looks like
ExampleTwo illustrative records, constructed to show the shape of the evidence worth keeping: one for an update rejection and one for incomplete testing eligibility. Not client cases, and not statistics. Keep the submission ID from Play Console's Submission activity with the notice and affected version so support can identify the exact submission.
| Notice | Update rejected, User Data policy |
|---|---|
| Affected version | 2.4.1 (build 241), production track |
| Issue | Privacy policy link in the listing returned 404 |
| Correction | Restored the privacy-policy page at the existing URL already used in Play Console and the app. No embedded URL changed, so no new binary was required. |
| Validation | URL opened from a logged-out device in two countries; Data safety form re-read against the page |
| Decision | Resubmitted; update approved |
| Notice | Testing eligibility incomplete |
|---|---|
| Affected version | 1.0.3, closed track |
| Issue | 12 testers added; only 9 stayed opted in through the 14 days |
| Correction | Three replacement testers recruited; each started their own 14-day period |
| Validation | Dashboard showed 12 testers opted in for the last 14 days |
| Decision | Qualified to apply after the replacement testers completed their required periods |
Pre-submission checklist
Run it against the exact release you are about to submit, not the one you tested last week. Items marked where applicable depend on what the app does.
Build and behaviour
Reviewer access and declarations
Privacy and data
Payments
Testing gate, new personal accounts only
Questions and answers
Does the annual ratio predict my app's first-review outcome?
No. The 7.89% ratio compares Google's reported global counts of reviewed and rejected app submissions for 2025. The reports do not provide a defined first-attempt cohort, so neither the ratio nor its complement is a probability for a particular new app.
Why is the safety-review count different from the transparency-report count?
They measure different things. The annual safety review reports rounded counts of policy-violating apps prevented from publication; the transparency report counts rejected submissions and removals. Google publishes no reconciliation between the two series, so they cannot be combined into one rate.
Does a rejected update affect the version already published?
An ordinary update rejection does not remove the published version; the earlier release stays available while you correct the update. Removal, suspension and account termination are separate enforcement statuses with their own notices, and those do affect the live app.
Is production-access refusal a policy rejection?
No. A production-access decision for a new personal account reviews the closed test you ran and the answers you gave. “More testing required” means the application needs further work; it is not a policy strike against the app, and more testers do not clear a genuine policy rejection.
Should I appeal or submit a correction?
Do not resubmit while the cited violation remains unresolved. Some fixes change the listing or declarations without changing the binary. If you believe the decision is mistaken, follow the appeal instructions in the notice and provide evidence of compliance. Do not create another account to republish; that is treated as a violation.
Sources and data notes
Where to go next depends on what you came for. To quote the rate, quote 7.89% with its year (2025 activity) and its denominator (reviewed submissions). To act on a notice, find its row in the decision table and follow that path. If the testing gate is the blocker, the closed-testing requirements guide covers setup end to end.
Bottom line
The Google Play submission rejection ratio for 2025 is about 7.89%, calculated from 1,692,467 rejected submissions and 21,461,250 reviewed in Google's 2025 Annual Transparency Report. It is a platform-wide historical figure, not your app's odds. A rejection notice names a specific decision: correct what it names, resubmit or appeal, and treat the testing gate for new personal accounts as a separate readiness step.
Annual transparency reports
Annual safety reviews
Policy and Play Console Help
Update history
February 28, 2026: published with the annual safety-review series only. September 12, 2026: added the transparency-report calculation and its limits, separated the two Google series, added the decision table, the reviewer-access, Data safety and post-rejection sections, and removed the ranked-reasons framing; a same-day second pass corrected the resubmission, functionality and review-timing wording. Next annual refresh when Google publishes the 2026 report, expected in 2027.