App Store Rejection Reasons and How to Fix Them

Apple rejected over 1.2 million new apps and nearly 800,000 app updates in 2025, out of more than 9.1 million submissions its App Review team evaluated. Privacy violations were the largest single category at over 443,000 rejections, followed by spam and copycat apps at over 371,000. Most rejections aren’t a verdict on your product idea, they’re mechanical problems with the build, the store listing, or a platform requirement that changed since your last release. Here’s what actually triggers each one, and what to do when you already have a rejection sitting in App Store Connect.

How often does Apple actually reject an app?

A little over one submission in five gets rejected, and the number has been roughly stable for two years running. Apple’s own fraud prevention reports give the raw figures. In 2024 the App Review team evaluated more than 7.7 million submissions and rejected more than 1.9 million of them. In 2025 it evaluated more than 9.1 million submissions and rejected over 1.2 million new apps plus nearly 800,000 updates, which comes to roughly 2 million rejections against a bigger pile of submissions.

The split between new apps and updates is the part worth sitting with, because it’s the number most articles on this topic leave out. Nearly 800,000 of those rejections landed on updates to apps that were already live and already approved once. If your app is in the store today and shipping fine, you’re still in the population that gets rejected, and the reason usually has nothing to do with the feature you just built.

That reframes what a rejection means. Read as a quality judgment, it leads teams to argue with reviewers and rewrite features nobody asked them to change. Read as a compliance check that failed on one specific named point, it leads to a fix that takes an afternoon, and the reviewer’s note always cites the guideline number telling you which point that was.

Which App Store rejection reasons are the most common?

Privacy leads by a wide margin, and Apple publishes enough of a breakdown to rank the rest. In 2025 the company rejected over 443,000 submissions for privacy violations, over 371,000 that copied other apps, were found to be spam, or otherwise misled users, nearly 59,000 for bait and switch behaviour, and over 22,000 for containing hidden or undocumented features.

Compare that to 2024 and the shape holds steady while the volume grows. Privacy rejections went from 400,000 to over 443,000, and spam or copycat rejections went from 320,000 to over 371,000. Hidden features moved the other way, from 43,000 down to over 22,000, which reads more like developers learning that undisclosed functionality gets caught than like Apple relaxing anything.

Those published categories don’t cover everything, though, and the gap matters when you’re trying to predict where your own submission will trip. Apple’s numbers describe the violations it treats as trust and safety problems. They don’t include the far more ordinary rejections that happen because a build crashed on launch, a screenshot showed a screen that no longer exists, or a reviewer couldn’t get past a login wall without credentials. Those fall under guideline 2.1 App Completeness and guideline 2.3 Accurate Metadata, and in day to day work they’re what most teams actually hit.

So the practical ranking looks different from the published one. Completeness and metadata problems are the most likely reason your specific submission comes back, privacy is the most likely reason it comes back with something serious attached, and the spam and copycat categories mostly affect a class of app that a legitimate business isn’t building in the first place.

Why does app completeness cause so many rejections?

Guideline 2.1 App Completeness covers a narrow idea with a wide reach: the reviewer has to be able to fully use your app, and anything that stops them counts as incomplete. That includes a crash on launch, a feature behind a login the reviewer can’t get through, a placeholder screen you meant to finish before release, and a backend that returns errors because the staging environment it points at is switched off over the weekend.

The single most common version of this is a missing or expired demo account. If any part of your app sits behind authentication, App Store Connect has a field for review credentials, and leaving it blank or filling it with a login that’s since been deactivated is a guaranteed round trip. The same applies to anything the reviewer can’t reach without help, such as a feature that only activates for a paid organisation or a screen that only appears after a scheduled job runs. The notes field is where you explain how to reach those, and using it well is one of the highest return five minutes in the whole submission process.

Guideline 2.3 Accurate Metadata is the sibling problem, and it’s about the store listing rather than the binary. Screenshots that show an older version of the interface, a description that mentions a feature you removed, keywords stuffed with competitor names, and an age rating that doesn’t match the content all fall here. This one catches maintained apps in a specific way. Screenshots go stale quietly over a year of small design changes, and nobody notices until a reviewer compares them to the current build. When we take over an existing app at RapidLabs, mismatched screenshots are one of the first things we look for, because it’s cheap to fix and it holds up releases that had nothing else wrong with them.

What privacy problems get an app rejected?

Privacy rejections come from a mismatch between what your app does and what you’ve declared, and there are now four separate places that declaration lives. Guideline 5.1.1 Data Collection and Storage requires a privacy policy that’s actually reachable, permission requests that explain themselves in context, and App Privacy answers in App Store Connect that match reality. The fourth place is newer and catches more teams than the other three combined.

Since May 1, 2024, uploads to App Store Connect have needed approved reasons declared for what Apple calls required reason APIs, and those declarations live in a privacy manifest file inside your project. Apple began emailing warnings about missing reasons on March 13, 2024 and made the declaration mandatory for uploads that May. Third party components carry their own obligation here: when you add an SDK from Apple’s list of commonly used ones, the manifest and signature requirements apply to that SDK, and binary dependencies need signatures too.

What makes this a maintenance problem rather than a one time task is that the obligation moves whenever your dependencies move. An app that declared everything correctly in 2024 can fail after a routine bump of an analytics or crash reporting library, because the new version of that library touches an API the old one didn’t. The failure arrives as an upload error before a human ever sees the build, which is at least fast feedback, but it’s also the kind of error that blocks a release on a Friday afternoon when the person who understands the dependency tree left the company two years ago.

The fix is unglamorous and works. Read the exact API and the exact SDK named in the error, check whether your app genuinely needs that call, and either declare an approved reason for it or replace the call with an alternative. Guessing at a reason to clear the error is the wrong move, since the declaration is a statement about what your app does and Apple checks it against behaviour.

Why does an update to a working app suddenly get rejected?

Because the requirements moved and your app didn’t, which is the whole story behind those nearly 800,000 update rejections. Apple maintains a page of upcoming requirements with dates attached, and each of those dates is a day when submissions that were fine yesterday stop being accepted. Three of them are already in force and catch older codebases hard.

Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later, using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26. This one has teeth beyond a version bump, because upgrading Xcode on a project that hasn’t been touched in a while tends to surface a chain of dependencies that also need upgrading, and each of those can bring behaviour changes with it. An app last built in 2025 can’t ship any update at all until that chain is resolved, which turns a one line bug fix into a real piece of work.

Since January 31, 2026, apps have had to respond to Apple’s updated age rating questions, and an unanswered questionnaire holds the submission regardless of what’s in the build. There’s also a regional requirement that surprises teams selling into Europe: trader status under the Digital Services Act has been required for apps in the EU since February 17, 2025, and for app updates since October 16, 2024. Missing trader information doesn’t reject your build on technical grounds, it just stops your app being distributable in a market you were counting on.

The pattern across all three is the same, and it’s the reason we treat store compliance as part of ongoing mobile app maintenance rather than a release day task. Requirements arrive with months of notice on a page anyone can read, and they only become emergencies for teams that aren’t reading it. Checking Apple’s upcoming requirements page once a quarter costs almost nothing and removes an entire class of blocked release. If you’ve inherited an app and have no idea which of these it’s currently failing, an app maintenance audit answers that question before you commit to a release date.

Should you fix and resubmit, or appeal the rejection?

Fix and resubmit for almost everything, and appeal only when a guideline was applied to something your app doesn’t actually do. Apple gives you three separate paths after a rejection, and picking the wrong one costs days. You can reply to App Review in the Resolution Center inside App Store Connect, you can appeal to the App Review Board if you believe a guideline was misapplied, or you can suggest a change to the guidelines themselves.

The Resolution Center is the right default, and it’s more useful than most teams realise. Replying there doesn’t require you to resubmit anything, and your rejected build stays where it is while the conversation happens. That means you can send a screen recording of the flow the reviewer couldn’t find, supply working demo credentials, or explain why a permission is necessary, all without burning a new submission. A surprising share of rejections resolve as a misunderstanding about how to reach a feature, and those resolve in a message rather than a code change.

An appeal to the App Review Board is a different instrument for a narrower problem. Use it when the reviewer’s factual reading of your app is wrong, such as a 4.3 Spam rejection on an app that isn’t a template, or a 4.2 Minimum Functionality rejection on an app that does substantially more than the reviewer found. Apple doesn’t publish a turnaround for appeals, so nobody can promise you a date, and that alone makes it the slower path when a fix is available. Don’t appeal because you dislike a rule that was correctly applied, since that’s what the guideline suggestion path exists for and the board won’t overturn a correct call.

One thing not to do, on either platform, is submit a fresh build hoping it moves faster than the conversation you’re already in. It doesn’t jump the queue, it gives you two threads to track, and it can read as evasion when the original point is still unaddressed. We covered the queue mechanics behind that in more detail in our piece on App Store review time.

How do Google Play rejections differ from Apple’s?

Google rejects less on craft and more on policy declarations and account standing, which changes what you prepare for. Play’s most common blockers are declaration mismatches rather than reviewer judgments: a Data safety section that doesn’t match what your app transmits, a sensitive permission like SMS or call log access without an approved use case, or a target API level below the current minimum. Those are all form and manifest problems, checkable before you upload.

The requirement that catches new Android publishers has nothing to do with your code at all. Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers who have been opted in continuously for the last 14 days before they can apply for production access. Organisation accounts and older personal accounts are exempt. Teams hit this after the app is finished, discover they need two weeks of real tester activity before they can publish anything, and lose a launch window to a rule they could have started satisfying a month earlier.

The other difference is durability, since an Apple rejection is usually about one submission while a Play policy strike attaches to the account and shapes how everything you ship afterwards is treated. That asymmetry is worth planning around when you’re launching on both platforms at once, because the Android side rewards caution about policy far more than the iOS side does.

Where to spend your effort before the next submission

The highest return work happens before you press submit, and it’s mostly clerical. Confirm the demo account works today rather than assuming it still works, read your screenshots against the current build, check your App Privacy answers against what the app actually collects, and open Apple’s upcoming requirements page to see whether a date has passed since your last release. That sequence catches the large majority of what sends a submission back, and none of it requires touching code.

When a rejection does arrive, read the whole note before changing anything, fix every point it raises in a single build, and use the Resolution Center to ask rather than guessing at what the reviewer meant. The teams that lose weeks to review aren’t the ones with bad apps, they’re the ones doing partial fixes across three rounds because they never asked a clarifying question.

For an app you inherited or haven’t shipped in a year, the honest answer is that you probably can’t predict which requirement it fails until someone checks. That’s the situation where a rejection turns into a multi week surprise rather than an afternoon, and it’s the specific problem app takeover work at RapidLabs exists to solve. The cost of finding out early is small, and it’s a great deal smaller than the cost of finding out on the day you planned to launch.