Apple reviewed 9,100,620 app submissions in 2025 and rejected 2,093,244 of them: 23.0%, or roughly one in four. Google doesn't publish a rejection rate, but it says it stopped more than 1.75 million policy-violating apps from being published on Google Play in the same year. Those are big numbers, and the useful part is underneath them: which rules the rejections fall under, how that has moved since 2022, and what that tells a release team to check before pressing Submit.
Everything below comes from the two stores' own reports: Apple's App Store Transparency Reports for 2022 to 2025 (the 2025 report went up on 20 May 2026), Apple's fraud-prevention newsroom posts, its App Review page, and Google's yearly Play safety posts (the 2025 one is dated 19 February 2026). Where a figure is our own division of theirs, we say so. We read every source on 1 November 2026.
Apple: four years of submissions and rejections
Two things stand out. Volume is up 49% in three years (6.1 million to 9.1 million submissions) while rejections grew only 25%, so the rejection rate has fallen every year, from 27.5% to 23.0%. And Apple doesn't count apps here: every new version and every resubmission after a rejection is a submission, and Apple notes that an app may go to App Review several times before it is approved. Apple's 2025 newsroom post splits the 2 million+ rejections into more than 1.2 million for new apps and nearly 800,000 for updates.
The 'approved after rejection' line is the reassuring one. In 2025 Apple counted 387,087 submissions approved after an earlier rejection, which is 18.5% of the rejected total, up from 15.3% in 2024. A rejection is usually a round trip, not the end of the app.
Why Apple rejects: the guideline sections
Apple's reports break rejections down by the five sections of the App Review Guidelines, not by individual guideline. A submission can break several rules at once, so in 2025 the sections add up to 2,704,747 rejection reasons for 2,093,244 rejected submissions: 1.29 reasons per rejection on average (1.19 in 2022).
Performance is the giant: almost two out of three rejected submissions failed something in section 2, and about one in seven of all submissions (14.9%). Section 2 is where Apple's one per-guideline statistic lives. Its App Review page says:
In practice 2.1 means: the app crashed or hung on the reviewer's device, a button or link went nowhere, a screen still had lorem ipsum or a 'coming soon' tab, or the reviewer couldn't get past a login because no demo account (or a broken one) was given in the review notes. None of those need a policy expert to fix. They need someone to install the exact build you upload and walk through it on a clean device.
How the mix moved from 2022 to 2025
Design is the fastest climber: from 212,464 rejections in 2022 to 415,532 in 2025, nearly double, as Apple pushes harder on copycats, thin apps and spam. Apple's 2025 fraud post puts more than 371,000 rejections down to copying, spam or misleading users, up from 320,000 in 2024 and 248,000 in 2023. If you publish several near-identical apps (one per city, one per client, a white-label template), this is the section that catches you. Business grew 35% in a year (209,845 to 283,820), which tracks with more apps selling subscriptions and digital goods.
Privacy is the other number to know. Apple's 2025 fraud post says more than 443,000 submissions were rejected for privacy violations (400,000 in 2024, 375,000 in 2023). That is a slice of the Legal section (495,673), and the usual causes are missing or broken privacy policy links, permission prompts that don't say why, data collection that doesn't match the privacy label, and required-reason APIs or SDK privacy manifests left out of the build.
Removals are a different list
Apps already on the store get removed for different reasons. The 2025 report lists 166,899 removals, led by fraud (90,608 under the Developer Program License Agreement's fraud clause) and a cleanup of outdated apps under guideline 4.0 Design (72,271). Apple's supplemental data gives per-guideline counts for removals only, and the familiar review guidelines are small there: 4.3 spam 418, 4.1 copycats 279, 2.3.1 hidden features 107, 2.1 completeness 41, 5.1.1 data collection 19. Hidden features matter more in review than in removals: Apple's newsroom post counts more than 22,000 rejections for hidden or undocumented features in 2025 (43,000+ in 2024). Appeals rarely win removals back: 26,305 removal appeals in 2025 led to 423 restorations, 1.6%.
Google Play: what Google publishes
Google gives totals for what it blocked, not a submission count, so there is no Play rejection rate to compare with Apple's. These are the figures from its yearly safety posts:
Every blocked count fell in 2025, and Google doesn't break any of them down by policy. Still, the pattern for ordinary teams is clear from the one reason Google itemises every year: permissions and sensitive data. Asking for SMS, call log, all-files access, background location, exact alarms or the accessibility service without a core use and a matching declaration in Play Console is the fastest way to a rejection. Google also says it runs more than 10,000 safety checks on every app it publishes.
Google publishes review time guidance rather than statistics: reviews of some apps, especially from new developer accounts, can take up to 7 days or longer (Play Console Help, answer 9859751). New personal developer accounts must also run a closed test with at least 12 testers for 14 days before they can apply for production; we covered that rule day by day in our article on Google Play's 12 testers rule.
What the numbers mean for your release plan
Apple says it reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Put that next to a one-in-four rejection rate and you can size the buffer a release needs. A worked example for an iPhone release you want live by Friday:
So 'submit two working days ahead' covers you only if you pass first time, which three in four submissions do. Submitting four to five working days before the date you've promised covers one rejection and fix at Apple's 90% review time. Phased release on iOS and staged rollout on Play then add their own days after approval; our article on phased rollouts has those numbers.
Before you submit: a checklist built from the numbers
Ordered by the share of rejections each item maps to. Apple's App Review page lists 14 common issues; every one is in here, with the guideline it falls under.
1. Performance, 64.7% of Apple rejections
2. Legal and privacy, 23.7%
3. Design, 19.9%
4. Business, 13.6%
5. Google Play
Two of these are about the build file rather than the app: whether the archive you're uploading is signed with the profile you think it is, and whether it asks for what you expect. Our IPA and APK inspector shows version, profile type, permissions and target SDK from the file itself, and the new provisioning profile inspector lists the profile's type, expiry, devices, certificates and entitlements for the app and each extension. Both run in your browser and upload nothing.
Check the exact build before it goes to review: drop the .ipa into the provisioning profile inspector to see its profile type, expiry, certificates and entitlements for every target, and use the IPA and APK inspector for version, permissions and target SDK. Nothing is uploaded.
Open the profile inspectorSources
Related on aipps.dev: Privacy manifests for React Native apps (https://aipps.dev/articles/react-native-privacy-manifest-required-reason-api-itms-91053), Google Play's 12 testers for 14 days rule (https://aipps.dev/articles/google-play-12-testers-14-days-closed-test-production-access) and phased rollouts on both stores (https://aipps.dev/articles/app-store-phased-release-vs-play-staged-rollout-percentages).
