The App Review Reply Reference: Every Mechanic, Both Stores

Here's the whole reference in one breath: Google Play caps a developer reply at a hard 350 characters, Apple publishes no official limit at all, both stores give you exactly one public reply per review, that reply is editable forever, and both notify the reviewer the moment you post. Everything else — who's allowed to reply, when it goes live, what the APIs will and won't touch — sits underneath those five facts. Bookmark this and stop guessing.

Most of what trips people up isn't the reply itself; it's the plumbing around it. A teammate whose role doesn't include the reply button. A reply truncated because nobody knew the cap was 350. A review that vanishes from the API before anyone answered it. So we'll go mechanic by mechanic — permissions, character limits, the one-reply rule, edit and delete, notifications, timing, and API windows — accurate to 2026, with honest hedges where Apple documents no number.

Replying is a permission, not a default. The person staring at a nasty one-star may not be the person with the button, and a role mismatch is the quietest way a review sits unanswered for a week.

On the App Store, per Apple's role documentation, the roles that can respond to customer reviews are Account Holder, Admin, App Manager, Marketing, and Customer Support. The Customer Support role exists largely for this one job. Developer and Finance cannot respond. On Google Play, replying is governed by the granular "Reply to reviews" permission, which an owner or admin grants per app or account-wide, so a support contractor can answer reviews without touching releases or finance.

Per-app scoping matters the moment more than one person touches reviews — "who can hit send" is a real safety control. It's the principle behind ReplyArgus roles: a drafter writes but never publishes, a viewer reads and never consumes a seat. For the store-by-store differences, see [App Store vs Google Play review replies](/blog/app-store-vs-google-play-review-replies).

This is the most-searched mechanic, and where a confident wrong answer does real damage. The two stores aren't symmetric, and only one publishes a number.

On both stores the model is identical: one public developer response per review, not a thread. You get a single reply that represents you, with no back-and-forth chat. The reviewer holds one slot too, so neither side stacks new entries.

But that slot isn't frozen. On the App Store you can edit or delete your response anytime; on Google Play you can update it, overwriting the old one. So if you promised a fix in version 4.2 that actually shipped in 4.2.1, go correct your own reply. The reviewer, and everyone reading the listing later, sees only the current version.

Yes, and this is the mechanic that makes replying worth the effort at all. Google Play emails the reviewer your response with the reply text included; Apple notifies the reviewer and surfaces the option to update their review. Either way, someone who had moved on gets tapped on the shoulder at the moment they're deciding whether you deserve to keep their one star.

This is why the research is so consistent. Google reported roughly a +0.7-star average lift for developers who respond (I/O 2019), and Hassan et al. found reviewers who got a response were about 6x more likely to raise their rating (4.4% versus 0.7%) across 4.5 million reviews. The notification is the delivery mechanism for all of it. To make the alert land on your side too, see [get notified of new App Store reviews](/blog/get-notified-of-new-app-store-reviews).

Replies aren't instant-and-guaranteed the way a comment on your own site is. Both stores run responses through moderation and can hold or remove a reply that violates content policy, so timing is "usually quick, occasionally delayed, always subject to content rules."

A reply typically appears within minutes to a few hours, so don't treat it as a real-time chat. Keep replies free of profanity, personal data, and anything that reads as a violation. And because AI-drafted replies are allowed as long as a human is accountable for what publishes, the moderation risk is about content, not authorship. We cover that line in [is AI review reply against App Store policy](/blog/is-ai-review-reply-against-app-store-policy).

Reply at any real volume and you're eventually touching the APIs, each with a shape you design around. The most important quirk lives on Google's side.

The App Store Connect API is friendlier on time — reviews don't expire out of a window the same way — but it's still a build: JWT auth, paging, rate limits, and the CRUD above. Between the two you're maintaining two auth models, two data shapes, one hard cap, and one silent expiry window, all so a reply goes out on time. That's the unglamorous reality behind "just reply to your reviews."

Put the mechanics together — 350 characters, one shot, notification-triggered, editable — and the target is a reply that's tight, specific, and true:

That reply fits under 350 characters, names the version, echoes the reviewer's own words, owns the failure, and makes one keepable promise. It'll never truncate on either store, and when the notification pulls the reviewer back, they read proof someone found their exact problem. The mechanics don't write the reply — they define the box it fits in, and a reply that ignores the box gets truncated, delayed, or ignored.

Every mechanic here is knowable. The hard part is honoring all of them at once — two stores, whatever language the reviewer wrote in, during the exact week a bad update triggers a spike of one-stars and the 7-day window is closing on reviews nobody got to. That's the seam where hand-managing reviews quietly breaks.

That's the gap [ReplyArgus](/features) closes. It watches both stores in one inbox, so the 7-day window never lapses, and drafts each 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 (by rating, keyword, language, or store), and role controls decide who can hit send. It's the plumbing of this whole reference, handled, and reachable from your own tools over the [MCP connector](/agentic-tools).