§Use caseOne operator

Read a thousand app reviews

A thousand one-star reviews reads as a wall of text, and the usual way through it is to have someone read for an afternoon and come back with a feeling. I built this to take the afternoon: it groups the reviews into what repeats, counts each one, and attaches quotes you can check. There is also a hard limit on the Apple side, and I would want to know about it before planning a run.

A real run, complaints ranked by how many reviews they cover
A real run, complaints ranked by how many reviews they cover
A themes row from a real Google Play run, showing complaint labels with their counts.

The questionHow do I find out what people complain about in my app's reviews on the App Store and Google Play?

How the working version is put together

  1. Point it at either store, or both

    An App Store id, a Google Play package name, or a URL copied straight out of the address bar of either store. Mix the two in one run and the same app comes back from both sides, which is usually where I find the interesting difference.

  2. Collect the reviews first

    I write one row per review: the star rating, the title and body, the app version it was left against, the date, the storefront, the developer's public reply where the store publishes one, and a link back. No key is needed for this part, and no browser or proxy either. Both stores publish these.

  3. Group the complaints and the praise

    The themes come from a single model call per app. It returns complaint themes and praise themes, each with a label, a count and up to three quotes, plus a readout a product owner can read in twenty seconds. On a one and two-star filter the praise list is often empty, and I would rather show you an empty list than pad it.

  4. Check every quote character for character

    The model hands back a quote and the review id it came from, and the quote is kept only if it appears in that review character for character, ignoring case and whitespace. Anything else is thrown away and counted on the row. Two quotes from my own runs I opened at their source and confirmed by hand.

  5. Record which pages actually answered

    On the Apple side I care about this more than anything else in the build. It asks for all ten pages of the feed every run, never treats an empty page as the end of it, and writes down exactly which ones came back with reviews. A thin result you can see the cause of is worth far more than a thin result that looks complete.

What it found on public apps

These are public reviews I scanned to test the build, and nothing more than that. Trainline's one and two-star App Store reviews clustered into refunds and change fees at 13 reviews, app reliability and activation at 12, confusing booking UX at 10, and several smaller ones under those.

Evri's Google Play reviews clustered differently. App crashes or the app not opening covered 22 reviews. Login and lockouts covered 12, training videos stuck 11, and low pay 10. I got no praise themes at all. On a one and two-star filter that is the correct answer, and a tool that invented one there would be lying to me as well as to you.

Apple's feed is cache-flaky, and Google Play is not

Apple's customer-reviews RSS feed serves at most ten pages, and in practice most of those pages come back empty at any given moment. Which ones answer is a property of Apple's cache rather than of the app. I watched one app answer on all ten pages for 113 reviews in the morning and on none at all two hours later, across four different country storefronts. It is not the user agent and it is not the headers, and retrying the same empty page does not flip it.

So on a bad window an App Store app returns nothing at all. That is the limit, stated plainly, and the only response I have to it is to run it again later. Google Play is the reliable half: real pagination, 150 reviews a page, a permalink for every review, developer replies and a full rating histogram.

Fields that exist on one store only

Google Play publishes developer replies, a per-star histogram and a permalink for each review. Apple's feed publishes none of those three, so I have to leave App Store rows carrying a null reply, a null histogram, and a URL pointing at the app's reviews page rather than at the review itself.

There is no per-star histogram on Apple's lookup endpoint either, so where you see a rating breakdown on an App Store row I computed it from the reviews actually collected. Neither store attaches a reviewer's country to a review, so the country field is the storefront it was read from.

Read this before you spend anything

When I would tell you not to bother

If your app is App Store only and you need a complete picture on a fixed date, I would expect this to frustrate you. The feed decides how much it feels like giving you, and no amount of retrying fixes a quiet window. Plan for repeat runs, or lean on the Google Play side.

If you want five years of history, neither store will give it to you. Both show recent reviews, newest first. That is exactly right for working out what is breaking now and useless for a long trend.

And if your app has forty reviews, read them yourself. The value here starts when the reading stops being possible.

What lands on your desk

  • A row per review from either store, with version, date, storefront and the developer reply where it exists
  • A themes row per app: up to eight complaint themes and five praise themes, each counted and quoted
  • Quotes verified character for character, with the failures dropped and counted on the row
  • A collection note saying which feed pages answered, so a thin run explains itself
  • A one-paragraph readout per app for people who will not open the dataset
  • If you want this arriving as a weekly digest or a ticket per theme, that is the work I do

Questions this page answers

Which stores does it read?
The App Store and Google Play. You can give it an App Store id, a Google Play package name or a URL copied out of either store, and you can mix both stores in one run.
Why did my App Store run come back with almost nothing?
Apple's public review feed is cache-flaky. Most of its ten pages return empty at any given moment and which ones answer is Apple's cache rather than your app. I watched one app return 113 reviews at one point in the day and zero two hours later. Run it again later, and read the collection note to see which pages answered.
Is Google Play more reliable?
Google Play is the half I trust. It has real pagination at 150 reviews a page, a permalink per review, developer replies and a full rating histogram, none of which Apple's feed gives you.
Where does the App Store rating breakdown come from?
Apple's lookup endpoint publishes no per-star histogram, so the breakdown on an App Store row is computed from the reviews that were actually collected.
Can I trust the quotes?
Each quote has to appear in its source review character for character, ignoring case and whitespace, or I drop it and count it. The labels and counts are the model's own reading of the sample, so treat those as a checkable summary rather than a measurement.

Want this built and handed over working?

One line is enough to start. You get an honest answer on fit, and a number rather than a discovery call.

Start a brief