Rejection guides
Why your app got rejected — and how to clear it
Rejection notices are written in guideline numbers and boilerplate. These pages translate each one into what actually went wrong, the fixes reviewers accept, and a reply you can send today.
Apple App Store 26
Review Guidelines
- 1.1
Objectionable Content
Apple rejected your app under Guideline 1.1. What counts as objectionable, why user-generated content triggers it, and the moderation features review expects.
- 1.2
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.
- 2.1
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.
- 2.2
Beta, demo and trial versions
Apple rejected your app under Guideline 2.2 for beta or demo language. Every place the word hides, what free trial wording is still allowed, and how to reply.
- 2.3
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.
- 2.3.1
Hidden or undocumented features
Apple rejected your app under Guideline 2.3.1 for hidden or undocumented features. What reviewers find, why remote config triggers it, and how to fix it.
- 2.3.10
Mentions of other platforms
Apple rejected your app under Guideline 2.3.10 for naming another platform. Where Android and Google Play mentions hide, and exactly what to remove.
- 2.5.1
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.
- 2.5.2
Downloading executable code
Apple rejected your app under Guideline 2.5.2. What counts as executable code, why JavaScript bundles are treated differently, and where the line actually sits.
- 2.5.4
Background modes
Apple rejected your app under Guideline 2.5.4 for a background mode with no real use. Which entitlements trigger it, how to remove them, and when to defend one.
- 3.1.1
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.
- 3.1.2
Subscriptions
Apple rejected your subscription under Guideline 3.1.2. The exact disclosures your paywall needs, where the Terms and Privacy links go, and how to fix restore.
- 3.1.3
Other Purchase Methods
Apple rejected your app under Guideline 3.1.3. What the reader app, multiplatform and person-to-person exceptions really permit, and how to reply.
- 4.0
Design
Apple rejected your app under Guideline 4.0 and named nothing. How to make the reviewer specific, what actually triggers it, and the fixes in order.
- 4.1
Copycats
Apple rejected your app under Guideline 4.1 for resembling another app. What Apple is comparing, how to change your identity, and how to reply if it is wrong.
- 4.2
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.
- 4.3
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.
- 4.3(a)
Design Spam
Apple rejected your app under Guideline 4.3(a) as spam, a reskin, a template build, or too close to an existing app. What Apple compares, and what actually clears it.
- 4.8
Login Services
Apple rejected your app under Guideline 4.8 over third-party login. When Sign in with Apple is required, what counts as an equivalent option, and what exempts you.
- 5.1.1
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.
- 5.1.1(v)
Account Deletion
Apple rejected your app under Guideline 5.1.1(v) because there is no way to delete an account inside the app. What counts as deletion, and the traps that fail review.
- 5.1.2
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.
- 5.1.5
Location Services
Apple rejected your app under Guideline 5.1.5. How to write a purpose string that passes, when Always is justified, and why to ask for When In Use first.
- 5.2
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.
- 5.3
Gaming, Gambling and Lotteries
Apple rejected your app under Guideline 5.3. What contests, real-money gaming and loot boxes each require, licences, geo-restriction, odds disclosure.
- 5.6
Developer Code of Conduct
Apple cited Guideline 5.6 against your app or account. What counts as review manipulation, why this one is account level, and how to answer it properly.
Google Play 20
Developer Program Policy
- Account Deletion
Google Play account deletion requirement: the in-app path, the web URL, and the data-only option
Play rejected your app over account deletion. You need an in-app path and a public web URL. What each must do, and where the URL goes in Data safety.
- Ads
Google Play disruptive ads rejection: interstitials, unexpected ads and ads outside the app
Play removed or rejected your app under the Ads policy. What counts as a disruptive, deceptive or unexpected ad, and the placements that clear the policy.
- Broken Functionality
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.
- Closed Testing
Google Play closed testing: it is 12 testers, not 20, and they must stay opted in for 14 days
New personal Play accounts need closed testing before production access. The real number is 12 testers opted in continuously for 14 days, not 20.
- Data Safety
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.
- Deceptive Behavior
Deceptive Behavior
Your store listing, icon or in-app content promises something the app does not deliver, or imitates something it is not.
- Enforcement
Rejected, removed, suspended or terminated: what each Google Play enforcement actually costs you
Play enforcement comes in four sizes with very different consequences. Which one you got, what you keep, what counts against your account, and how to appeal.
- Families
Google Play Families policy rejection: target audience, ads and child-appealing content
Play flagged your app under the Families or target audience policy. What the questionnaire commits you to, why child-appealing listings get caught, and the fixes that clear it.
- Financial Services
Google Play Financial services rejection: loans, crypto and trading apps
Play rejected your app under the Financial services policy. The declarations it expects, the personal-loan rules, crypto and trading restrictions, and how to clear each one.
- Health Content
Google Play health app rejection: medical claims, misinformation and required disclosures
Play rejected your health app for unsupported medical claims, missing disclosures or an incomplete health declaration. What the policy asks for and how to satisfy it.
- Impersonation
Google Play Impersonation policy rejection: app names, icons and developer names that look like someone else's
Play cited the Impersonation policy. What counts as misleading similarity in a title, icon or developer name, and how to change the listing so it clears.
- Permissions and APIs
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.
- Photo and Video Permissions
READ_MEDIA_IMAGES rejected: Google Play's Photo and Video Permissions policy and the declaration form
Play flagged READ_MEDIA_IMAGES or READ_MEDIA_VIDEO. When broad photo access is allowed, how the declaration works, and how to switch to the photo picker.
- Ratings and Reviews
Google Play ratings and reviews manipulation: incentivised installs, fake reviews and rating prompts done wrong
Play cited the Ratings, Reviews, and Installs policy. What counts as manipulation, why review prompts get flagged, and how to fix the app and the listing.
- Restricted Content
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.
- Subscriptions
Google Play Subscriptions policy rejection: trial terms, price disclosure and the cancellation path
Play rejected your app under the Subscriptions policy. Exactly what must be on the paywall before purchase, and how to disclose trials, renewals and cancellation.
- Target API level
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.
- Target API level 36
Google Play target API level 36: the 31 August 2026 deadline, the extension to 1 November, and how to upgrade
Play now requires target API level 36 for new apps and updates from 31 August 2026, with an extension to 1 November. What breaks and how to upgrade.
- Tester Engagement
"Your testers were not engaged with your app": what Google Play actually publishes about tester engagement
Play denied production access for insufficient tester engagement. There is no published metric or threshold. Here is what is documented, and what is guesswork.
- User Data
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.
Or paste the rejection and let AppSubmit read it
The decoder takes the exact message Apple or Google sent, tells you in plain English what triggered it, writes the fix plan for your app specifically, and drafts the reply to App Review. It knows your listing, your build and your history, so the plan is not generic advice.
Join the waitlist