ReviewFold
Guide · Competitor research
How to analyze competitor app reviews
A useful competitor review analysis ends with a short brief: what people value, where they run into friction, and what you need to check before changing your own product. A list of complaints alone leaves out the reasons people chose the competitor in the first place.
This guide is for a developer who already has a task or product in mind. If you are still deciding what to build, start with finding app ideas from reviews.
01 · The subject
Choose a competitor by the task.
Write down the activity you want to understand. For a photo tool, that might be enhancing a photo and saving the result.
Pick an app people use for that activity. A popular app in a nearby category may solve a different problem — and its reviews will tell you a great deal about a question you are not asking.
Include alternatives such as a built-in feature or a manual workflow in your notes. They may not have a review listing to analyze, but they still affect whether someone would switch.
Also record the options that have no reviews
- The built-in featureFree, already installed, and often good enough. It sets the floor your alternative has to clear.
- The manual workflowA spreadsheet, a group chat, a habit. It is the competitor that never appears in a store search.
- Doing nothingThe most common outcome. If the task is infrequent, this is the option most people choose.
02 · The frame
Fix the scope before reading.
Record the store, region, collection date, review dates and sampling rule. Recent written reviews are a view of what those reviewers chose to report, not a survey of everyone using the app.
Keep each app’s sample separate. If you later compare apps, check whether the stores, time windows and collection methods are comparable. More complaints in one saved sample do not by themselves make that app worse — a different sample size, a different release, or a different week of collection can produce the difference.
Two samples are not a ranking
A saved sample is a slice of what people wrote, not a measurement of the app. Before any comparison, ask whether the two slices were taken the same way.
03 · The reading
Read for value as well as friction.
Ask two questions: what outcome did the reviewer value, and what made reaching it difficult? Preserve both when they appear in the same account.
Here is a small example from 200 public Remini reviews collected from the US App Store on September 23, 2026. These selected historical accounts illustrate the method; they are not a current product test or a full audit. ReviewFold is not affiliated with Remini.
“All the photos come out amazing. Easy and free”
Adds to the briefOne reviewer values the result, ease of use and free access.
Still needs checkingWhat photos and workflow did they use? How did they judge the result?
“watch an ad in exchange every time you use one and when you export”
Adds to the briefDescribes ad-supported use and export in that person’s account.
Still needs checkingWhich features and conditions applied, and what works today?
“I truly used to love this app and the option to watch ads”
Adds to the briefThe full review contrasts earlier appreciation with current frustration about ads.
Still needs checkingWhat changed in the experience? The reported duration is not an independently measured benchmark.
These reviews suggest a tradeoff to investigate: access, effort and a usable output may all matter in the same workflow. They do not establish the relative importance of those factors for the whole audience. For a closer reading of what a positive account can and cannot support, see reading positive reviews for product strengths.
04 · The artefact
Write a brief that keeps facts and questions apart.
Use the following structure for one competitor. Fill only the parts your evidence supports — and leave the rest visibly empty.
- Task under study
- Enhance a photo and save a useful result. This is our chosen research scope.
- Value to investigate
- Result quality and ease of use, mentioned in a selected review.
- Access tradeoff
- Some selected accounts describe ad-supported use; another describes frustration with ads.
- Product facts checked today
- OpenNot yet checked in this example. Add the official source or the date of a legitimate walkthrough.
- Unresolved question
- Under what conditions does the access path help or obstruct completing the task?
- Implication for our product
- Investigate the tradeoff before assuming that removing ads alone creates a better alternative.
- Next action
- Observe the current workflow and ask a relevant user about a recent attempt.
- Reason to revise the brief
- The current experience differs from the historical accounts, or the issue is not important to the intended audience.
This is an editorial research brief, not a feature ReviewFold automatically generates. Use a review worksheet to keep the underlying excerpts traceable.
05 · The product itself
Check the current product separately.
Read current documentation and pricing, then try the relevant workflow where you can legitimately access it. Write down what you checked and the date. A complaint about a missing feature does not establish that it is absent today; the person may have encountered an eligibility rule, an unfamiliar screen or a different version.
As a competitor researcher, you do not have the other company’s logs. Keep the cause of an observed problem open unless you have evidence for it.
Date every fact
“They require a subscription to export” is a claim with an expiry date. Write the day you checked, and the brief will tell you when it needs re-reading.
06 · The next action
Decide what to learn next.
Choose the next check from the uncertainty in the brief, not from the biggest complaint in the sample.
- If the task is unclear, ask about the last attempt.A specific occasion beats a general opinion about the app.
- If a policy is unclear, look for current official information.Record the source and the date you read it.
- If accounts conflict, investigate the conditions under which each could be true.Two people can describe the same week and disagree.
For your own app, combine this research with your users’ feedback and product evidence. Do not copy a competitor’s requested feature just because it appears repeatedly. You still need to know whether it helps your intended users and fits your product.
Limits
A brief is not a verdict.
It records what you have read and what you still owe the decision. Confusing the two is how a complaint list becomes a strategy.
- One sample is not the marketMore complaints in one saved sample do not rank two apps against each other.
- Historical accounts expireA review describes the app on the day it was written, not the version you downloaded today.
- Value is not prevalenceA clear benefit in one account does not tell you how many people care about it.
- Cause stays openWithout the other company’s records, an observed problem has a description, not an explanation.
Current support, stated plainly
- Apple App Store: US and Canada. Google Play: US.
- Up to 200 recent public reviews per report.
- One app and one region per report; no cross-app comparison.
- A free preview shows themes and counts; the paid report adds review excerpts, PDF and CSV.
- Selecting competitors and checking their current workflows remain your work.
One region is not one language. A US listing collects reviews written in several languages, and a translated excerpt can look like a familiar complaint while describing a different task. Reading multilingual reviews keeps the original wording beside the translation.
Get a traceable starting point
Start from the feedback, then write the brief yourself.
ReviewFold analyzes one app and one region at a time, using up to 200 recent public reviews. It supports Apple US/Canada and Google Play US. The limited free preview shows themes and counts; a complete report adds review excerpts and PDF/CSV exports. Selecting competitors, checking their current workflows and comparing separate reports remain your research work.