How to Reply to App Store Reviews

A habit tracker shipped a reminder that did not fire. The 1-star review is specific: “7:30 a.m. reminder died after the last update. I missed three days.” That sentence is a gift. It names the feature, the time, and the version window. Your reply should be just as specific. It should also assume a stranger will read it, because a developer response on the App Store is visible to everyone, not only to the person who wrote the review.

Apple’s Respond to reviews is the path: in Apps, open the app, choose Ratings and Reviews in the sidebar, pick the platform, and click Reply. You can edit or delete the response later, and you do not have to be the person who wrote it. Put the same fix in What’s New so the product page and the reply tell one story. Asking for the review in the first place is the other post, how to ask for an App Store review.

Write for the next shopper

The reviewer already lived the bug. The person deciding whether to download is the audience that matters, and they will read your reply under the angry paragraph. If you sound defensive, you confirm the review. If you sound like a template that could apply to any app, you confirm you did not read it. If you name the reminder, the version, and what to do after updating, you give the next person a reason to believe the 1-star note is stale.

Roles are Account Holder, Admin, or Customer Support. Customer Support lands directly on Ratings and Reviews after picking the app. Pick the platform on the top right before you reply, because an iPhone review and a Mac review are not the same thread. There is no prize for speed that beats accuracy. A wrong version number in a public reply is worse than a reply that waits until the build is actually approved.

A template that is still about this bug

Use a shape, then fill every blank with this incident. The shape is: sorry for the specific failure, what broke, which version fixes it, how to confirm, and an invitation to edit the review after they have tried the build. The blanks are not optional. “Sorry for the inconvenience, we value your feedback” fits a coffee shop and a bank and this habit tracker, which means it fits none of them.

The public reply names the 7:30 reminder, the permission bug, and version 4.2. It asks them to edit the review after the reminder works. It does not beg for stars.

Here is the reply you would actually paste, edited so it could only belong to this bug: “Sorry the 7:30 a.m. reminder stopped after the last update. That build dropped repeating notifications when permission was already on. Version 4.2 fixes it. Update, then turn that reminder off and on once. If 7:30 fires tomorrow, you can edit this review so it describes the current app. If it still misses, reply with your iOS version and I will look at that device.”

Do not argue with the review

You will want to write “it works on my phone.” Do not. If the reminder failed for them, it failed for them. A public correction that they “must have” denied permission, when your own note says the bug was a dropped repeat on an already-granted permission, makes you look like you did not read your crash log or their sentence. State the cause you actually found. If you have not found it, say you are looking, and do not invent a cause to sound finished.

Skip sarcasm, skip the user’s name if you are not sure you should have it, and skip a link that looks like a marketing redirect. A support email is fine when you need a screenshot of the notification settings. The reply itself still has to stand alone, because most people will never email you. They will read three lines under the review and decide whether the tracker is abandoned.

Match What’s New to the reply

What’s New ships with the version. If 4.2 says “Bug fixes and performance improvements,” the reply is doing all the work and the product page is doing none. Write the release note the way you wrote the reply: the 7:30 reminder fires again, turn it off and on once after updating. People who never read reviews still read the first line of What’s New. People who read both should not find two different stories.

Promotional text can change without a new binary, and it does not affect ranking. You can put a short “4.2 fixes repeating reminders” line there while review is in flight, then replace it. It is not a substitute for the version note, and it is not a place to hide a keyword. The binary is what makes the reminder true. The reply should not promise 4.2 until that build is the one you are shipping.

Edit the reply when the facts change

Apple lets you edit and delete a response from the same Ratings and Reviews screen. Use edit when you promised the wrong version, or when 4.2 did not actually fix the repeat and 4.3 does. Delete when you posted something you would not want a shopper to see, including a reply that argued. Leaving a wrong version number up is a quiet way to collect a second angry review from the same person.

Reply to the pattern, not to every duplicate. If twelve reviews say the same reminder died, twelve copies of the same specific paragraph are fine. Twelve copies of a vague apology are noise. If one review is abuse with no product content, you do not owe it a speech. The reviews that name a step you can reproduce are the ones that change the next build.

What a reply will not do

A good reply does not delete the star. The reviewer has to edit it. Apple does not publish a search-rank weight for ratings, so do not reply because you think a paragraph moves you three places. Reply because the next downloader will read the thread, and because the writer might update the review after 4.2. If the overview rating is still a lie after the fix is widely installed, that reset is covered in do ratings change search rank. Written reviews stay either way.