App rejected by the App Store or Google Play — what to do, step by step

You submit an update the day before a campaign, and in the morning a message lands in your inbox: "We noticed an issue with your app" or "Your app doesn't comply with Google Play policies". The release is blocked, marketing is asking about the date, and the rejection contains a guideline number and two vague sentences.

The good news: a rejection is a normal stage of the release process, not a punishment. The vast majority of rejected apps are back in the store within a day or two, as long as you respond specifically and avoid a few typical mistakes. This article walks through what to do, step by step: how to read the reason, how to reply to the reviewer, when to appeal and how not to end up here again with the next release.

First, figure out what actually happened

Three situations look similar in an e-mail but differ in how serious they are:

• Update rejection. The new version didn't pass review. The previous version still works in the store, users don't lose access. This is by far the most common case and the least dangerous.
• App removal / suspension. The app is no longer available for download. People who already have it can usually keep using it, but there are no new downloads.
• Developer account suspension. The most serious scenario, usually after a series of violations or on suspicion of fraud. It affects every app on the account.

Check this before you start fixing anything. In App Store Connect, the submission status and the reviewer's message are in the Resolution Center. In Google Play Console, the reason and scope of the enforcement action are shown in the app's Policy status section — that's where the full decision lives, not in the e-mail.

A separate issue that's easy to mistake for a penalty: the app stops being visible to some users because it doesn't meet the required targetSdk level. Nobody rejected it — a deadline passed. We covered this case separately in our article on why an app disappears from Google Play after the target API deadline.

Read the decision literally and find the guideline number

The biggest mistake at this stage is guessing. The reviewer almost always gives a guideline number — for Apple, for example 2.1, 4.2 or 5.1.1; for Google, the name of a specific policy, such as "Permissions and APIs that Access Sensitive Information".

Do three things:

1. Open that specific guideline in the App Store Review Guidelines or the Google Play Policy Center and read it in full. Numbering and policy names change over time, so always check the source, not an article from two years ago.
2. Write down exactly what the objection refers to — a specific screen, permission, store listing text or screenshot. A rejection almost never concerns "the whole app".
3. Check whether it's a code problem or a metadata problem. This distinction decides how long the fix will take. Changing the description, screenshots, data form or privacy policy doesn't require a new app version and can often be done within an hour.

The most common reasons for App Store rejection

Apple reviews manually and in detail. A few categories come up again and again:

• The app doesn't work for the reviewer. A crash on launch, a login screen without a working test account, a feature that can't be reached. This is the most common reason for rejection and usually the easiest to fix: a demo account, an exact path in the review notes, a screen recording.
• Too little functionality, or the app is a wrapped website. If the app is mostly a browser view with the same content as the website, Apple expects real native value: notifications, offline mode, system integration.
• Privacy and user accounts. Collecting data without explicit consent, no privacy policy, forcing sign-up where it isn't needed. A separate, often overlooked point: an app that lets users create an account must also let them delete it from within the app.
• Payments outside the store's mechanism. Selling digital content while bypassing in-app purchases, or sending users to pay in a browser. We mapped out where the line between allowed and not allowed runs in our article on BLIK and App Store and Google Play guidelines.
• Metadata that doesn't match the app. Screenshots showing features that don't exist, third-party brands in the description, the wrong age rating, placeholder text.
• Tracking without consent. Using the advertising identifier or marketing SDKs without a tracking consent prompt.

The most common reasons for Google Play rejection

Google largely reviews automatically, so decisions tend to be terser, and the most common problems concern declarations rather than code:

• Sensitive permissions without justification. Background location, access to SMS and call log, all-files access, the list of installed apps. Each of these requires a declaration and a real, user-visible feature. If a permission is left in the project from a library you no longer use — remove it, that's the fastest route.
• A Data safety form that doesn't match reality. The app sends data you didn't declare — most often through an analytics or ads SDK added alongside some other change. The form has to be updated with every change to your set of libraries.
• A missing or unavailable privacy policy. The link has to work, lead to a public page and describe this specific app.
• The app doesn't work properly. Crashes, empty screens, features unavailable without logging in, no test data.
• Content and metadata. Promises in the description not backed by features, keywords stuffed into the title, a category that doesn't match the content, an incorrect declaration for apps aimed at children.
• Technical requirements. The targetSdk level, required declarations for financial, health or AI apps — the set of policies grows every year.

What to do in the first hour

1. Don't resubmit the same version. Resubmitting without changes or an explanation usually ends in the same rejection, and with Google it adds to the violation count on your account.
2. Save the whole decision. The message text, guideline number, date, version number. In a longer exchange with the reviewer, this history is invaluable.
3. Reproduce the problem yourself. On the same device model and OS version as the reviewer, if they gave them, and on the same build you submitted — not on a development version.
4. Check whether the fix needs a new version. Metadata, the data form, the privacy policy and permission declarations can be changed without releasing the app.
5. Prepare evidence. A working, non-expiring test account, a short screen recording showing the feature in question, review notes in English.

How to write a reply to the reviewer

A reply that works is short, factual and addresses the objection point by point. The reviewer doesn't know your product and doesn't have time to learn it.

A few rules that genuinely shorten the back-and-forth:

• Write in English, specifically and without emotion. "We disagree" without evidence adds more rounds to the process.
• Refer to the guideline number and say plainly what you changed or why you believe the requirement is met.
• Give an exact path. "Log in with the demo account, home screen → Orders → New order button" is worth more than a paragraph of explanation.
• Attach a recording. For objections like "we were unable to access the feature", a video settles the matter fastest.
• If it's a legal requirement, say so directly and point to the regulation — for example, identity verification in a financial app.
• Don't change ten other things along the way. The smaller the difference between versions, the shorter the review and the easier it is to tell what worked.

When to appeal

If, after reading the guideline, you still believe the decision is wrong, both platforms offer an appeal path.

Apple. Start with a clarification in the Resolution Center — some rejections are simply the result of a misunderstanding and end there. If that doesn't help, you can ask for the decision to be reconsidered by the App Review Board or, if your case doesn't fit the guideline, submit a request for an exception.

Google. You submit an appeal through a form in Play Console, next to the specific violation in the Policy status section. In the appeal, describe exactly what the app does, why it needs the permission and what you've already fixed. With automated decisions, this is often the only way to get a human to look at the case.

An appeal makes sense when you have a substantive argument. If the objection is valid, it's faster to fix it and ship a new version than to argue for a week.

How long it takes

Apple says it reviews most submissions within one to two days, and after a fix the submission goes back to the end of the queue. Google can approve an update in a few hours, but for new accounts, sensitive permissions and after a violation, review takes longer — sometimes more than a week. Appeals are slower than a regular review.

The practical takeaway for release planning: don't ship a business-critical update the day before the deadline. A buffer of two or three working days costs nothing and saves you from a campaign launching without the app. For apps with regular releases, it's also worth building a release process in which submitting to the store is routine rather than a one-off event.

When the app was removed, not rejected

The approach is different here, because the clock is ticking in lost downloads:

1. Check the scope. In Play Console you'll see whether it's a removal from the listing, a restriction in selected countries or a suspension. For Apple, you'll find the information in the message and the app's status.
2. Establish whether the problem concerns one version or the account. An account-level violation means cleaning up every app, not just this one.
3. Fix it and resubmit with an explanation. With a removal, the fix alone isn't enough — you have to go through an appeal or a resubmission with a description of the changes.
4. Take care of communication. Users who can't download the app leave ratings. A short notice on your website and social media limits the damage.

If along the way it turns out you don't have access to the store account, the signing keys or the current code, the problem is bigger than a rejection — it's a matter of regaining control over the project.

How to reduce the risk with the next release

Rejections can't be eliminated, but they can be made rare:

• A permanent test account that doesn't expire, doesn't require an SMS code to a Polish phone number and has demo data.
• Review notes describing how to reach features that need context — code scanning, payments, device integration.
• A permissions review before every release. After every library change, check what actually ended up in the app manifest.
• Updating the data form with every SDK change, not once a year.
• Testing on the latest OS version — including the beta, before it reaches users.
• Staged rollout, so that a bug doesn't reach everyone at once.
• An internal checklist based on your previous rejections. They repeat surprisingly often.

Summary

An app rejection is irritating, but in most cases it's a matter of one day's work: read the guideline, establish whether the problem is in the code or in the declarations, fix one thing and reply specifically. It only becomes a real problem when nobody in the company understands the decision, there's no one to prepare a new release, or the store access is held by someone you can't reach.

We handle rejections, App Store and Google Play releases and the yearly store requirement bumps as part of mobile app maintenance — with a number of hours tailored to the project, which we write more about in our article on mobile app maintenance cost. If the app hasn't had a release in a long time and nobody knows whether it still builds, start with reactivation or simply get in touch.