My app was rejected on Google Play. What happens next?

If a live version exists, it stays live. Google's own words: "If an update to an existing app is rejected, the version published prior to the update will still be available on Google Play." Your users are not affected, your installs continue, and nothing has been taken down.

What has happened is that the update stopped. In Play Console the update status reads Update rejected, or App rejected if this was a first publish, and the app status may drop back to Draft or No active releases.

The reason will be in an email to the account owner and in Play Console Notifications. It usually reads as a policy notice rather than a review message, and that difference in tone is why so many developers go looking for a rejection screen that does not exist.

Where the rejection actually appears

There is no message thread on Play. No Resolution Center, no reviewer to reply to. The information is spread across three places and you need all three.

Email to the account owner. The primary channel, and it names the policy. If your Play account owner is a shared inbox nobody reads, this is the moment that becomes expensive. Google's instruction on resubmitting: "Check your Notifications and email for information about the policy your app violated."

Play Console Notifications. The bell icon. The same message, and it survives longer than an email somebody deleted.

The Publishing overview page. What was submitted, what was rejected, and what is still sitting unsent. Watch for "Changes not yet sent for review", which Google pairs with the warning that "Your changes are not automatically sent for review."

That last one accounts for a good share of "Google never responded" reports. Nothing was rejected, because nothing was sent.

The statuses, in Google's words

Worth reading these exactly, because two of them look identical and are not:

Update rejected: "One or more of the changes in your update are not compliant with the Google Play policy or the Developer Distribution Agreement. You can fix the issue and resubmit, or you can submit an appeal."

App rejected: the same sentence, plus "Note: The difference between this state and Update rejected is that App rejected only applies to apps in Draft that you're attempting to publish for the first time."

Draft: "Your app has no presence on Google Play because either you haven't published it yet or it was rejected during the review process."

No active releases: "This means that either you did not roll out updates on any tracks or the updates were rejected."

Both of the last two describe a rejection using language that sounds like inaction. If your app has gone quiet and the status is Draft, that is not a console glitch.

What a rejection costs you

Less than you fear, as long as it stays a rejection. Google's enforcement page lists the consequence in one line: rejections "Don't impact the standing of your Google Play Developer account."

That is the key distinction on Play, because the neighbouring outcomes are much worse:

• A removal takes your published version down until you submit a compliant update. Your "users, statistics, and ratings will be retained".
• A suspension takes the app down, counts as a strike, and you "forfeit the users, statistics, and ratings of the removed application".
• A warning does not affect standing, but "your app will be removed after the number of days found in the initial warning email".

Read the word in your email before deciding how worried to be. Rejected is the cheap one.

The sequence, in the order you would really do it

1. Find the named policy. The enforcement email cites a specific policy, not a vague category. Open the policy page it links to and read the whole thing, including the examples. Google's advice: "Read through the relevant policy noted in the enforcement message for more details."

2. Check whether anything else is non-compliant. Google adds a note most people skip: "Additional enforcement could occur if there are further policy violations." Fixing one thing and shipping straight into a second violation is how a rejection becomes a pattern.

3. Fix it, then fix it everywhere. This is the step that catches people. Google is direct: "Make the appropriate changes to your app and update all release types in addition to your production release (for example, the open, closed, and internal test track releases)."

4. Deactivate the non-compliant bundles. Upload the fixed bundle across all tracks and deactivate the old ones. The warning is worth quoting in full: "If you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play." A resubmission that leaves the offending bundle live on your internal test track can cost you the live app.

5. Create the new release. Manage track, Create new release, confirm the non-compliant version sits under "Not included", save, Review release, roll out. Repeat on every track that carried the bad bundle.

6. Submit, and check that you actually submitted. Back to Publishing overview. If changes are sitting in "Changes not yet sent for review", send them.

7. Only then consider an appeal, if you believe the rejection is wrong rather than fixable.

The one thing not to do

Republish without fixing. Google says it twice on the same page, in a note under both rejections and removals: "Until a policy violation has been fixed, don't republish a rejected app."

A resubmission that changes nothing is not neutral. Repeated rejections feed the escalation path: "Egregious or multiple policy violations can result in suspension, as can repeated app rejections or removals."

The appeal route

Play appeals are one shot per action. Google's wording:

"You may submit one appeal per app removal, suspension, or other enforcement action. We will reinstate apps in appropriate circumstances, including if an error was made and we find that your app does not violate the Google Play Developer Program Policies and Developer Distribution Agreement."

Two practical notes from the same page. Language: "we can only respond to appeals in Chinese, English, Japanese, and Korean at this time." And conduct: "If you misuse our appeals process, including sending abusive or inappropriate communications to our support teams, you may become ineligible for further email support."

Appeal when you can show the policy does not apply. Fix and resubmit when it does. Doing both at once is not available the way it is on the App Store, because you get one appeal.

Why Play rejections feel different from Apple's

On the App Store you are in a conversation with a reviewer who cited a guideline and often attached a screenshot. On Play you get a policy determination with no thread attached, so the fix has to be complete and self-evident on the next submission. Enforcement is also scored at the account level, so three small rejections across three apps is one pattern on one account.

FAQ

Will my live app come down because an update was rejected? No. Google states the previously published version stays available. Only a removal or a suspension takes the live app down.

How do I find out why it was rejected? Email to the account owner, plus Notifications in Play Console. There is no reviewer message thread, and the reason names a policy rather than describing what the reviewer saw.

How long until I can resubmit? There is no cooling-off period. Google's only condition is that the violation is actually fixed first.

Do I need a new version code? Yes, a new bundle needs a higher version code. Also deactivate the old bundle on every track that carried it, or the resubmission fails.

Does a rejection hurt my account? Not on its own. Repeated rejections do, because they feed the path towards suspension.

Can I talk to a human? There is a Help page inside Play Console that can raise a request, plus the appeal form. Neither reaches the reviewer who decided.

AppSubmit keeps the enforcement email, the named policy and the bundle you shipped against the release they belong to, which matters most on Play because the console gives you a status rather than a thread. Play Console Notifications hold the same record if the account owner's inbox is somewhere you can actually read.