What is app store review research?
App store review research means reading the 1, 2 and 3 star reviews of apps that already serve your audience, on the Apple App Store and Google Play, to find what users keep asking for and never get. Every review is dated and tied to an app version, so you can see when a problem started and whether the developer ever fixed it.
The method has a twist that other review sources lack: update history. When a popular app ships a new version, angry reviews spike with lines like “bring back” and “since the last update”. Those spikes show you what users depended on, which is a cleaner signal than any wish list.
When should you use it?
- You want to build an app (consumer or a mobile tool for professionals) and at least 3 competing apps exist with hundreds of reviews each.
- You plan a service around an app category, like coaching for people who quit fitness apps, and need to know why they quit.
- You suspect the big player is coasting: lots of downloads, a stale product, a growing pile of feature requests.
- Skip it if your category has no apps yet (go to Reddit problem research) or if the apps are mostly used on desktop, where reviews live on G2 and Capterra instead.
How do you do it, step by step?
-
Choose 3 to 5 competing apps. Take the top app in the category, one fast-rising app and one niche app built for a narrower group. Write down each app’s rating, number of ratings and price model (free, freemium, subscription).
-
Sort for the harshest and the newest reviews. Apple says that when an app has enough ratings in your country or region, you can browse its reviews by most recent, by the most negative and by other sorts. On iPhone, open the app page, tap through to all ratings and reviews and switch the sort. On Google Play, open the full list of reviews and read the low-star ones. Read 40 to 50 reviews per app, on both stores if the app is on both.
-
Tag each review in one of 6 buckets. Missing feature, bug or crash, paywall or price anger, wrong fit for a role (“as a teacher I need…”), update regression (“used to work”), and support silence. Put the exact words in a quote column. Airtable’s multi-select field makes this fast.
-
Line up the complaints with the version history. Open the What’s New section on the App Store page and its version history. Write the date of each major release next to your review dates. A cluster of “bring back” reviews in the 2 weeks after one release tells you which feature carried the app.
-
Read the developer replies. Apple notes that developers can respond to reviews and that those replies are visible to everyone. A copy-paste “thanks, we’ve passed this to our team” under the same request 20 times means the team can’t or won’t build it. That is an opening with a public paper trail.
-
Hunt for switching language. Search your sheet for “moved to”, “switched”, “deleting”, “cancelled my subscription” and “would pay for”. Switchers name the competitor they went to and the reason, which gives you both a gap and a price anchor.
-
Count across apps and pick one gap. A request that appears in 3 or more apps and is solved in none is a CATEGORY gap. Rank candidates by how many unique reviewers mention them and whether those reviewers are paying users (subscription complaints prove they pay).
What does a worked example look like?
Say Ines, a hypothetical dance-studio owner, wants to build a booking app for small studios. She studies 4 class-booking apps that studios use and that students download.
She reads 45 low-star reviews per app. The tags show that students can’t cancel a class inside the app in 2 of the 4 apps, waitlist notifications arrive after the class has started in 3 of 4, and one app’s latest version removed calendar sync. That last one jumps out: 14 of the 50 most recent reviews for that app say “bring back calendar sync”, all posted within 3 weeks of a single release.
The developer replies under the waitlist complaints are identical across 6 months: “We’ve shared this with our product team.” No fix ships.
Ines writes her gap: Students of small studios miss freed-up spots because waitlist alerts come too late, and studios lose the class fee. She also notes the studios pay a monthly fee for these apps, so the buyer and the price range already exist. Her next step is talking to 8 studio owners.
Which free tools help?
| Tool | What you use it for | Free plan |
|---|---|---|
| Apple App Store app | Reading and sorting reviews, version history, developer replies | Free |
| Google Play | Reading Android reviews, which differ from iPhone users | Free |
| Airtable | Tagging reviews with multi-select fields and counting by tag | Free plan available |
| Google Sheets | Timeline of release dates against review spikes | Free with a Google account |
Apple explains how ratings, reviews and developer responses work in About Ratings and Reviews.
What mistakes should you avoid?
- Reading only the top-sorted reviews. The default order mixes old and new reviews. Switch to the newest and the most negative.
- Treating bugs as opportunities. Crashes get fixed. Missing features and regressions that last for months are the real gaps.
- Building the feature everyone requests for a giant app. If the top app can add it next quarter, you are a feature. Look for requests tied to a specific group of users the giant ignores.
- Ignoring paywall anger. “Everything is behind a subscription now” can signal room for a simpler, one-time-purchase app.
- Forgetting Android. Google Play users are a different crowd with different devices and complaints. Read both if the app is on both.
How do you know it worked?
You have 150+ tagged reviews across 3 to 5 apps and at least one gap that meets our rule of thumb: mentioned by 10+ unique reviewers across 3 or more apps, still unsolved in the latest version, with a pattern of unhelpful developer replies.
Go: you can name the gap, the type of user who feels it and the app they would leave. No-go: every complaint is a bug or price whining. The category is served well enough; look at a narrower audience or another category.
What should you do next?
Turn your gap into questions for jobs-to-be-done interviews so you learn what users try to get done when the app fails them. Then mock the fix with a Figma clickable prototype and show it to the reviewers’ lookalikes. For web software, repeat the exercise with competitor review analysis. If you want an AI co-founder to push back on your conclusions, Fe/male Switch runs that validation as a startup game.
FAQ
Can I see all reviews for an app on the web?
The full, sortable list is easiest to read in the App Store app on an iPhone or iPad. Google Play shows reviews on the web and in its app. Paid review-monitoring tools exist for bigger projects, and you can skip them for a first pass.
How far back should I read?
Focus on the last 6 to 12 months, because apps change fast. Go further back only to check whether a complaint is old and still unsolved, which makes it stronger.
Are review-analysis tools worth paying for?
Not at this stage. Reading 150 reviews by hand teaches you the vocabulary users use, which you need for your landing page later. Pay for a tool only once you track the same competitors every month.
Updated 26 October 2026 · Written by the Fe/male Switch team