App Store or Google Play rejection: how to understand it and get approved

A rejection email from Apple or Google is frustrating, especially when a launch date is close. The good news is that most rejections are about something specific and fixable, and the message usually tells you where to look. The bad news is that the wording can be vague, and a rushed resubmission that misses the real cause often leads to another rejection. This page explains the common reasons at a high level, how to respond, and when to bring in a developer.

Store rules change regularly and differ between Apple and Google, and sometimes between countries. Treat this page as an orientation, and always read the current official guidelines for the specific point you were rejected on.

Start by reading the message properly

Before changing anything:

1. Copy the full rejection text into a document, including the guideline section named and any screenshots the reviewer attached.
2. Note the device and OS version the reviewer used, if given. A crash that only happens on a tablet or an older OS points somewhere different from one that happens everywhere.
3. Separate what they asked from what you assume. If the message mentions only your privacy details, do not rebuild the login screen.
4. Check whether it is the app or the listing. Some rejections are about the binary; others are about screenshots, descriptions or forms in App Store Connect or Play Console.

Common rejection reasons

Crashes and bugs

Reviewers test on real devices. If the app crashes at launch, freezes on a screen, or shows an error on a clean install, it will be rejected. Common causes include a missing permission description, a backend that was unreachable during review, a feature that only works with data on your own test account, or a build made in a debug configuration.

Incomplete information or a broken demo login

If parts of the app need an account, reviewers need working demo credentials, entered in the review information section of the submission, not in public text. Placeholder screens, "coming soon" buttons, test content and dead links also count as incomplete. If something needs special hardware or a location, explain how to review it in the notes.

Metadata problems

The name, description, keywords, screenshots and preview videos must match what the app actually does. Screenshots showing features that do not exist, mentions of other platforms, or misleading claims are typical reasons for listing rejections.

Privacy details and data safety forms

Both stores ask you to declare what data the app collects and why: Apple through the App Privacy section in App Store Connect, and Google through the Data safety form in Play Console. These declarations must match what the app and every SDK inside it actually do, including analytics, crash reporting and advertising libraries. You also need a reachable privacy policy. Apple additionally expects certain SDKs and APIs to be covered by a privacy manifest in the app bundle.

Account deletion

If users can create an account inside your app, both Apple and Google expect them to be able to start deleting that account too. On iOS this must be possible from within the app, not only by emailing support. Google Play also asks for a web link where users can request deletion without reinstalling the app.

Login options on iOS

When an iOS app offers sign-in through a third-party or social login, Apple generally requires an additional login option with specific privacy features, and Sign in with Apple is the common way to meet it. Adding it involves both app code and backend changes, so it is rarely a five-minute job.

Payments

Digital content and features unlocked inside the app, such as subscriptions, premium tiers or in-game currency, generally have to use the store's own in-app purchase system. Physical goods and services used outside the app, such as deliveries or bookings, can usually use other payment providers. The rules for linking to outside payment options vary by country and have changed in recent years, so check the current position for the markets you sell in.

Google Play account and testing requirements

Google Play has its own hurdles. Newer personal developer accounts must run a closed test with a set number of testers for a set period before applying for production access, and apps must target a recent Android API level. Rejections or warnings for these show up in Play Console rather than as a review message.

How to respond in Resolution Center

On Apple's side, rejections appear in App Store Connect, and you can reply in the Resolution Center thread for that submission.

• Keep it short and factual. Say what you changed and where the reviewer can see it.
• If you think the reviewer misunderstood something, explain how the feature works and attach a screen recording.
• Ask a specific question if the message is unclear; reviewers do answer.
• If a reply does not resolve it, an appeal to the App Review Board is possible.

For Google Play, check the email and the policy status page in Play Console, fix the issue, and submit an update. Google offers an appeal form for decisions you disagree with.

What a rescue developer will typically check first

A mobile developer taking over a rejected app will usually:

1. Read the rejection and the store's current guideline text side by side.
2. Install the exact build that was reviewed on a clean device or simulator matching the reviewer's setup.
3. Check crash reports and backend logs from the review period.
4. Audit the SDKs in the app against the privacy declarations.
5. Confirm the build configuration, signing, version numbers and target API level.
6. Draft a clear reply for you to send, or send it if they have the right role on your account.

You can add a developer to your Apple Developer team and Play Console with a role that suits the job, rather than handing over your login. The guide on giving a developer access without sharing passwords explains the general approach, and the production readiness checklist helps you catch other gaps before the next submission.

Post the app as a takeover

If you need someone to fix the rejection and get the app through review, post it on TakeoverWork. Posting is free. Paste the rejection text with any personal details removed, name the framework (Flutter, React Native, FlutterFlow, Swift or Kotlin), and say whether you still have the source code and store access. If the previous developer holds the code or signing keys, read what to do when a developer disappears with the code first. The guide on writing a takeover listing that gets responses has more tips.

TakeoverWork connects app owners with developers and agencies who finish started projects. It does not check or employ them, makes no promise about review outcomes, and never handles payments, so agree scope and price directly with the person you choose.