App store review analysis for indie developers

The two stores behave completely differently

Google Play gives you real files. Download reports → Reviews, pick the app and the month, and you get a CSV from a private Google Cloud Storage bucket tied to your developer account. The data is captured daily and posted within three to seven days, so this month is always partial — which is fine for a weekly triage as long as you know it.

App Store Connect gives you a web page. You can view, sort and respond to reviews; you cannot export them, and Sales and Trends has no review report. The documented route is the App Store Connect API endpoint for customer reviews, at a maximum of 200 per page.

Full steps and the exact links for both: App Store and Google Play.

Apple keeps no review history. If you did not snapshot it at the time, there is no way to reconstruct it later.

Apple does not keep your review history

When a customer edits a review, the new version replaces the old one. Apple keeps no history of what it said before.

This has a consequence most developers discover at the worst moment. You ship a fix for the crash everyone is complaining about, you want to show that complaints dropped — and you cannot, because the reviews that complained have been quietly edited into “fixed now, thanks” and the originals are gone.

The fix is cheap if you do it early: pull the API once a week and keep the JSON. A cron job and a folder is enough. Seven lines of shell now is a year of history later, and there is no retrospective way to get it.

One more Apple detail worth knowing: the country or region associated with a rating reflects where the customer originally bought the app, not where they are now. Treat geographic splits accordingly.

App reviews break differently from product reviews

A mug fails by arriving broken. An app fails in eight recognisable ways, and the label set should name them rather than reusing ecommerce topics:

• Bugs and crashes — outright failures: crashing, freezing, data loss, wrong behaviour.
• Performance — slow, laggy, battery, storage, data use. Deliberately separate from bugs: “it takes nine seconds to open” is not a crash and needs a different fix.
• UI and usability — layout, navigation, confusing flows, accessibility.
• Pricing and subscription — cost, paywalls, trials, unexpected charges. This one is worth watching closely after any pricing change.
• Feature request — asking for something the app does not do, or for a removed capability back. The second kind is a much stronger signal than the first.
• Login and account — sign-in, sign-up, verification, sync, deletion.
• Ads — frequency, placement, unskippable video.
• Support — contacting you, or not hearing back.

Add your own on top: the name of the feature you shipped last month, the SDK you migrated, the platform version you dropped support for. Those are the ones that answer the question you actually have this week.

A twenty-minute weekly triage

1. Pull the week’s reviews — Play’s monthly CSV filtered by date, or your API snapshot.
2. Run them with the app label set. Thirty at a time is free and needs no account, which for most indie apps is the whole week.
3. Read the needs a reply list first. These are people with an unresolved problem, and a reply on a one-star review is the single highest-leverage twenty minutes available to you. Both stores let you respond.
4. Then read the topic list sorted by negative volume. One week tells you little; four weeks of the same labels tells you whether last release helped.
5. File the severity 4 and 5 items as bugs with the quote attached. A bug report containing the customer’s own words is easier to prioritise later than one containing your summary of them.

Comparing releases without fooling yourself

The obvious comparison — crash complaints before and after the fix — is also the easiest to get wrong, in three ways.

Review volume is not constant. A featured week or a review prompt rollout changes the denominator. Compare shares, not counts.

Reviews lag the release. Users on the old build keep reviewing it for weeks. A dip in the first few days after shipping is adoption, not improvement.

Edited reviews move. On the App Store an edited review simply becomes a different review, with the old text gone. Without your own snapshots the before-picture is not merely incomplete — it has been rewritten.

None of this is a reason not to compare. It is a reason to keep the label set fixed across runs, work in shares, and hold your own history. The general method covers the counting side in more detail.