App store rating dropped? Diagnose it, then reply (2026 guide)

If your app store rating dropped, find the cause before you reply. Line the drop up against your release dates and read that week's reviews. The five common causes are a release bug, an outage, a price change, review bombing and months of unanswered reviews. Each needs a different fix.

Key takeaways

Replying more is not the same as recovering. In our 2026 study of 100 top Google Play apps on US charts, 42% of replies were word for word repeats, and about 1 in 4 graded replies to low-star reviews missed what the reviewer raised, by an AI grade that a person disagreed with on 1 reply in 10. A perfect reply rate built on templates reads as no answer at all.

The cause of the drop decides the fix. A release regression needs an engineering fix and a specific reply. Review bombing needs evidence and a report to the store. Pricing backlash needs time and communication. Confusing these wastes the days when your response has the most effect.

Apple gives you a rating reset. Google gives you recency weighting. Neither is a shortcut around fixing the underlying problem, and using either one without doing that first usually makes the story worse, not better.

Recovery is measured by reply effect on the reviews that could still move, not by the arithmetic of star averages. Track whether ratings actually shift after a reply, separately from whether the reply was good, and you get a diagnosis instead of a feeling.

Why your rating dropped: five causes, and how to tell them apart

Before you write a single reply, find out what actually happened. The cause decides the fix. Get it wrong and you send the team down the wrong path, while the reviews that matter most sit there unanswered. That's the single most expensive mistake in a recovery.

Release regression. A bug, a performance hit, or a broken feature shipped in a specific version. Reviews cluster around the same complaint, often naming the same screen or action, and the cluster starts on a specific day that lines up with a release.

Outage. Looks similar to a regression at first glance, but it hits every version at once rather than one, and it stops the moment the service is back, not the moment you ship a fix.

Pricing or paywall change. Complaints shift from bugs to money and fairness. These reviews run angrier and change more slowly, because the grievance is about a decision, not a defect.

Review bombing. A burst of near-identical, short reviews, often from accounts with little or no usage history, tied to something outside the app itself: a public controversy, a monetization decision, a community grievance. Games see this most, but any app that makes a visible, unpopular decision can get hit.

Accumulated neglect. No single event. Months of unanswered reviews and unfixed complaints add up until the average reflects a pattern instead of an incident. This is the hardest to recover from, because there's no one fix, only a sustained change in operating discipline. Our app store review management guide covers that routine: monitoring new reviews, analyzing recurring complaints and replying.

Treating a review bomb like a product failure wastes engineering time on something engineering can't fix. Treating accumulated neglect like a one-time crisis gets you a short burst of effort that fades before the pattern actually changes.

Diagnose it before you touch a reply

Check a ninety day average and a three day spike almost disappears. That's exactly why a live incident looks calm on a dashboard you only check once a week. Diagnosis means narrowing the window you look at, not widening it.

Start by lining up the drop against your release timeline. Does it start on a specific version? That's a regression. Pull every review from that version and read what they describe. Does it hit every version at once, at the same time as a service incident in your logs? That's an outage, not a product bug, and no code change will move the reviews. Has the language shifted from bugs and crashes to price and fairness? That's a pricing reaction. Are the reviews short, similar in wording, and coming in a burst from accounts with no history? That's a bombing, not organic feedback.

This is where alerting earns its place. Nobody can watch a dashboard closely enough to catch a three-hour spike before it becomes a three-day one. AppReply's alerts check for rating changes and review spikes as they happen, then send an assessment with the reviews behind it. The diagnosis above takes minutes instead of a manual pull through the console, and the alert tells you which cause you're looking at before you write anything back.

Alert rules narrowed by rating, topic and language, so a spike routes to the right person instead of a shared inbox.

Replying is not the same as recovering

The instinct after a bad drop is to answer everything, fast. That instinct produces coverage, and coverage is not the same thing as an answer that does anything.

Our 2026 study looked at 100 top Google Play apps on US charts. Reply rate turned out to behave less like a dial than a switch: of 76 apps with real complaint volume, 24 answered none of their low-star reviews and 18 answered 90% or more. More than half sat at one end or the other. So a team either built a way to answer reviews, or it didn't. But building it and doing it well turned out to be two different things. Across every reply in the study, 42.3% repeated another reply from the same app, word for word. One travel app posted the same line 1,604 times in 23 days. A kids' game asked what it could change to earn more stars, in the same sentence, 313 times under low-star reviews.

Both of those apps had reply rates that would look excellent on a dashboard. Neither was actually answering anyone. And among the graded replies to one to three star reviews in those 100 top Google Play apps on US charts, about 1 in 4 missed what the reviewer raised, more often under one-star reviews. That is an AI grade that a person disagreed with on 1 reply in 10, so read the share that answered (73.8%) as an upper bound. A templated answer, or an answer to the wrong problem, gives a reviewer no more reason to reconsider their rating than no answer at all.

That's the whole difference between recovery and the appearance of activity. A rating recovers when a reviewer with a real complaint sees that it was heard, and ideally fixed. It doesn't recover because a reply count went up.

What to write, and where the full guide is

Once you know the cause and you're ready to reply, the writing follows the same rules as any other reply, just with higher stakes. Name the specific problem. Say what's true right now. Reference the version or date if there's a fix. Never paste the same sentence under three hundred different complaints.

We cover the full mechanics, worked examples by review type, and the exact steps in both consoles in how to reply to app store reviews. For real replies to negative reviews graded pass or fail, and what gets a reviewer to raise their rating, see how to respond to negative reviews. Once the fix ships, a well-timed in-app review prompt brings in fresh ratings from the users it now works for. During a rating drop, make one change to that approach: reply to the people who already complained about the thing you just fixed before you reply to anyone else. That's the reply with a real shot at getting someone to reconsider what they wrote.

Apple's reset, and Google's recency weighting

The two stores give developers different tools for the number itself, and neither is a substitute for the diagnosis above.

Apple lets you reset your star average when you submit a new version. The option appears during submission in App Store Connect. After the reset, your displayed average clears, then repopulates as new ratings for that version come in. Written reviews stay exactly where they were. Apple recommends using this sparingly, and for good reason: it only helps if the version you're resetting on actually fixed the root cause. Reset without fixing the real problem and you'll collect the same complaints again, this time with no old average to fall back on. It also won't touch review bombing, since the bomb will just continue against the new version.

Google Play has no reset option. Instead, in August 2019 Google switched from a lifetime average to one that weights recent reviews more heavily. Google hasn't published the exact formula, but the effect is real: an app that had a bad stretch years ago, and is now earning genuine positive reviews, sees its visible rating improve faster than it would under a pure lifetime average. This cuts both ways during a drop, too. A bombing or a regression can move the visible number faster on Google Play than the same event would on the App Store. But once a real recovery effort is working, it also shows up faster there.

Neither tool changes what actually happened. They just change how fast the number reflects it, once you've done the work.

Recovery timelines, treated as a shape, not a promise

Many rating-recovery guides, including earlier versions of this one, hand out a specific week count per scenario. Most of those numbers don't trace to anything, and treating them as guarantees sets a team up to quit right before the effort starts working. What actually holds up is the shape, not the number:

A regression with a fast, well-explained fix shows the earliest movement. The fix and the follow-up reply can both happen within days of diagnosis, and you're replying to the same people the bug actually affected.

Review bombing tends to settle in a similarly short window, once the store removes reviews that violate its policies and your own genuine reviewers dilute whatever noise is left. Store-side enforcement against fake reviews is real, not a formality. Apple's 2024 fraud prevention report put its enforcement at over 1.2 billion ratings and reviews processed, and more than 143 million fraudulent ones removed that year. That figure covers all fraud, not bombing specifically, but it's a reason to expect a report to actually get looked at.

Accumulated neglect is the slowest by a wide margin. There's no fix to ship, only a change in whether reviews get answered at all, week after week, until the average starts to reflect the new pattern instead of the old one.

Treat any specific week count you read, here or anywhere else, as a rough guess about the shape. Not a schedule you're behind on if you miss it.

Case study: Genshin Impact, September 2021

On September 20, 2021, miHoYo announced the rewards for Genshin Impact's one-year anniversary. Kotaku reported that most of them were locked behind raffles and contests, and that players answered by review bombing the game on Google Play. On September 28, GamesRadar reported the Google Play rating at between 1.9 and 2.0, down from 4.6 on September 16, with a large share of the newest reviews naming the anniversary rewards. Kotaku, a day later, put it at 2.8, down from 4.5. It spilled past Genshin itself, too: Kotaku confirmed complaints about the anniversary in the review sections of at least ten other games, most of them not made by miHoYo, and Inven Global reported that Google Classroom was targeted as well.

Two things were in play, and only one of them is well documented. GamesRadar noted that Google Play's review policy forbids fake, inaccurate and repeated reviews, wrote that many of the new reviews fit that description, and expected the rating to recover as flagged reviews came down. We found no statement from Google on what it removed, and no reliable figure for how far the rating recovered. Separately, the developer added to the rewards. On September 30, GamesRadar published a statement from miHoYo saying it had "already come up with more celebrations", and reported that players had just received one of four free bundles by in-game mail: 400 Primogems and a glider skin that had been tied to a paid bundle. That addressed the actual grievance instead of just the reviews about it.

The lesson isn't the specific number of stars lost. It's that a bombing has two separate answers: report the pattern to the platform, and separately, fix whatever the reviewers are actually angry about. Enforcement without fixing the grievance just leaves the anger looking for a new outlet. Fixing the grievance without reporting the pattern leaves policy-breaking reviews sitting on your page indefinitely.

Measure recovery through reply effect, not star-count math

It's tempting to reduce recovery to arithmetic. A review that moves from one star to four removes more drag from your average than a new five-star review adds. That's true, and it's a decent argument for why chasing detractors beats chasing new praise. But it's the wrong way to measure whether recovery is actually working, because arithmetic doesn't know whether any given reply was good.

The measurement that does know is reply effect: whether the star rating actually moved on reviews that got a developer reply. Track it only on reviews below five stars, since a mostly five-star base flatters any average you compute. Google says "Responding to a negative review can increase that rating by an average of +0.7" (Google Play Console). That figure is per replied review, not per app. Independent research puts the same lever at 4.4% of replied reviews getting raised, against 0.7% with no reply at all. The fuller citation is in how measuring reply quality actually works. Either way, the lever is the same: a reply that answers the complaint gives the reviewer a reason to revisit it. A reply that doesn't, doesn't.

Reply effect this period versus last, split by AI-drafted and human replies.

Read reply effect next to reply quality, not instead of it. Quality up and ratings moving on the reviews you replied to means the work is paying off. Quality up and ratings flat means your quality checklist is probably grading the wrong things. Ratings moving while quality falls on paper means something is working that your written standard doesn't cover yet, and it's worth reading those replies directly instead of trusting the score. Reply Quality checks published replies against your own written standard after they go out, flags the ones with wrong facts or the wrong language, and tracks the trend. That way you're not relying on a spot check during the highest-stakes weeks of a recovery.

A recovery checklist, for when you're ready to improve the rating rather than just diagnose it

• Confirm the cause before writing anything: regression, outage, pricing, bombing, or neglect. Line the start of the drop up against your release timeline and any service incidents first.
• If it's a regression, ship the fix, verify it's actually fixed, then reply to every affected review naming the fix and the version.
• If it's bombing, document the pattern and report it through Apple's report-a-problem tool or the Play Console's review-flagging tools, rather than arguing with it in public. Keep replying to the reviews inside the wave that read as genuine.
• Prioritize replies to reviewers who already complained about something you've since fixed over reviews from people you haven't heard from at all.
• Do not paste the same sentence under a hundred different complaints. A repeated reply counts in your coverage number and reads as nothing to the reviewer.
• Use Apple's reset only after the underlying problem is verified fixed. Use Google's recency weighting as a reason to concentrate genuine positive activity into a real window, not as a reason to skip the fix.
• Track reply effect on replied reviews below five stars, separately from whether the replies were good. Read the two together.

Your rating recovers when the reviews it's built on get answered, not when the reply count does

A dropped rating is a symptom. The reviews underneath it are the actual signal, and every day they sit unanswered is a day the average keeps reflecting a problem you may have already fixed. The fastest way back isn't the reset, the recency algorithm, or a higher reply rate on its own. It's diagnosing the cause correctly, writing the specific reply that gives someone a real reason to reconsider what they wrote, and measuring whether it worked.

AppReply watches your review stream for the spike or drop that signals something changed, drafts contextual replies for human approval, and checks what actually published against your own standard, so recovery is something you can see happening rather than something you're hoping is happening.

See how alerts work | See how reply quality checks work | Book a demo