Finding the Feature Requests in Your App Store Reviews

"Great app, but I'd give it five stars if it worked without signal." That is not a complaint about your app. It is a feature request with a star rating attached. App Store reviews are full of them, and they come from people who would never email you or join a beta. This post is a practical routine for finding those requests, tagging them so they add up, replying, and giving the reviewer somewhere better to put the idea.

The short version

• Read reviews on a fixed day each week, and look past the stars to the sentence that says what is missing.
• Tag every review with one type (request, bug, praise, other) and, for requests, a short label for the feature.
• Count the labels. Five reviews asking for the same thing in different words is one strong request.
• Reply to the requests, briefly, and tell the reviewer where the in-app board is.
• Add each new request to the board yourself, so later reviewers and users have something to vote on.

How feature requests hide in reviews

Few reviewers write "Feature request:". The idea is usually wrapped in something else. Look for these patterns:

• The conditional: "would be five stars if…", "would pay for this if…".
• The wish: "I wish it could…", "please add…", "hoping for…".
• The comparison: "the other app I used lets me…".
• The workaround: "I have to screenshot the map before I leave home." That is a request for offline maps, written as a description of pain.
• The quiet one-star: "Useless in the mountains." Angry, short, and still a request.

Mid-range ratings are the richest. A five-star review rarely asks for anything, and many one-star reviews are about billing or bugs. Three- and four-star reviews often come from people who like the app and want one more thing.

A weekly tagging routine

You do not need a special tool for this. A spreadsheet with one row per review works well, and it takes twenty to thirty minutes a week for most indie apps.

The columns

The rules

1. One type per review. If a review mixes a bug and a request, split it into two rows.
2. Reuse labels. Before you invent "maps-offline", check whether "offline-maps" already exists. A short, fixed list of labels is what lets the counts add up.
3. Quote, do not paraphrase. The reviewer's own words are useful later, when you write the request title or the release notes.
4. Count monthly. At the end of each month, sort by label and count. The top three labels are your strongest review-driven requests.

Replying to a review that asks for a feature

Apple lets you respond to reviews in App Store Connect. Its Ratings, reviews, and responses page, as of 4 June 2026, says that the reviewer is notified when you respond and can then update their review, that you can edit your response at any time, and that App Store Connect users with the Admin or Customer Support role can respond. It also asks you to keep responses respectful and free of personal information, marketing language and spam. For offensive reviews, it points you to Report a Concern instead of a reply.

For a feature request, a good reply does three things in a few lines:

1. Thanks the reviewer and names the idea, so they know you read it.
2. Says honestly where it stands: being considered, being worked on, or not likely soon.
3. Tells them where to add their vote inside the app.

For example:

Thanks for this. Offline maps is the most requested idea we have,
and it is on our list. You can vote for it, and follow its status,
under Settings > Feature requests in the app.

Keep it personal. A copied reply under fifty reviews reads like a form letter. Our guide on replying to App Store reviews covers tone and timing in more depth.

Why point reviewers to an in-app board

A review is a dead end for a feature request. Other users cannot vote on it, the reviewer cannot add detail, and you cannot tell them when it is done except by replying again. A board inside your app fixes all three. The request gets a count, the reviewer can comment, and the status changes as you work.

It also helps your rating. People who feel heard are more likely to update a review, and people who have a better place to ask are less likely to use the review box for requests in the future. Pair it with a well-timed rating prompt (see SKStoreReviewController) and the reviews you get start to reflect the app, not the missing feature.

How FeedbackKit fits in

FeedbackKit is a feedback board that lives inside your app. It does not read or import App Store reviews, so the tagging routine above stays a manual job. What FeedbackKit gives you is the place to send reviewers afterwards. The Swift SDK adds ready-made SwiftUI screens for the board, the submit form and request details (Swift docs). Put the board somewhere easy to describe in a reply, such as a "Feature requests" row in Settings.

When a review brings in a new idea, add it to the board yourself, then reply. Users vote and comment inside your app, and a new request starts with its submitter's vote. Voting stops when a request reaches Completed or Rejected, so the count you see reflects open demand. Duplicates from different reviewers can be merged in the admin app, with each voter counted once.

Here is the board your reviewers land on, with sample data from a fictional hiking app:

When a request moves to a status on the project's email list, FeedbackKit emails the person who submitted it, on every plan, if they gave an address. To bring review-driven requests together with the ones from email, TestFlight and support, see Get your iOS feature requests into one list.

Next week, read your reviews with a spreadsheet open. Start free and give those reviewers somewhere to vote.