Does Your Developer Response Disappear When a User Edits Their Review?

On Google Play, yes: when a reviewer edits their review, your developer response usually disappears, and you have to write a new one. On the Apple App Store it's the other way around, where your response generally stays attached to the review through edits. So say you replied to a one-star, the user bumped it to four after your fix, and now your carefully written reply is gone from the Play listing. That's not a bug. That's Google Play working as designed.

The reason it's so easy to miss is almost cruel: your reply is often the thing that *caused* the edit. You answer, the store notifies the reviewer, they come back and raise their rating. In editing, Google Play detaches the very reply that earned the change. Below: what each store does, why Play behaves this way, and how to catch an edited review before the window to re-reply closes.

The two stores handle an edited review in opposite ways, and knowing which is which saves you a panicked support ticket.

On Google Play, a review holds one developer reply at a time, bound to the version of the review it answered. When the user edits (new stars, new text, or both), the store treats it as a materially changed review and clears the old response, since it was written against words that no longer exist. Your reply isn't moved or archived; it's detached, and the listing shows the edited review with no developer response until you write a fresh one. The whole store-by-store rulebook is in the [app review reply mechanics reference](/blog/app-review-reply-mechanics-reference).

On the App Store, Apple keeps your response attached across the reviewer's edits. Only the current version of each side is ever shown, but your response persists rather than vanishing. It behaves more like a running edit between two parties than a reply that gets wiped. You can revise your response to match the new review, but you're not forced to start over the way you are on Play.

Because a reply answers a specific complaint, and once the complaint changes, the answer can be wrong. Say you replied "we've fixed the crash you hit in 5.1" to a one-star. The user updates to five stars and rewrites it to "works great now, thanks for the fast fix." Leaving your original reply, which apologizes for a crash the review no longer mentions, would read as bizarre to the next person browsing. Detaching it is Google keeping the public record coherent.

There's an irony worth sitting with. The reply is the strongest nudge to edit a review at all: Google reported roughly a +0.7-star average lift for developers who respond (I/O 2019), and Hassan et al., studying 4.5 million reviews, found reviewers who got a response were about six times more likely to raise their rating than those who didn't (4.4% versus 0.7%). So on Play, the more effective your reply, the more likely it triggers the edit that erases it. That doesn't cost you the rating change; the higher star count sticks. It just means the *reply* is gone, and a listing full of freshly-improved ratings with no visible responses undersells how responsive you actually are.

It's worth seeing the same loop from the reviewer's side. A notification pulls them back, they edit, and on Play your reply quietly clears in the process. We walk through exactly what the person on the other end sees in [what happens when a developer replies to your review](/blog/what-happens-when-a-developer-replies-to-your-review).

Treat an edited review as a new event, not a closed one. The practical discipline is simple: watch for edits, and re-reply where it still makes sense.

That last point is the sharp edge. The [Google Play Reviews API](/blog/google-play-reviews-api-reference) surfaces a rolling ~7-day window, so a re-reply opportunity has a real expiry. Miss the edit for eight days and automation can't rescue it: you're left with a five-star review and no developer response until the user happens to edit again. Reliable polling is what keeps that window from closing on you.

When a review flips from one star to five after your fix, the re-reply isn't an apology anymore. It's a short, warm acknowledgment that closes the loop and leaves a visible developer response for the next reader:

Under 350 characters, safe on both stores, and it does one job: it puts a developer response back under a review that Google Play stripped on edit. Anyone reading the listing later sees a happy reviewer *and* a team that answered. Without the re-reply, they'd see only the first half.

The mechanic is knowable. Honoring it at volume is where it breaks. To keep a visible developer response under every review, you'd have to notice each edit across two stores, tell a happy edit from an angry one, and re-reply before Google's seven-day window closes, during the exact week a bad update spikes edits and your attention is thinnest. Hand-managing that is how the best turnarounds end up with no reply attached.

This is the gap [ReplyArgus](/features) is built to close. It watches your Apple App Store and Google Play reviews in one inbox and re-surfaces a review the moment it's edited, so an edit that cleared your Play reply doesn't vanish from your radar. It drafts each reply, and each re-reply, in the reviewer's own language (100+ languages, both directions), grounded in your past approved replies and an auto-ingested knowledge base of your store listing. Nothing publishes until you approve it, or until a rule you set does. And because it exposes your reviews over an [MCP connector](/agentic-tools), you can triage and re-reply straight from Claude or Cursor instead of tab-hopping between two dashboards.