How to Reply to App Store Reviews: Rules, Tips and Templates

An App Store review is feedback you didn't ask for, in public, next to your download button. A good reply turns it into a conversation: the reviewer is notified, can update their review, and everyone reading the product page sees that someone is listening. A bad reply does the opposite, in the same public place. This guide covers how replies work as of 30 April 2026, the rules Apple sets, which reviews to answer, and templates you can adapt.

Shipping on Android too? The Google Play version of this guide is How to Reply to Google Play Reviews, With Templates.

The short version

• Reply from Ratings and Reviews in App Store Connect. You need the Account Holder, Admin or Customer Support role.
• Each review shows one response. You can edit or delete it, and replies can take up to 24 hours to appear.
• The reviewer is notified and can update their review. Your reply stays public even if they edit theirs.
• Guideline 5.6.1: be respectful, keep to what the reviewer said, and leave out personal information, spam and marketing.
• For a feature request, tell the reviewer where in the app they can add it or vote for it, so you can tell them when it is done.

How replies work

Apple's help page Respond to reviews covers the mechanics. As of 30 April 2026:

1. In Apps, select the app, then click Ratings and Reviews in the sidebar. Users with the Customer Support role alone land there directly.
2. Pick the platform at the top right.
3. Find the review, click Reply, write your response and click Submit.

A few rules from the same page and from Apple's ratings and reviews overview:

• One response per review appears on the product page. You can edit or delete it at any time, and you don't have to be the person who wrote it.
• Responses can take up to 24 hours to appear and show as pending until then. Edited responses carry a note that they were edited.
• When you respond, the customer is notified and can update their review. Several quick edits, such as fixing a typo, produce a single notification.
• Your response stays visible even if the customer later edits their review.
• People can rate apps on every platform, but written reviews exist for iOS, macOS and visionOS apps, not tvOS.
• Apple also lets you manage responses through the App Store Connect API. Our guide to creating an App Store Connect API key covers the setup.

Apple's rules for replies

Guideline 5.6.1, App Store Reviews, asks you to treat customers with respect when responding, keep responses targeted to what the user said, and not include personal information, spam or marketing. The wider developer code of conduct in 5.6 applies too: no harassment, intimidation or bullying, in review replies or anywhere else.

Apple's page on ratings, reviews and responses adds practical advice, as of 30 April 2026:

• Keep replies concise, address the specific feedback, and personalise them rather than pasting the same text under similar reviews.
• If a reviewer reports a download error or a billing problem, direct them to Apple Support.
• If a review contains offensive material or spam, use Report a Concern in App Store Connect instead of replying. The reviewer isn't told you reported it.

Which reviews to answer when time is short

You can reply to any review, however old. If you can't answer every one, Apple suggests prioritising reviews with the lowest star ratings and those that mention technical problems with the current version. Two moments are worth extra attention:

• Right after a major release, when people are most likely to read and update. Apple suggests replying promptly to new and updated reviews then.
• When an update fixes something a reviewer complained about. Apple suggests mentioning the fix in your release notes and replying to the relevant reviews. Our guide to writing release notes covers the notes half.

You can set up email alerts in App Store Connect for when a reviewer edits a review you have replied to, so a changed review doesn't go unseen.

Templates

Adapt these. Apple asks for personalised replies, so treat each one as a starting point and refer to what the reviewer actually said.

A bug report

"Thanks for telling us, and sorry the map stopped loading after the update. We have found the cause and the fix is in review now. If it still happens after the next update, please write to us from Settings > Help so we can look at your device's details."

A feature request

"Thanks, offline maps are high on our list too. You can add it, or vote for it, in the app under Settings > Suggest a feature, and you will see its status change there as we work on it."

A misunderstanding

"Thanks for the review. Trail notes are there, just tucked away: open any hike and tap the pencil at the top right. We will make that easier to find in a future update."

A billing problem

"Sorry about the charge. Purchases go through Apple, so Apple Support can look at the payment and any refund. If something in the app didn't unlock, write to us from Settings > Help and we will sort it out."

Praise

"Thank you, this made our day. Have a great time on the trail."

After a fix or a feature goes out

Edit your existing reply rather than writing a new one, since each review shows one response: "Update: offline maps are in version 4.2, out now. Thanks for asking for it."

Pointing reviewers to your in-app board

Feature requests in reviews are a poor fit for the review format. You can't ask a follow-up question, other users can't add to them, and there is no way to tell the reviewer it is done except by editing a public reply. Pointing them to a place inside your app fixes that, and it keeps your reply targeted to what they said, as 5.6.1 asks. Keep it to a short, plain instruction. A sales pitch for your other features would be marketing.

How FeedbackKit fits in

To be clear about what FeedbackKit does and doesn't do: it doesn't read, import or reply to App Store reviews. Replies stay in App Store Connect. What FeedbackKit gives you is the in-app place to point reviewers to: a board where they can post the request, vote for it if it is already there, and comment.

Once the request is on the board, the follow-up is handled. When you move it to Completed, FeedbackKit emails the person who submitted it, on every plan, if they gave an address and Completed is on the project's list of statuses that send email. A new project's list includes Completed. Choosing a different list needs Pro, and emailing voters who opted in needs Team. Your team gets email and push on every plan, and Slack on Pro and up.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Then edit your App Store reply to say it is out, and the loop is closed in both places. We wrote more about that in closing the loop with status emails, and about asking for ratings at the right moment in our guide to SKStoreReviewController and requestReview. SDK setup is in the Swift docs.

If you want somewhere better than a review for feature requests, start free.