Why your app got rejected — and how to clear it

App Completeness

The reviewer could not get through your app. Either they could not sign in, something crashed, or they found content that was not finished. It is the most common rejection there is, and almost always the cheapest to fix.

Accurate Metadata

Your listing promises something the app does not show. Apple treats the product page as part of the product: screenshots must be real screens, the description must describe what ships today, and nothing may point at Android.

Spam and Duplicate Apps

Apple believes your app is one of many near-identical apps, or too close to something you or someone else already publishes. This is one of the hardest rejections to clear because it is a judgement about your concept, not a bug.

Minimum Functionality

The app does too little, or it is a website in a shell. Apple expects native value: something a browser tab cannot do as well.

Data Collection and Storage

Something about how you collect data does not meet Apple's rules: you asked too early, you asked without explaining, or you made leaving harder than joining.

App Tracking Transparency

Your app tracks users across apps or websites and either does not ask, asks in a way the reviewer could not find, or asks while the privacy labels say you do not track.

In-App Purchase

Digital content used inside your app has to be bought through in-app purchase. A link out to your own checkout for the same thing is what triggers this.

Private APIs and Software Requirements

Static analysis found a symbol that belongs to a private framework. Usually it is not your code at all — it is an SDK you embed.

User-Generated Content

If users can post, message or upload, Apple requires a specific set of safety controls — and it checks that they exist, not that you intend to add them.

Intellectual Property

Your app uses a name, logo, artwork or data that belongs to someone else, and Apple has no evidence you are allowed to.

Broken or unstable functionality

The reviewer or the automated pre-launch test could not use the app. Google runs your build on real devices before a human ever sees it, so this often comes from the pre-launch report.

Deceptive Behavior

Your store listing, icon or in-app content promises something the app does not deliver, or imitates something it is not.

Permissions and sensitive APIs

You are requesting a permission Google treats as high risk, and either the declaration is missing or the justification does not hold up.

Data safety form mismatch

Google compared your declaration against what the app actually transmits, and they disagree. SDKs are the usual reason — analytics and ad libraries collect more than developers expect.

Missing or invalid privacy policy

Google could not find a working privacy policy, or the one you linked does not describe what your app actually does with data.

Target API level requirement

This is a technical gate rather than a policy judgement: Play requires new apps and updates to target a recent Android API level, and raises the bar every year.

Restricted content and impersonation

Either the content itself is not allowed in the form you shipped it, or the app appears to be from someone else.