Your first one-star review will arrive within about a fortnight of launch, it will be about something you already know is broken, and it will sting more than it should. What you do next matters more than most founders expect, because an app store reviews response is not really a message to that one person. It is a public artefact that every future visitor to your store listing reads while deciding whether to download. This guide covers the system we put in place for every product we ship: who owns it, how fast to reply, what to write for each type of review, and how to ask for ratings without becoming the app everyone mutes.
What makes a good app store reviews response?
A good app store reviews response acknowledges the specific problem in the reviewer’s own words, states one concrete fact about what is happening or what has changed, and offers a private route to continue. It stays under sixty words, avoids marketing language entirely, and never argues. The audience is not the reviewer. It is the next hundred people reading your listing.
That last point reframes the whole exercise. A defensive reply to an unfair review makes you feel better for an hour and costs you downloads for a year. A calm, specific reply to the same review reads as competence, and prospective users notice it far more than they notice the complaint itself.
The mechanics, briefly
Both stores let you reply publicly, and the rules differ slightly. On the App Store you respond through App Store Connect, one reply per review, editable afterwards, and the reviewer gets a notification with the option to update their rating. On Google Play you respond through the Play Console, and replies are also editable and notify the user. In both cases your reply is public and permanent enough that you should write it as though it will be screenshotted.
The mechanical part that most teams get wrong is not the writing, it is the routing. Reviews sit inside a console nobody logs into, and by the time somebody reads them the moment has passed. Set up alerts into a channel your team actually watches, and name one person as the owner. Shared responsibility here reliably means nobody does it.
Reply fast, and know why
Forty-eight hours is the target. The reason is not politeness, it is that a reviewer who is still annoyed is a reviewer who might still change their rating. A week later they have moved on and your reply is purely for the audience.
There is a second reason. Negative reviews cluster after releases, so a fast response loop tells you within a day whether the version you shipped last night broke something. We treat a spike in one-star reviews as a release signal, in the same way we treat a crash rate, which is part of the instrumentation we describe in how to set up app analytics from day one.
The five types of review and what to write
Almost every review falls into one of five buckets. Sort first, then write.
1. The bug report
Someone hit a real defect. This is the easiest type to handle and the most valuable, because they are doing your QA for free.
Thanks for flagging this, and sorry it caught you out. We have reproduced the crash on the checkout screen and a fix is in the release going out this week. If you email support@example.com we will let you know the moment it lands.
The template works because it does three things: confirms you can reproduce it, gives a timeframe, and moves the conversation somewhere private. Never promise a date you cannot hold. “This week” that becomes six weeks is worse than “we are working on it”.
2. The missing feature
They want something you have not built. Half the time it is on the roadmap, half the time it never will be. Be honest about which.
This one comes up a lot and it is on our list for the next few months. Not promising a date yet, but it is a real priority rather than a polite no. If you want the detail of what you need, drop us a line at support@example.com.
And when the answer is genuinely no:
Honest answer: we are not planning to add this, because it would pull the app away from what it does well. Thanks for taking the time to explain what you needed, and sorry it is not a fit.
A clear no is respected far more than a vague maybe, and it stops the same request arriving every month.
3. The misunderstanding
The feature exists and they could not find it. This is a design problem wearing a review costume.
That option is there, it is under the three-dot menu on the main screen, which is clearly not obvious enough. We are moving it somewhere more sensible in the next update. Sorry for the runaround.
Take the blame for the discoverability. Never write anything that reads as “you did not look properly”. And genuinely fix it, because for every person who wrote this review there are dozens who just deleted the app.
4. The genuine criticism
The app works as designed and they think the design is wrong. This is the hardest one, and it is where most teams go defensive.
Fair point, and we hear it. The current flow was built for people doing this occasionally, which makes it slower for someone using it daily like you. We are looking at a shortcut for exactly this case. Thanks for being specific about it, it helps.
Naming the trade-off out loud is what makes this work. You are not conceding that you were wrong, you are explaining the decision, and readers can tell the difference.
5. The abusive or irrelevant one
Personal abuse, spam, or a review about something outside your app entirely. Do not engage. Report it through the store’s own process and move on. Both stores remove reviews that breach their content policies, though not quickly and not always.
Do not forget the five-star reviews
Most teams only reply to complaints, which is a missed opportunity. Replying to positive reviews takes twenty seconds, makes the reviewer more likely to stay, and fills your listing with visible evidence that a human is home.
Keep it short and specific, and never sell:
Really glad the weekly summary is useful, that was the feature we agonised over most. Thanks for taking the time to write this.
One caution: never reply to a positive review with a request to share the app or upgrade. It reads as transactional and it is the fastest way to turn a fan into someone who stops writing reviews.
Asking for ratings without being irritating
Your rating average is mostly determined by when you ask, not by how good the app is. Frustrated users volunteer reviews. Happy users need prompting.
Three rules. Ask after a success moment, meaning the point where the user has just completed the thing your app exists to do, never on launch and never after an error. Use the native rating prompt rather than a custom dialogue, because both platforms limit how often it can appear, and respecting that limit is both a policy requirement and good manners. And never gate the prompt behind a satisfaction question that routes unhappy users to a feedback form and happy ones to the store, because both stores prohibit it and it is dishonest.
If your average is already damaged from a bad launch, the fix is volume rather than deletion. A sustained flow of new ratings moves the average faster than anything else, which is another reason to solve distribution properly, as covered in getting your first 100 app users in the UK.
Turn reviews into a backlog, not a chore
The teams that get the most out of reviews treat them as research. Every review that describes a real problem gets tagged in the issue tracker, and once a month someone reads the tags together rather than one at a time.
Patterns appear quickly. Five separate complaints about the sign-up flow mean the sign-up flow is broken, even if each one looked like a different issue. It is the cheapest qualitative research available, and the only kind you get for free, though it is no substitute for actually talking to people, which we argue for in user research with five customers.
One more thing worth tracking: which app version each review came from. A one-star review from four versions ago tells you about a problem you may already have solved, and the response should say so, because it reassures the reader far more than a generic apology.
Getting this right before you launch
The review system is something to set up before release, not after the first complaint arrives. Alerts routed, owner named, templates written, rating prompt placed after a genuine success moment. It takes about an hour and it is the cheapest hour in your entire launch plan, which is why it sits on our pre-launch checklist alongside everything in how to prepare for App Store review in the UK and the Google Play equivalent in launching on Google Play in the UK.
If you are approaching a launch and want a second pair of eyes on the whole release plan, including the parts that happen after the app goes live, tell us where you are through our project brief form. The month after launch is the one most teams have no plan for, and it is the one that decides how the product is received.
.webp)
.webp)
