Apple rejected 23% of App Store submissions in 2025, and most rejections cited Performance

Apple reviewed 9,100,620 App Store submissions in 2025 and rejected 2,093,244 of them, a rejection rate of 23.0%. The Performance section of the App Review Guidelines was cited in 1,354,418 of those rejections, more than Legal, Design, Business and Safety put together. For a team preparing an app for review, that makes Performance the sensible place to start a final pre-submission check.

Many articles about App Store rejection quote rates that no public source supports. Apple publishes its own figures every year in its App Store Transparency Report, so we started there, added the guideline text and Apple's App Review pages, and built everything below from those.

Apple rejected 23% of App Store submissions in 2025

Apple does not state a rejection rate. It publishes two counts side by side, and the rate is our arithmetic: 2,093,244 rejected divided by 9,100,620 reviewed is 23.0%.

Two details change how that figure should be read. First, the report counts submissions, not apps. Apple's first footnote says apps may go through App Review several times before they are approved, so an app rejected twice and approved on the third attempt adds three submissions and two rejections. Second, a rejection is often a step rather than an ending. The same report lists 387,087 "app submissions approved after rejection", which is 18.5% of everything rejected that year.

Apple's newsroom post of May 20, 2026 adds a split the report itself does not give. The 2 million rejected submissions were "including over 1.2 million new apps and nearly 800,000 app updates". New apps make up the larger share of rejected submissions, though Apple's figures do not say how many of those were first attempts, since a new app can be submitted more than once.

The rejection rate has fallen every year since Apple began reporting

Apple has published four transparency reports, covering 2022 to 2025, and the rate dropped in each one.

• 2022: 1,679,694 rejected of 6,101,913 reviewed, or 27.5%
• 2023: 1,763,812 of 6,892,500, or 25.6%
• 2024: 1,931,400 of 7,771,599, or 24.9%
• 2025: 2,093,244 of 9,100,620, or 23.0%

Submissions grew 49.1% between 2022 and 2025, while rejections grew 24.6%. Apple links part of that volume to new tooling, writing in the same newsroom post: "As powerful AI development tools drive a surge in app submissions". We would not read the falling rate as App Review going soft, because the report does not say why the rate moved. It also says nothing about any single category of app or developer. What it does rule out is a claim that turns up in search results for this topic, that Apple's overall rejection rate is climbing. On Apple's own numbers, it fell four years running.

Performance appears in more rejections than every other section combined

Apple breaks rejections down by the five sections of its guidelines. The 2025 counts were Performance 1,354,418, Legal 495,673, Design 415,532, Business 283,820, Safety 151,159 and Other 4,145. Legal, Design, Business and Safety together come to 1,346,184, which is 8,234 fewer than Performance alone. The margin is narrow, but it is there.

These counts overlap, so they cannot be added up to a total. Apple's second footnote says a submission may be rejected for failing one or more guidelines. The six section counts sum to 2,704,747 against 2,093,244 rejected submissions, so the average rejected submission was cited under about 1.29 sections. That is a count of section citations, not of distinct problems. A fairer way to state Performance's weight is as a share of rejected submissions: 1,354,418 divided by 2,093,244 is 64.7%. If each submission is counted once per section, which the report implies but does not say outright, about two in three rejected submissions had at least one Performance problem.

That share has been steady, from 60.6% in 2022 to 64.7% in 2025, and Performance, Legal, Design, Business and Safety came in that order in all four reports.

Performance in Apple's guidelines means a finished, accurate, current app

The section name suggests frame rates and load times, and that is not mainly what it covers. Apple's App Review Guidelines are "arranged into five clear sections: Safety, Performance, Business, Design, and Legal", and Section 2, Performance, holds 2.1 App Completeness, 2.2 Beta Testing, 2.3 Accurate Metadata, 2.4 Hardware Compatibility and 2.5 Software Requirements.

Guideline 2.1(a) is worth reading slowly. It says submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission." It continues: "Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login." And it ends: "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." Guideline 2.1(b) adds that in-app purchases must be "complete, up-to-date, visible to the reviewer and functional."

Guideline 2.3 asks that "all your app metadata, including privacy information, your app description, screenshots, and previews accurately reflect the app's core experience". Its subsections are specific. Screenshots "should show the app in use, and not merely the title art, login page, or splash screen" (2.3.3), and "App names must be limited to 30 characters" (2.3.7). Guideline 2.2 sends unfinished builds elsewhere: "Demos, betas, and trial versions of your app don't belong on the App Store", with TestFlight named as the place for them.

Guideline 2.5.1 opens with "Apps may only use public APIs and must run on the currently shipping OS", and 2.5.5 says "Apps must be fully functional on IPv6-only networks." Keeping up with the currently shipping OS is a recurring cost, not a one-off, and we cover that calendar in our post on platform deadlines and maintenance cost. Section 2 also now carries the rule against hidden features: 2.5.19 says "Don't include any hidden, dormant, or undocumented features in your app".

Apple's App Review page says it plainly: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more." That measures unresolved issues, not rejections, so it is a different metric, but it points the same way.

Legal, Design, Business and Safety cover different risks, from privacy to minimum functionality

The other four sections cover legal compliance, design quality and minimum functionality, payment rules, and user safety. Together they were cited less often than Performance alone, but each one can stop a legitimate product.

Legal, cited in 495,673 rejections, is where privacy sits. Apple's App Review page says a privacy policy must, among other things, identify "the data the app collects, how it collects that data, and all uses of that data." Design, cited in 415,532, is defined in the report's third footnote as the category covering copycat apps, apps with minimum functionality, and spam. On minimum functionality, the App Review page is blunt: "Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app." If you are still deciding whether your product needs a native app at all, our comparison of web apps and mobile apps in 2026 covers what actually forces that choice.

Business, cited in 283,820, centres on payments. Guideline 3.1.1 sets the general rule: "If you want to unlock features or functionality within your app", for example subscriptions or premium content, "you must use in-app purchase." The guidelines also list exceptions, such as reader apps under 3.1.3, and some storefronts have their own entitlements, so check the rules for your app type and region. Safety, cited in 151,159, covers objectionable content, user-generated content, apps for kids and physical harm.

Apple's newsroom post also gives some 2025 counts that cut across sections: "over 443,000 submissions for privacy violations", "over 371,000 submissions that copied other apps, were found to be spam, or otherwise misled users", and "over 22,000 submissions for containing hidden or undocumented features". Copycat and spam rules target specific kinds of abuse. Privacy, minimum functionality and completeness are different: they can catch an otherwise legitimate product, so a team should check for all three before submitting.

The highest-leverage pre-submission work is a completeness pass

Every item below comes from Apple's own text: the Before You Submit list at the top of the guidelines, Section 2, and the App Review page.

• "Test your app for crashes and bugs", on a real device and on the latest OS release.
• Scrub "placeholder text, empty websites, and other temporary content" from the build and the listing.
• Open every URL in the app and the listing. Guideline 2.1(a) asks for "fully functional URLs".
• "Provide App Review with full access to your app." If it has accounts, that means "either an active demo account or fully-featured demo mode, plus any other hardware or resources that might be needed to review your app (such as login credentials or a sample QR code)."
• "Enable backend services so that they're live and accessible during review." A staging server that sleeps overnight counts as off.
• "Include detailed explanations of non-obvious features and in-app purchases in the App Review notes, including supporting documentation where appropriate."
• Make in-app purchases "complete, up-to-date, visible to the reviewer and functional".
• Check that the description, screenshots and previews "accurately reflect the app's core experience", and that screenshots "show the app in use".
• Keep the name within 30 characters, and keep metadata free of "trademarked terms, popular app names, pricing information, or other irrelevant phrases".
• List significant changes in What's New. Guideline 2.3.12 allows a generic note only for "Simple bug fixes, security updates, and performance improvements".
• Use only public APIs, build for the currently shipping OS, and confirm the app is "fully functional on IPv6-only networks."
• "Provide required documentation for apps and features that require regulatory approval."

The App Review page warns that without the required review information, "the app review process may be delayed and your app may not pass review." A list like this only helps if each item is checked in a way that could actually fail: log in with the demo account from a clean device, on the network the reviewer will use, rather than ticking a box that says the account exists. That is the argument we make in a check that cannot fail tells you nothing.

A rejection is a conversation first and an appeal second

Apple's process starts with a reply, not a dispute. A rejection message names the guidelines the submission did not meet, and you can respond to App Review in App Store Connect, clarify, fix and resubmit.

The App Review Board is for genuine disagreement. Apple's appeal help page says: "Before filing an appeal, reply to the rejection, removal, or termination message you received in App Store Connect and provide clarification about the issue. If this clarification is not sufficient to resolve the issue, proceed with filing an appeal." In the appeal, "point to the specific requirements involved and explain how your app satisfies them."

The same page sets firm limits. "Only submit one appeal per rejected or removed app", and if the rejection cites several guidelines, that one appeal should address all of them. "Don't file an appeal for requests from App Review for additional information or documentation about your app." "Don't file an appeal if you've addressed the issues App Review identified" and resubmitted. Apple's own example of a well-formed appeal is, fittingly, a 2.1 case: "My app was rejected under Guideline 2.1 for incomplete information. The demo account and setup steps needed to test the flagged feature are included in the App Review Information section of this submission". And Apple is clear that "Submitting a complete appeal does not guarantee that the App Review Board will overturn the rejection, removal, or termination."

Apple also accepts requests for expedited review, for example for a critical bug fix, and lets an eligible bug fix update ship while other issues found in review are fixed in the next submission, as long as there are no legal or safety concerns.

On timing, Apple's App Review page currently says App Review is "typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours." Older Apple material, including a developer Tech Talk, gave 90% within 24 hours, and many third-party pages still quote that figure. Whichever you plan around, check the date of the Apple page you are citing, and leave room for a resubmission.

The transparency report publishes no statistics on appeals of rejections. Its appeal figures cover app removals: 26,305 appeals in 2025 and 423 restorations, or 1.6%. Apple's footnote explains that most appealed removals involve illegality or fraud. That number tells you nothing about the odds of appealing an ordinary rejection.

The transparency report has limits worth respecting

Apple's report is the best public data on App Review, and it is still narrow.

• It reports sections, not guideline numbers. You cannot get a count for 2.1 or 2.3 from it. The 40% figure for 2.1 comes from a different page and measures unresolved issues.
• Section counts overlap. They show how often a section was cited, not how many submissions failed for that reason alone.
• The totals include bad actors. Apple terminated 193,035 developer accounts in 2025, 192,702 of them for fraud, and the copycat and spam submissions sit in the same counts as honest mistakes.
• It is Apple's own data, without outside audit. Apple publishes no first-submission rejection rate, so pages claiming that 40% or more of first submissions are rejected are not quoting Apple.

Google Play does not publish a comparable rate. Google's 2025 safety post, dated February 19, 2026, says that "In 2025, we prevented over 1.75 million policy-violating apps from being published on Google Play", down from the 2.36 million Google reported for 2024. Without a count of apps reviewed, no rate can be calculated, so any Google Play rejection percentage you see is not Google's.

What the data does support is simple. Two in three rejected App Store submissions in 2025 cited the section about whether an app is finished, accurate and current. The last stretch before submission is unglamorous: a build that runs on a device, a server that is up, an account that works, and a listing that tells the truth.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.