The most common App Store and Google Play rejection reasons, explained
Review teams see the same themes again and again. A small number of guidelines account for a large share of rejections, and most of them concern a handful of recurring ideas: the app should work, be honest, protect people's data, add something to the store and handle payments correctly. This guide lists the common ones and explains in a sentence or two what each is really about.
Each item links to a fuller explanation of the guideline. None of the explanations tells you how to resolve a particular rejection; they describe what the rule means.
The app is not ready or does not work
The most frequent finding on Apple is under the completeness guideline, 2.1. It covers crashes, unfinished features, placeholder content and situations where the reviewer cannot reach the main features, for example because a login does not work. On Google Play the corresponding expectations sit in the functionality and quality policies.
The app looks like something that already exists
Apple's guideline 4.3 and Google's Spam policy address apps that duplicate other apps, including a developer's own. Template-built apps are the typical example. The question reviewers ask is whether the app adds something distinct to the store.
Privacy and data handling
Privacy findings include missing account deletion, privacy policies that do not match behaviour, missing purpose strings for permissions, and inaccurate privacy labels or Data Safety declarations. Many are caused by the behaviour of third-party libraries inside the app.
Payments and subscriptions
The in-app purchase requirement, rules about links to outside payment, and the way subscriptions are presented produce a steady stream of rejections on both stores. They are often about the presentation of price or about where a purchase takes place.
The listing does not match the app
Screenshots that show features not present, descriptions that overstate what an app does, borrowed brand names in keywords and inaccurate age ratings are routine metadata findings. They are generally about the accuracy of what is shown in the store.
Content and user safety
Apps that let users post content meet requirements for reporting, blocking and moderation. Generative features meet content-safety expectations because a reviewer can test the output directly.
Why the same few reasons repeat
The most common rejection reasons are common because they sit where many apps are weakest: completeness, honesty in the listing, privacy handling and payments. They also reflect how review is organised. Issues that a reviewer can observe quickly, such as a crash or a missing login, come up more often than subtle policy questions.
Reading the list sensibly
A list of frequent reasons is a map of where to look for explanations, not a prediction of what will happen to a given app. Many successful apps never receive any of these findings, and some rejections fall outside the list entirely. The topic overview pages on this site group the underlying guidelines by theme.
Common questions
Completeness and functionality findings, such as crashes or inaccessible features, are among the most frequently reported on Apple.
There is a lot of overlap, but the wording and structure differ.
New accounts and first apps often receive closer scrutiny, though many are approved without incident.
Review processes change often. This guide is a plain-language explanation written by AppReviewFix, not official guidance. Check Apple's App Store Review Guidelines and Google's Developer Program Policies for current details.