App Store Review & Rating Monitor

Know the morning your app's rating moves — in every country you sell it in. Free.

Name your apps, pick your storefronts, run it on a schedule, and it publishes a row only when the reception actually moved: ratings arrived, the average shifted, or a new version shipped. Nothing happened means nothing in your dataset.

What makes this different from a review scraper

Every other App Store Actor hands you the corpus: five thousand reviews to analyse. That is a different job. This one tells you what changed since the last time it looked, which is the thing you act on the same day.

And it does it in every storefront separately. An app carries a different rating in each of the countries Apple sells it in, and they do not move together — the release that lifts your rating in the United States can sink it in Germany. A monitor that collapsed them into one number would report neither.

It can tell you what the new reviews were rated — without reading a single review

Apple publishes an app's average rating and the number of ratings it is an average of. Neither number says anything about one review. Across two checks, together, they do.

If a storefront moves from N ratings averaging A to N+k averaging A′, then the sum of every star ever given moved from N×A to (N+k)×A′ — and the difference is what the k new ratings contributed:

stars = ((N + k) × A′ − N × A) / k

For one new rating, that is the exact star value the reviewer left. So a row can say "one new review, and it was a 1-star" having read nothing but two numbers from a public endpoint.

And it tells you when it cannot. The published average is rounded, so the answer carries a margin that grows with the size of your app:

Your ratings	New ratings	Truth	What it derives	Published?
200	1	1★	1.001 ± 0.002	yes
5,000	3	1★	1.001 ± 0.017	yes
250,000	5	1★	1.20 ± 0.50	yes, at the limit
18,000,000	1	1★	4.685 ± 180	no

Above half a star of margin the row reports that ratings arrived and says the star value could not be established. It never rounds a doubtful answer into a confident one.

The boundary works out to one clean rule:

k new ratings resolve to a star value on any app with fewer than about 50,000 × k ratings.

So a single new review is readable on an app under 50,000 ratings, ten new reviews are readable under 500,000, and a hundred under five million. If you run WhatsApp you get rating movement and volume; if you run a normal app you get the stars.

How often it cries wolf

42 checks across 14 real apps and 3 storefronts, 90 seconds apart, with no releases in between: zero reported movement. Measured 2026-08-27 with scripts/run_false_alert_sweep.py, which ships in this Actor so you can re-run it yourself.

That is the number that matters, because it is the one that could sink the product. Apple serves this data from a CDN, and if two reads seconds apart disagreed, every scheduled run would invent movement and the arithmetic above would faithfully turn that noise into a star rating. It does not.

A fifteenth app in that sweep had been delisted. It came back as a failed row reading APP_NOT_FOUND for that one storefront, and the other 42 checks completed — which is the other half of the design working.

Who this is for

You are	What you get
A mobile team shipping releases	The row that puts a rating drop next to the version that caused it
An indie developer	The exact star of every review that lands, on an app small enough to resolve it
An agency managing app portfolios	Every client's apps and countries in one dataset, only the rows that need answering

What you paste in

App Store links, or just the number after id in one:

https://apps.apple.com/us/app/whatsapp-messenger/id310633997
310633997

Run it on Apify's scheduler — hourly, daily, whatever suits.

Input

Field	Type	Default	What it does
apps	list	—	The apps to watch. App Store links or ids. Required.
countries	list	["us"]	Which storefronts to watch each app in. Two-letter codes: us, gb, de.
onlyReportChanges	boolean	true	Publish a row only when something moved. Turn off to keep a full rating history.
stateStoreName	string	app-review-monitor-state	Where the baseline lives. Change it to run two independent watch lists.
proxyConfiguration	object	off	Leave it off. The endpoint answers a scheduled check without one.

What you get back

{
  "event": "reviews-changed",
  "app": {
    "appId": "1234567890",
    "countryCode": "de",
    "trackName": "Your App",
    "url": "https://apps.apple.com/de/app/id1234567890"
  },
  "rating": 4.56266,
  "previousRating": 4.62,
  "ratingChange": -0.05734,
  "ratingsCount": 4918,
  "previousRatingsCount": 4818,
  "newRatings": 100,
  "newRatingsAverageStars": 1.8,
  "newRatingsStarsMargin": 0.000487,
  "version": "3.4.1",
  "previousVersion": "3.4.0",
  "versionReleasedAt": "2026-08-25T15:51:23Z",
  "changeKinds": ["ratings-added", "negative-review", "rating-fell", "version-changed"],
  "previouslyCheckedAt": "2026-08-26T09:00:00Z",
  "status": "verified"
}

That row is one sentence: a hundred ratings landed in Germany averaging 1.8 stars, the rating fell 0.057, and 3.4.1 shipped the day before. No competitor puts those three facts on the same line. Every number in it is checkable against the two before-and-after figures on the same row — which is the point.

It also works the other way. Three 1-star reviews on that same app move the displayed average by 0.002, far too little to report as a rating fall — but the arithmetic still resolves them to 1.00 ± 0.016, so the row says a bad review landed and honestly says the rating did not move.

changeKinds carries negative-review as its own value, so you can filter a dataset down to the rows that need answering today without parsing anything. Three stars is deliberately not counted as a complaint — it is what people leave when an app was fine, and alerting on it would make the alerts worth ignoring.

How honest a row is

status	Meaning
verified	Read cleanly. Nothing was uncertain.
warning	Delivered, but something was uncertain — the reason is on the row.
failed	The app could not be read in that storefront. No rating is published, and never a stale one.

Five rules this Actor does not bend:

• A star value that cannot be established is never published. The margin is computed before the claim, not after. Too wide, and you get the count and a warning — never a guessed 1-star, which is the alert nobody forgives.
• Ratings being removed is a removal. Apple withdraws ratings, and counts go down. That is reported as ratings-removed, never folded into arrivals, and no star value is derived across it — the sum lost the stars of reviews this Actor never saw.
• Someone editing their own review is not a new review. An average that moves while the count stands still is a recomputation, and it is reported as one.
• An app with no published average is not an app with no rating. Apple withholds the average below a threshold. You get a warning, not a zero.
• A storefront that yields nothing is a failure, not "no change". A monitor that silently stopped seeing your app would report calm forever, which is the worst thing it could do.
• If the baseline cannot be reached, the run still reports — and says nothing is a change. Rather than failing and showing you nothing, every app is published as a first sighting with a warning on the row and on the run. You get today's ratings; you are never told they moved.

Limits

Limit	Value
Apps per run	100
Countries per run	10
App-and-country checks per run	500
Time per lookup	30 seconds
Time per run	900 seconds
Smallest rating move reported	0.05
Widest margin a star value may carry	0.5

The smallest reported move is 0.05 because the App Store displays one decimal. Below half a displayed step the number moved and your listing did not.

What this deliberately does not do

• No review text, and not by accident. Apple's robots.txt asks crawlers not to read the customer-review feed, and this Actor honours that. Everything it publishes comes from the public lookup endpoint, which no rule there covers. That constraint is why the star value is derived arithmetically instead of scraped — and it is the reason this Actor can run on a schedule forever without a proxy, a login, or a blocked run.
• No Android. The record is built so a Google Play reader could land without changing a published field, but it is not here yet.
• No App Store Connect access, and no credentials of any kind. Public data only, so you can watch competitors as easily as your own apps.
• No discovery: it watches the apps you name.
• No email or SMS. Use Apify's integrations to route a run's dataset wherever you want it.

Pricing

Free. Only Apify's platform usage applies. Two events are defined — app-checked (every read) and reviews-changed (a real move) — and neither is charged today.

They exist so that adding a price later would be a price change and not a redesign.

---

Works well with

Review & Rating Monitor — the same job for your Google Business listings. Most teams that care about a 1-star in the App Store care about one on their storefront too, and the two datasets answer the same morning question.

Website Change Monitor — watch a competitor's release notes or pricing page, so a rating move on your app and a change on theirs land in the same place.

---

FAQ

How does it know what changed? It stores each app's rating, rating count and version — three numbers, per storefront — in a key-value store on your account, and compares the next check against it.

What happens on the first run? Every app is a baseline row: the starting point, not a change. You are never told a rating moved on an app the Actor has not seen before.

Why is newRatingsAverageStars sometimes null? Because your app has too many ratings for Apple's published average to resolve a single new one. The row still tells you how many arrived and how the average moved. This is a property of the arithmetic, not a fault, and the row says so in its warning.

Can it tell me what the review said? No. It tells you one arrived and what it was rated. Take the row as your signal and read the review in App Store Connect or on the listing.

Does watching ten countries cost ten times as much? Yes — each one is a separate check, because each one is a separate answer. Watch the storefronts that matter to you.

Will it tell me twice about the same change? It can, in one case: if the row is published but the baseline cannot be saved. That is the deliberate trade — the alternative is losing the alert silently and forever.

---

Support

Open an issue on the Actor's Apify page. Include the run ID, the app ID and the country code.

Not affiliated with, endorsed by, or sponsored by Apple Inc. App Store is a trademark of Apple Inc.