App Store Reviews Scraper (Apple)

Get customer reviews for any iOS / macOS app from the Apple App Store, for any country storefront, as JSON, CSV or Excel. Each review includes rating, title, text, app version, author and date, plus optional app metadata (name, developer, average rating, rating count) and the full per-star ratings breakdown — how many 1★, 2★, 3★, 4★ and 5★ ratings the app has in that storefront. Pay only per review returned.

Use cases

• Product research and competitor analysis across countries
• Sentiment analysis, feature-request mining, churn reasons
• Monitoring your own app's newest reviews on a schedule
• Feeding reviews into AI agents and dashboards
• Alerting on new reviews only — set watchLabel and schedule it; see Watch mode below
• Alerting on rating reversals — watchEvents: ["scoreChanged"] catches a reviewer editing their own star rating on a review you already have, e.g. a 5★→1★ downgrade after a bad update

Input

Field	Type	Description
apps	array	App Store URLs or numeric app IDs
appNames	array	Free-text app names (e.g. "Notion") — auto-resolved to an app id via Apple's own search API. See caveat below.
includeMacApps	boolean	Also search the Mac App Store when resolving appNames (default false). Apple's app-name search is iOS-only, so Mac-only apps are invisible without it — see below.
countries	array	Storefront codes, e.g. us, gb, de, jp, br (default us)
countryFallback	boolean	If a storefront returns nothing, pull that app's reviews from one that works (default false)
sort	string	mostRecent (default), mostHelpful, or favorable/critical to deliver reviews ordered by star rating (highest/lowest first, newest first within a tied rating) — see FAQ. favorable/critical cannot be combined with watchLabel.
maxReviewsPerApp	integer	Up to 500 per app per country (Apple's documented limit; in practice its feed often stops sooner — the run says so, see FAQ) — counted before the review filters (rating/keyword/length/votes/date), see FAQ
includeAppInfo	boolean	Attach app name, developer, average rating, rating count and the per-star ratingBreakdown (default true)
maxResults	integer	Total cap
minRating / maxRating	integer	Only keep reviews with a star rating in this range (1-5)
keyword	string	Only keep reviews whose title or content contains this word/phrase (case-insensitive)
reviewsAfter	string (ISO date)	Only keep reviews posted on or after this date. Forces sort to mostRecent and stops paging as soon as older reviews are reached, so a narrow window doesn't scan (and isn't charged for) pages you don't want.
reviewsBefore	string (ISO date)	Only keep reviews posted on or before this date, inclusive of that day. Pair it with reviewsAfter for a date range.

A bare date (2026-06-01) in either bound means that whole calendar day as the storefront itself dates it — the same date you read at the start of each review's updatedAt. So reviewsAfter: "2026-06-01" with reviewsBefore: "2026-06-01" returns exactly the reviews stamped 2026-06-01, never one stamped the day before or after. Pass a full timestamp (2026-06-01T12:00:00Z) if you want an exact instant instead. | minReviewLength | integer | Only keep reviews whose body text is at least this many characters — drops one-word "Great!" ratings without discarding a short review that happens to have a long title. | | minVoteSum / minVoteCount | integer | Only keep reviews with at least this many net helpful votes / total helpfulness votes. Requires sort: mostHelpful — see FAQ. | | watchLabel | string | Turns this run into a watch — only reviews posted since the last run under this label are returned and charged. Leave empty for normal runs. | | watchEvents | array | Optional, watch mode only. new and/or scoreChanged — pick scoreChanged alone to be alerted only when an existing reviewer edits their own star rating, and pay for nothing else. Leave empty for both. See Watch mode. | | webhookUrl | string | Optional. An http(s) URL to POST a JSON completion summary to when the run finishes — row counts plus the per-pair completeness records, see FAQ. The same records are always written to the run's RUN_SUMMARY key-value record whether or not you set this. |

Filtering happens before you're charged — you never pay for rows that got filtered out.

Watch mode — only new reviews since the last run

Set watchLabel to any name and this Actor stops re-delivering the same reviews on every scheduled run:

1. First run for a label is a free baseline. It records which reviews already exist for every apps/countries pair — walking as deep as Apple will serve, up to 500 per pair and regardless of maxReviewsPerApp — and returns zero rows — you are charged nothing. Apple's feed often stops well short of 500 (see the FAQ), so a baseline may only cover the newest ~50 reviews of a pair; that is safe, see the next bullet.
2. Every run after that returns only reviews that weren't in the baseline, and adds them to it. Nothing new → zero rows → zero charge.
3. A review older than the baseline could reach is never billed as "new". Each pair also records the oldest review date its baseline walk actually scanned. If Apple's feed serves deeper on a later run than it did at baseline time, the extra older reviews are recognised as pre-existing — not delivered, not charged — and the run says how many. Reviews posted after the baseline are always newer than that date, so real alerts are never suppressed.
4. An already-delivered review whose author edits their own star rating is delivered again, as a scoreChanged event, not silently missed. Apple keeps a review's id stable when the reviewer edits it in place (only the feed's own updated date advances) — so without this, a review your watch already delivered at 5★ could quietly drop to 1★ and you'd never know. Every row carries watchEvent (new or scoreChanged) and, on a scoreChanged row, previousScore (the rating last recorded for it). Use watchEvents to receive only one kind, e.g. ["scoreChanged"] to watch an app you already track elsewhere purely for sentiment reversals. There is no developer-reply field anywhere in this review feed (unlike Google Play), so that isn't an event this Actor can offer.

The baseline lives in your own Apify account, in a named key-value store called fetchsmith-app-store-reviews-watch, keyed by your label plus a fingerprint of apps/appNames/countries/countryFallback/sort and every review filter (minRating/maxRating/keyword/minReviewLength/reviewsAfter/reviewsBefore/minVoteSum/minVoteCount) (Apple's feed takes none of those server-side, so all of them decide what "new" means). Change any of those and you get a fresh baseline rather than a silently wrong one. Delete the record to start over; use different labels to watch several filter sets in parallel.

Details worth knowing:

• Use sort: "mostRecent" (the default). mostHelpful isn't date-ordered, so a brand-new review isn't necessarily inside the scanned window and can be missed; the run logs a warning if you watch with mostHelpful anyway.
• maxReviewsPerApp is your scan-depth budget on incremental runs and is left exactly as you set it — with mostRecent, new reviews sort at the top, so your own cap doesn't hide them. If every matching review inside that window turned out to be new, the run warns you that reviews posted since the last run may sit further back — raise maxReviewsPerApp or run the watch more often.
• If an appNames search resolves to a different app than last time (or a new countries entry appears), that app/country pair is baselined on the spot rather than having its entire review history delivered as "new".
• countryFallback still applies during a watch — a baselined pair whose storefront later goes empty falls back the same way a normal run does.
• Reviews with no id Apple can hand back (rare) are skipped in watch mode, since they can't be recognized on the next run — never charged.
• Change events need one run to warm up. A baseline created before watchEvents existed stores review ids but not the star rating to diff against; the first run after upgrading records that state (and says so in the log), so scoreChanged starts firing from the run after that. New reviews are unaffected.
• Baseline size cap: the saved baseline holds at most 40,000 review ids across all your apps/countries pairs (the oldest drop off first). A watch this large is rare, but if it happens, the dropped ids will be delivered and charged again as "new" on a future run — the run's log and status message name the count when it occurs (RUN_SUMMARY.baselineTruncated/baselineTruncatedTotal). Split a very large watch across several labels (e.g. one per app) to stay under the cap.
• Don't combine a fixed reviewsBefore with watchLabel — see "why has my watch stopped finding anything new" in the FAQ.

appNames caveat, verified live: Apple's search API almost never returns zero results — even keyboard-mash gibberish gets back an unrelated app (measured: nonsense strings matched an Arabic quiz game, an emoji trivia app, etc., every time). A naive "take the first hit" would silently resolve a typo'd name to the wrong app. This Actor only accepts a match that shares a real word with the requested name (in the app's name, developer, or bundle id); otherwise it skips the name with a "no match found" warning instead of guessing. Use a numeric app id or Store URL when you need certainty. Also note: if you pass appNames and leave apps untouched, the Actor deliberately ignores apps's own example default rather than mixing an uninvited app into your results.

Mac App Store apps (includeMacApps), verified live 2026-09-17: Apple's name-search entity for apps is iOS-only. Searching "Final Cut Pro" by name returns Final Cut Camera, iMovie and CapCut — the actual Mac app is never in the list, so before this option a name lookup would quietly hand you a different app. With "includeMacApps": true the Mac App Store is searched too and an exact title match wins over a loose one, so "Final Cut Pro" resolves to id 424389933 and returns its real Mac reviews. Everything after resolution is platform-agnostic: you never needed this option if you pass a numeric id or an apps.apple.com URL — the review feed and the app-metadata lookup are keyed by app id, not by platform, and have always worked for Mac apps. It is off by default so that an existing iOS-only name lookup can't start matching a same-named Mac app.

Output (one item per review)

{
  "reviewId": "14523209599",
  "appId": "1232780281",
  "country": "us",
  "title": "Great for planning",
  "content": "I use it every day for ...",
  "rating": 5,
  "version": "3.42.0",
  "author": "jane_doe",
  "authorUrl": "https://itunes.apple.com/us/reviews/id...",
  "updatedAt": "2026-09-07T16:13:22-07:00",
  "reviewUrl": "https://itunes.apple.com/us/review?id=1232780281&type=Purple%20Software",
  "voteSum": 0,
  "voteCount": 0,
  "appName": "Notion: Notes, Docs, Tasks",
  "developer": "Notion Labs, Incorporated",
  "averageRating": 4.7,
  "ratingCount": 512345,
  "totalRatings": 519312,
  "ratingBreakdown": { "five": 432140, "four": 51220, "three": 15870, "two": 6190, "one": 13892 }
}

Per-star ratings breakdown (ratingBreakdown)

An app's average rating hides the shape of its distribution: 4.5 stars from mostly 5s and a handful of 1s is a very different product story from 4.5 stars from a wall of 4s. Apple's public lookup API only gives you the average and the total, so most App Store review scrapers stop there. This Actor also returns the actual count of ratings at each star level, per storefront, on every row when includeAppInfo is on:

"totalRatings": 29481802,
"ratingBreakdown": { "five": 25284650, "four": 2000235, "three": 696048, "two": 274710, "one": 1226159 }

• Counts are ratings, not reviews — they include the millions of users who tapped a star without writing anything, so totalRatings is far larger than the 500 reviews Apple's feed will hand you.
• The breakdown is per storefront, so countries: ["us", "gb", "de"] gives you three genuinely different distributions to compare.
• It costs nothing extra: it is fetched once per app/storefront alongside the app lookup, and you are only ever charged per review returned.
• It is verified before it is reported — if the numbers don't reconstruct Apple's own published average, the Actor omits the field and logs a warning rather than handing you a distribution that might be inverted.

Useful for a 1★-share trend line over releases, for weighting sentiment against how many silent raters actually sit behind a review, and for competitor comparisons where two apps show the same average.

Pricing

result — charged per review returned, tiered by your Apify account plan from $0.0001 (Free) down to $0.00007 (Gold and up). App lookups, empty pages and errors are free. HTTP-only and fast.

Where this sits in the market. Input schema and pricing verified live 2026-10-02 against each Actor's latest build, not against its Store description. The two busiest App Store review scrapers on the Store, thewolves/appstore-reviews-scraper (2,688 users, re-verified live 2026-10-16) and theagents/appstore-reviews (818 users), both charge a flat $0.0001/review with no start fee — the exact same price and shape we use, so we're at parity with the traction leaders rather than undercutting or overcharging. Everyone else charges meaningfully more once every fee is counted: johnvc/apple-app-store-reviews-api (550 users, re-verified live 2026-10-16) is $0.00125–$0.00144/review tiered plus a $0.0175 one-time setup fee, a $0.00005 Actor-start fee and $0.00001 per dataset row; easyapi/app-store-reviews-scraper (545 users) is $0.00299/review plus a $0.09 Actor-start fee (900x our whole per-review price, charged before a single review is scraped); sourabhbgp/apple-app-store-scraper (199 users, corrected cycle 1805 — was stale at 178) is a flat $0.002/review, 20x ours.

The comparison above is not just the two busiest plus three more — it is every listing in the niche with more users than the smallest one named. A fresh Store sweep, verified 2026-10-02, found four more App Store review scrapers bigger than sourabhbgp's user count at sweep time (178; sourabhbgp has since grown past all four, to 199 — the ordering below reflects sweep time, not today), none of them previously named and none of them cheaper: jdtpnjtp/apple-app-store-scraper (163 users) charges $0.00065/review, 6.5x ours; brilliant_gum/google-play-app-store-scraper (160 users, a combined Google Play + App Store scraper, not App-Store-only) charges $0.006/review, 60x ours — its own README pricing table names this as the Review scraped event; an earlier version of this paragraph quoted $0.004, which is that listing's Search / chart result scraped event, not what a reviews run is charged (fixed 2026-10-03, cycle 1178, same isPrimaryEvent-vs-rival's-own-table class as the westerly_breaker fix in eu-ted-tenders-scraper's README); code-node-tools/app-reviews-scraper (199 users, re-verified 2026-10-18) charges $0.0005/review tiered down to $0.0003 on Gold and up, 3x-5x ours (an earlier version of this paragraph said a flat $0.0005/5x; its live record tiers by account plan, fixed 2026-10-03, cycle 1178); benthepythondev/appstore-reviews-scraper (152 users) charges $0.002/review tiered down to $0.0014 on Diamond, 14x-20x ours at every tier, same ballpark as sourabhbgp. scriptbase/appstore-reviews-scraper (59 users) also ties our exact $0.0001/review rate. No listing found in this sweep, named or not, undercuts our price.

Re-verified live 2026-10-03 (fleet-oldest competitor_audit rotation): all nine rivals named above re-checked with zero price drift. Three more listings surfaced in the same 169-match sweep, all dearer and none previously named: fatihtahta/app-store-global-reviews-scraper (59 users, tied with scriptbase) charges $0.0004/review plus an optional $0.003/1,000-translated-words add-on, 4x ours; powerai/app-store-reviews-scraper-ppr (34 users, 0 new in 30 days) is $0.00499/review tiered to $0.00199 on Gold+, plus a $0.09 Actor-start fee matching easyapi's; nexgendata/ios-app-store-reviews-scraper (32 users) is a flat $0.1/review plus a $0.005 start fee, ~1,000x our rate, the dearest listing found in this niche.

Correction, re-verified live 2026-10-03 (cycle 1178): we are no longer the cheapest listing in this niche. The fleet-oldest competitor_audit rotation came back around to this Actor and re-verified all twelve rivals named above with zero price drift, but reading five more listings just below nexgendata/ios-app-store-reviews-scraper's 32 users found two genuine price threats this README's earlier "no listing found in this sweep, named or not, undercuts our price" line (just above) no longer covers: apihq/app-store-reviews-scraper (28 users) charges a flat $0.00008/review with no start fee — 20% below our $0.0001, at every volume, with no crossover; automation-lab/apple-app-store-reviews-scraper (27 users) tiers its review price by the buyer's own Apify plan, $0.0001725 (Free) down to $0.000042 (Diamond) — dearer than us on Free/Bronze/Silver (1.2x-1.7x our rate) but cheaper from Gold up ($0.00009 Gold, $0.00006 Platinum, $0.000042 Diamond — 0.9x, 0.6x and 0.42x ours). Three more, all dearer, checked for completeness: seemuapps/apple-app-store-reviews-scraper (31 users) $0.0025/review flat, 25x ours; scrapesmith/apple-app-store-reviews-scraper (26 users) $0.00045/review plus a $0.01 one-time start fee, 4.5x ours on the per-review rate alone; memo23/app-store-scraper (25 users) $0.001/review (10x ours) plus three optional paid add-ons — review-insights ($0.02/call), pain-point-analysis ($0.05/call) and detail-enrichment ($0.001/call) — that read like AI analysis but are not independently verified as model calls; none of our review rows carry an equivalent field. All five prices read live 2026-10-03.

Widened sweep, verified live 2026-10-04 (cycle 1204). Every sweep of this niche before today searched and matched on the spaced phrase "app store reviews", which is three contiguous words — but this niche's single most common self-title is "AppStore Reviews Scraper", one word, so a whole class of listings was invisible to our own search by construction. Re-running the sweep with the no-space and "iOS app reviews" phrasings added (548 listings seen, 186 matching) surfaced eight listings no prior sweep here could see. Two of them are real App Store review scrapers, both read live today and neither undercuts us: fetchcraftlabs/apple-appstore-reviews-scraper (62 users), which is the niche's 8th-biggest listing and had never been named in this README, charges a flat $0.001/review — 10x ours — plus a $0.00005 Actor-start fee; freshactors/app-store-scraper (21 users) charges $0.0001/review flat, exactly our rate, so it is a third parity listing alongside thewolves/theagents/scriptbase rather than a price threat (its app-details and keyword-search events are separately tiered, $0.002→$0.0008 and $0.001→$0.0004 by account plan; a reviews-only run pays neither, and neither do our runs). The remaining six were read and ruled out as non-substitutes, not competitors: maximedupre/app-store-ratings-scraper ($0.00015/row plus a $0.001 start fee) returns an app's aggregate star rating and metadata with no review text at all, and zinin/tinder-app-intel, zinin/bumble-app-intel, zinin/hinge-app-intel and zinin/badoo-app-intel (2 users each, $0.005/storefront snapshot plus a $0.005 start fee) sell per-country subscription prices and store ratings for one named dating app apiece. The cycle-1178 correction above still stands unchanged: apihq at $0.00008 flat, and automation-lab from Gold up, remain the only listings in this niche — across all 186 now visible — that charge less per review than we do.

Correction, verified live 2026-10-04 (cycle 1229): that is no longer the complete undercutter list. The fleet-oldest competitor_audit rotation re-swept this niche with the no-space/iOS phrasings too (549 seen, 188 matched) and live-priced every unnamed App-Store-scope listing with 3+ users. riadh_chebbi/apple-app-store-reviews-scraper (1 user today, 3 when that sweep ran) charges a flat $0.00005/review with no start fee — half our $0.0001 rate, at every volume, with no crossover — at the time the cheapest listing found in this niche (no longer: see the 2026-10-05 correction below, where silentflow prices lower per review and steadyscrape matches this rate with no fee either). tagadanar/apple-app-store-reviews (6 users) tiers its review price by the buyer's own Apify plan, $0.0001 (Free) down to $0.00007 (Gold/Platinum/Diamond), plus a flat $0.001 per-run fee this Actor does not charge: that fee makes it dearer than us below roughly 50-100 reviews/run on Bronze/Silver and below roughly 34 reviews/run on Gold+, but cheaper above those volumes since its per-review rate undercuts ours from Bronze up. One more listing ties our exact rate rather than beating it: scrapersdelight/appstore-reviews-scraper charges flat $0.0001/review with no start fee, a fourth parity listing alongside thewolves/theagents/scriptbase/freshactors. bikram07/app-store-reviews is listed FREE (Apify's free-pricing-model flag, not a $0/review PPE rate) but has had zero runs in the last 30 days, so it is read as dormant rather than an active price threat. Six more unnamed listings read at 3+ users in this sweep were ruled out as different-shape, not App-Store-review competitors (an earlier version of this sentence said "ten" and then named six, and said "five" Shopify listings and then named four — counts corrected and every exclusion re-verified against the listing's own live description, not its title, 2026-10-05, cycle 1264): four scrape Shopify's own app-marketplace reviews (fetch_cat/shopify-app-reviews-scraper, automation-lab/shopify-app-store-reviews-scraper, taroyamada/shopify-app-store-review-intelligence, philzx/shopify-app-intelligence), one scrapes Google Play (obsidian937/google-play-reviews-scraper), and one scrapes Tencent's Android app store 应用宝 (reviewbot/tencent-app-store-review-scraper) — all three are different source sites entirely, not Apple's App Store. The remaining dearer-and-ruled-in listings (fetch_cat/apple-app-store-reviews-scraper $0.000575→$0.00014 tiered plus a $0.005 start fee; shahidirfan/App-Store-Reviews-Scraper $0.00099 flat plus a $0.0005 start fee; kestrel/app-store-reviews-scraper $0.004 flat; bovi/appstore-reviews $0.001→$0.00095 tiered plus a tiered start fee; goat255/app-store-reviews-scraper $0.00115→$0.001 tiered; sync-network/apple-app-store-reviews-scraper $0.001 flat plus a $0.00005 start fee; skootle/app-store-reviews $0.008→$0.005 tiered plus a $0.01 start fee; hipersoft/appstore-reviews-scraper $0.0005 flat plus a $0.00005 start fee; darknezz/app-store-reviews-scraper $0.002 flat plus a $0.01 start fee) are all dearer than us at every tier and do not change the standings above.

Correction, verified live 2026-10-05 (cycle 1264): this niche's price floor is now well below us, and every "only listings that undercut us" claim above is superseded. Sweeps of this niche have always live-priced the unnamed listings with 3 or more users, on the reasoning that Apify pins a brand-new listing at 2 users so a 3-user floor is the cheapest honest cut. Today's sweep (553 seen, 190 matched, 148 of them unnamed here) returned exactly one unnamed listing at 3+ users — santhej/app-store-reviews-scraper (3 users), flat $0.0001/review, our exact rate, plus a $0.001 Actor-start fee we do not charge, so dearer than us below ~10 reviews/run and at parity above. By the standing rule this niche was clean. It is not. Live-pricing the entire 148-listing unnamed cohort including the 2-user floor — 148 GET /v2/acts calls, read-only, ~2 minutes — found 23 listings that charge less per review than our $0.0001, 20 that tie it, 96 dearer, 3 on Apify's FREE pricing model (no price record at all, i.e. $0 — the cheapest price a rival can have) and 6 that bill per app or per scan rather than per review, so no per-review comparison is possible. None of the 23 had ever been named here, and all 23 were confirmed to be Apple App Store review scrapers from their own live descriptions, not their titles. The lesson is structural: a 2-user listing is not a weak competitor, it is a new one, and a niche being actively flooded with new listings undercutting the incumbent rate is invisible to any user-count floor at all.

Cheaper than us at every volume, no start fee (all verified 2026-10-05): steadyscrape/app-store-reviews-scraper flat $0.00005/review (ties riadh_chebbi as the cheapest no-fee listing in this niche); peerless_columbine/apple-app-store-reviews-scraper-api $0.00008 (Free) → $0.00005 (Gold+); axiomworks/review-firehose $0.00008 → $0.000056 (Gold+).

snow_leo_data/app-store-scraper removed from this list — forecast landed, re-verified live 2026-10-16: its scheduled 2026-10-05 12:00 UTC pricing entry is now in effect, and it raised the rate from flat $0.00008 to flat $0.0003 at every tier, 3-4.3x dearer than us (our range is $0.0001 Free down to $0.00007 Gold+). It is no longer an undercutter anywhere; the standing lesson holds — a future-dated entry is a risk to re-check, not a price to carry forward unverified.

Cheaper per review with an Actor-start fee, so the crossover volume is what matters (ours has no start fee; the figure is the run size above which the rival wins; all rates verified 2026-10-05): ninhothedev/app-store-reviews-scraper $0.00008 + $0.00005 start (~3 reviews); automationnation/app-store-reviews-scraper $0.00008 → $0.00005 (Gold+) + $0.00005 start (~3); soilair/app-store-reviews-api $0.00008 → $0.00005 (Gold+) + $0.00005 start (~3); scrapesignal_labs/apple-app-store-reviews-scraper $0.00008 + $0.00005 start (~3); thenetaji/apple-app-store-reviews-scraper $0.00008 → $0.000056 (Diamond) + $0.00005 start (~3); cirkit/app-store-reviews-scraper $0.00007 + $0.00005 start (~2); betterscrapers/the-better-app-store-reviews-scraper $0.00009 → $0.00008 (Gold+) + $0.00005 start (~5); zenomastro/apple-app-store-reviews-pro $0.00008 → $0.000064 (Gold+) + $0.0001 start (~5); getanyapi/app-store-reviews-scraper $0.000152 (Free, dearer than us) → $0.000076 (Bronze+) + $0.00005 start (~3 on Bronze and up only); superslowsloth/app-store-reviews-scraper $0.00007 + a $0.002 start fee (~67); silentflow/apple-reviews-scraper $0.00004 → $0.000034 (Gold+) — the lowest per-review rate in the niche — plus a $0.005 start fee (~83 on Free, ~76 on Gold+); luminar/app-store-reviews-change-monitor $0.000075 plus $0.005 per monitored scan; grokbob/app-reviews-dual-batch-ppe $0.00007 + a $0.01 start fee (~333); automly/appstore-reviews-scraper $0.000095 + a $0.01 start fee (~2,000).

Cheaper only from the Gold account plan up, dearer below it (verified 2026-10-05): lightmoon/apple-app-store-reviews-scraper $0.0007 (Free/Bronze) → $0.00009 (Gold+) + $0.00005 start; tidytools/apple-app-store-reviews $0.0001 (Free/Bronze) → $0.00008 (Gold+), its app-details and app-insights events billed separately. A second hipersoft listing, hipersoft/app-store-reviews-scraper (distinct from the hipersoft/appstore-reviews-scraper named above), is $0.0002 → $0.0001 (Gold+) + $0.00005 start — dearer below Gold and at parity above, not an undercut.

Lowest headline rates in the niche (verified 2026-10-05), all three bundling paid analysis events a reviews-only run here never incurs: datasignalslab/app-store-review-intelligence $0.00001/row but $0.02 per app analyzed + $0.00005 start (1 app × 1,000 reviews ≈ $0.030 against our $0.100); pappy-dev/appstore-reviews-v2 $0.00005/row with five optional $0.05 analysis events; listless_adzuki/app-store-review-scraper $0.00001 per dataset item alongside a separate $0.004 review-result event, so which event a reviews run actually bills is not determinable from the pricing record alone — read as cheap-but-unverified rather than counted above.

Three of the unnamed listings carry no price record at all (verified 2026-10-05) — Apify's FREE pricing model, which means $0 per review and therefore the lowest possible price in the niche, not missing data: convertfleetdotonline/app-store-reviews-scraper and conversational_kermis/pulse-appstore (which searches the App Store by keyword and then exports the matching apps' reviews) are straight App Store review scrapers, and creative_maitake/app-store-review-pain-miner mines low-star reviews into scored pain points. All three sit at Apify's 2-user floor with no runs recorded in the last 30 days, the same dormancy read applied to bikram07/app-store-reviews above, so they are listed as real $0 price points rather than as live demand we are losing to.

Full 0-2-user tail resweep, verified live 2026-10-07 (cycle 1350, fleet-oldest competitor_audit rotation). This niche is new-listing-heavy enough that re-running the full unnamed cohort two days after the 2026-10-05 sweep above was not redundant — a fresh pass over the same 122-listing tail (no top-N cut) turned up two more undercutters. Getting there required fixing the sweep script itself first: Apify represents a tiered price two different ways across listings — a flat number, or the same number one level deeper as {"tieredEventPriceUsd": N} — and the first pass of this cycle's tool silently read the second shape as "no tiers," which would have hidden both findings below. Both survivors were read against their own current pricing record, never a one-time or secondary event, and neither is named with an exact user count (both are small, recently-launched listings — see the note above about why): axiomworks/app-store-reviews-scraper is a second listing by the already-named axiomworks/review-firehose's owner, tiered identically — $0.00008 (Free) → $0.000056 (Gold+), no start fee, cheaper than us at every tier; deriverge/app-store-reviews-scraper ties our $0.0001 on Free but undercuts from Bronze up ($0.00008 → $0.00005), also with no start fee. One listing was read and ruled out of scope on its own description, not its title: digital_influx/marketing-research-mcp is a generic MCP tool bundling SEO audits, DNS/contact lookups, podcast and Bluesky data alongside App Store reviews as one of a dozen unrelated capabilities — a different product shape from a dedicated review-export Actor, not a substitute for a buyer who wants a reviews dataset. Five more listings the script flagged AMBIGUOUS (two or more non-one-time events, neither flagged primary) were hand-read against their eventTitle and own description and all tie or lose to our rate: cybermax/app-reviews, openkrill/app-store-play-reviews, unicentrocucuta/appstore-watch (all tie at $0.0001), dodge_bot/app-store-reviews ($0.0002), datalantern/app-store-reviews ($0.0003). Everything else in the fresh tail was dearer, FREE-model, or dormant, already covered by the dormancy read above.

Second full-tail resweep the same day, verified live 2026-10-07 ~23:30 UTC (cycle 1388). The cycle-1350 pass above ran earlier on 2026-10-07; re-pricing the identical 122-listing unnamed tail hours later turned up four more undercutters, none previously named, and three of them had cut their price that same day — which is the sharpest evidence yet for the "new-listing-heavy niche" read above: in this niche a sweep's price findings can go stale inside one day, so the date on each block below is a timestamp, not a season. All four were read against their own currently-effective pricing record, and in each case the per-review charge (not a one-time or secondary event) was the figure compared:

• myagizm/appstore-reviews-scraper — flat $0.00008 per dataset row, every tier, no start fee, 20% under our $0.0001. This one is not explained by a price change: its pricing entry dates to 2026-09-29 and so was already live during cycle 1350's pass, which means that pass missed it. Its unit is Apify's generic apify-default-dataset-item rather than a named review event, so the rate is per row emitted; its description scopes the Actor to written App Store reviews, so row and review should coincide, but we have not run it to confirm one row per review.
• om_kh/appstore-reviews-api — tiered $0.0001 (Free, our exact rate) → $0.000085 (Bronze) → $0.00007 (Silver) → $0.000055 (Gold+), no start fee. It cut its price roughly 8x on 2026-10-07 at 13:23 UTC, from $0.0008 (Free) → $0.00044 (Gold+); cycle 1350's pass reading it as dearer than us was correct at the time. So: parity on Free, a real undercut from Bronze down.
• dropin-apis/app-store-reviews — $0.00008 per dataset row plus a $0.00005 Actor-start fee, also cut that same day (2026-10-07 17:42 UTC, from $0.0002/row). With a start fee the crossover is what matters, and here it is tiny: it costs less than us above about 3 rows per run, so treat it as a genuine undercutter at any realistic volume.
• northbell/app-store-reviews-scraper — listed 2026-10-07 02:24 UTC, tiered $0.0001 (Free and Bronze, our exact rate) → $0.00009 (Silver) → $0.00008 (Gold+), but carrying a $0.01 Actor-start fee, which inverts the comparison at low volume. Crossovers against our flat $0.0001 with no fee: ~500 reviews per run on Gold+, ~1,000 on Silver, and never on Free or Bronze (it ties our per-review rate there, so the $0.01 fee leaves it strictly dearer at every volume). A conditional undercut for high-volume Gold+ buyers only, not an across-the-board one.

The only future-dated price change anywhere in the 122-listing tail was vonsensey/app-store-reviews-all-countries-scraper-api, cutting its review event $0.004 → $0.002 (Gold+) effective 2026-10-09. Forecast landed, re-verified live 2026-10-16: the cut is in effect exactly as projected ($0.002 Gold/Platinum/Diamond, $0.004 Free) — still 29-40x our rate, so it was not an undercutter before or after that date. Of the rest of the tail, 15 listings tie our $0.0001 exactly at every tier, two are one-time/report-fee products with no per-review rate at all (second_coming/app-store-review-analyzer $0.02 per scan run, muhammadafzal/apple-app-store-review-intelligence $0.016-$0.02 per report plus a $0.005-$0.00625 start fee — a per-report shape, not a per-review substitute), and the remainder are dearer. Nothing in this pass was ruled out on its title.

Third full-tail resweep, verified live 2026-10-08 ~15:45 UTC (cycle 1420, fleet-oldest competitor_audit rotation). Same method as the two passes above, no top-N cut: 560 listings seen across the niche's search terms, 201 matched, 87 already named here, and all 117 unnamed ones live-priced (0 unresolvable, 0 ambiguous). Result: 16 tie our $0.0001/review exactly, 100 are dearer, and exactly one undercuts us —

• tinyrex/app-store-reviews-scraper undercut us here at the time (flat $0.00008/review, 20% under our $0.0001, behind a $0.00005 Actor-start fee) but is gone from the Store as of 2026-10-09 — GET /v2/acts/tinyrex~app-store-reviews-scraper now 404s (record-or-token-not-found), a removal rather than a rename or ownership change, confirmed by the API itself. A fresh full-tail resweep is still owed to find whatever the current cheapest listing is; this retracts the specific undercutter without claiming "0 undercut us" in its place.

That listing is not a miss by the earlier passes: it was created 2026-10-07 23:42 UTC and priced one minute later, roughly twelve minutes after cycle 1388's sweep finished. It is the cleanest datum yet for the "new-listing-heavy niche" read above — this niche can add an undercutter inside the gap between two sweeps on the same evening, so every price figure in this README should be read against the timestamp on its own block. No listing anywhere in the 117 carries a future-dated price change this time, none is on Apify's FREE model, and none is a pure per-run-fee product with no per-review rate at all. (The one future-dated cut named above, vonsensey/app-store-reviews-all-countries-scraper-api $0.004 → $0.002 effective 2026-10-09, is a named listing and so sits outside this unnamed-cohort sweep; re-verified live 2026-10-16, it has landed exactly as projected and remains ~29x our Gold+ rate.)

Fourth full-tail resweep, verified live 2026-10-09 ~03:00 UTC (cycle 1443), pulled forward out of strict rotation order specifically to close the retraction above. Same method again: 561 listings seen, 200 matched (vs 201 at 1420 — one net listing fewer, consistent with churn in a niche this new-listing-heavy rather than a count regression), 84 already named here, and all 116 unnamed ones live-priced (0 unresolvable, 1 ambiguous). Result: 5 tie our $0.0001/review exactly, 110 are dearer, and tinyrex's vacancy was not backfilled — 0 of the 116 undercut us. The one ambiguous listing, transparent_meteorite/app-store-reviews, has two recurring per-row events with neither flagged primary (review-returned and app-details both $0.0005+/row, title line advertises "$0.50/1k" i.e. $0.0005/review) — dearer than us 5x over under either reading, so the ambiguity doesn't change the verdict. This sweep only re-prices the unnamed tail, same as the three before it — the named undercutters already disclosed above (deriverge/app-store-reviews-scraper, silentflow, riadh_chebbi, and the cycle-1264/1300 cohort) were not re-verified this cycle and stand as last priced; this paragraph retracts tinyrex without claiming the niche's price floor as a whole has moved. Read every figure in this README against its own timestamp — this niche added and priced a new undercutter within 12 minutes of the previous sweep (tinyrex, cycle 1420).

This pass also put an exact number on the two per-report listings named above, which no earlier block quantified because a flat per-run fee has no per-review rate to compare: a whole run of second_coming/app-store-review-analyzer costs $0.02 (one scan event, billed at most once per run), and one of muhammadafzal/apple-app-store-review-intelligence costs $0.016–$0.02 per report plus a $0.005–$0.00625 start fee. Against our flat $0.0001/review with no fee, those break even at about 200 reviews and ~262 reviews (Free plan) respectively — so on a large export they are cheaper, and on a small one dearer. We still read them as a different product (a scored report, not a reviews dataset you can join and re-query), but the honest figure is a crossover, not "no comparison is possible".

Fifth full-tail resweep, verified live 2026-10-16 ~03:00 UTC (cycle 1779, fleet-oldest competitor_audit rotation, 336 cycles / 7 days after cycle 1443). This niche's growth has not slowed: three search phrasings ("app store reviews", "appstore reviews", "ios app reviews") now return 859 unique listings (up from 561 at cycle 1443), of which 403 title-match this niche (contain "review" plus "app store"/"ios"/"apple" in the title) versus 200 at cycle 1443 — roughly double in 7 days, the sharpest growth this rotation has measured. 78 of those are already named in this README; 325 are unnamed, and 401 Google Play/App-Store-dual listings swelled the description-only match further (excluded here — this section counts the title-strict set). Live-pricing the full 325-listing unnamed tail is now too large for one audit cycle (prior full-tail passes topped out at 148); this pass live-priced the 18 unnamed listings with 5+ users (the ones with enough traction to matter before the next rotation) and found exactly one real, previously-unnamed competitor at or below our rate:

• reviewbot/apple-review-scraper (43 users) — flat $0.0001/review, our exact rate, but the first 10 reviews per run are free, which we do not offer. A pure Apple App Store review scraper (no Google Play bundling), so it is a genuine substitute, not a different-shape exclusion. Crossover: strictly cheaper than us on any run of ≤10 reviews, exact parity above that — a fifth parity listing by rate, the first with a free tier attached.

The other 17 were read against their own live pricing (verified live 2026-10-16) and ruled out, all for reasons already established above (dearer, or a different product shape than a per-review export): andok/app-store-reviews (10x–7x dearer even at Diamond, dual-store), logiover/app-store-data-api and logiover/app-reviews-scraper (10x–17x dearer, dual-store/ASO-bundled), focused_vanguard/appstore-reviews-scraper (35–40x dearer), haketa/app-store-scraper (20–25x dearer, bundles top-chart rankings), cleanscrape/app-store-reviews-scraper (2x dearer plus a start fee), rupom888/appstore-ios-scraper (20x dearer flat), native_emblem/app-reviews-scraper (1.5x dearer flat, dual-store), berkaydev/app-store-google-play-reviews-scraper (3x dearer), scrapemint/app-review-intelligence ($0.002/row, 20x dearer); and five read as a different product shape, same exclusion rule as maximedupre/sourabhbgp above — priced per app record with reviews as a bundled sub-field, not per review: johnvc/apple-app-store-product-api ($0.00008 Free → $0.00006 Gold+ per app, "sample reviews" bundled), sian.agency/apple-app-store-scraper (per-app overview/detail events, reviews bundled into the detail price), dami_studio/app-store-scraper ($0.00009/app row), renzomacar/app-store-scraper (reviews-batch priced per batch, not per row — ambiguous, no clean per-review figure), plus the two Shopify-App-Store listings in the same cohort (freshactors/shopify-app-store-scraper, devsef/shopify-app-store-scraper — wrong store entirely, same exclusion as the Shopify listings named earlier in this section).

Open item, not closed by this pass: the remaining ~307 unnamed listings at 1-4 users are untouched — per the cycle-1264 lesson above ("a 2-user listing is a new one, not a weak one"), a future competitor_audit cycle should live-price that tail with a dedicated batch script (one GET per listing, ~5 min of API calls) rather than by hand; 325 is too many for manual per-listing reading in one cycle. The one confirmed finding above is already shipped.

Unnamed-tail sweep closed, verified live 2026-10-16 ~03:40 UTC (cycle 1780). The open item above is now done: all 175 unnamed title-matching listings were live-priced in one batch (GET /v2/acts/<handle> each, 0 unresolvable). Our own rate was re-read live at the same time and is unchanged: flat $0.0001 per review result, one price on every account plan, no start fee. Twelve of the 175 undercut that on at least one plan tier, plus two more found by hand-reading the five listings whose event set was too ambiguous for the batch script. The honest summary is that our $0.0001 is no longer close to this niche's floor — the floor is now $0.00005–$0.00008.

Cheaper than us at every account plan with no start fee (strictly cheaper at any run size):

• lergassy/app-store-reviews-scraper (2 users, re-verified 2026-10-19) — $0.00008 (Free) → $0.000072 (Bronze) → $0.000064 (Silver) → $0.000056 (Gold+) per review, no fee: 20% to 44% cheaper than us at every volume. A pure per-review App Store export with country and star filters, i.e. a direct substitute on features as well as price. The cheapest unconditional rate in this niche to date.
• workstream/app-store-reviews-scraper (2 users) — flat $0.00008/review, no fee, one price on every plan: a straight 20% under us at every volume.
• hiver/app-reviews-scraper — $0.00009 (Free/Bronze) → $0.00008 (Gold+), no fee: 10–20% under us. Bundles Google Play, but prices the App Store review row per review, so unlike the per-app listings excluded above it is a genuine substitute.
• almmity/app-store-reviews-official-feed (2 users) — $0.00009/row, no fee (10% under us), but its own title caps it at ~1,000 reviews per country; we do not cap, so it only beats us inside that ceiling.
• gh0st1k/app-store-reviews-scraper (1 user) — no price record at all (so currently free), and claims "All 175 Countries, No 500 Cap". Same caveat as the three no-record listings named in the 2026-10-05 block: an unpriced new listing usually means pricing not yet set, not a free product, so re-read it rather than treating free as settled.

Cheaper than us above a crossover, verified live 2026-10-16 (they carry a start or per-app fee; the figure is the run size above which the rival wins, computed against our flat $0.0001):

• wintersworks/appstore-reviews-scraper (2 users) — $0.00008/review + $0.001/app-details: wins above ~50 reviews, i.e. on essentially every real export.
• cheapapi/app-store-google-play-scraper (3 users) — $0.00009/review + $0.003/app-details (and a $0.0005 per-request minimum top-up): wins above ~300 reviews.
• tactful_anvil/app-store-reviews-scraper-multi-country-deep-history (2 users) — $0.00008 (Free) → $0.000056 (Gold+) + $0.01 start fee: wins above ~500 reviews on the Free plan, sooner on paid plans.

Cheaper for any paying customer, parity on the Free plan (they tier by account plan, we do not — the same asymmetry first noted in the 2026-10-05 block; most buyers are not on the Free plan):

• cleanfeed/app-store-reviews-scraper (1 user) — $0.0001 (Free) → $0.000048 (Gold+), no fee. Half our rate for a Gold customer, and the joint-lowest rate in the niche.
• plainrows/app-store-reviews-scraper and plainrows/app-reviews-scraper (2 users each) — $0.0001 (Free) → $0.00005 (Gold+), $0.002 start fee.
• webdatatools/app-store-reviews-scraper (2 users) — $0.0001 (Free) → $0.00006 (Gold+), $0.00005 start fee.
• euroscrape/app-reviews (2 users) — $0.0001 (Free) → $0.00007 (Gold+), $0.003 start fee.

Ruled out from the same batch, verified live 2026-10-16: bikram07/competitor-teardown (FREE model, but a battle-card analysis product, not a review export — the different-product-shape exclusion), and three of the five hand-read ambiguous listings, all dearer — pushbuild/app-store-reviews ($0.0005/review, 5x dearer), contented_catwalk/app-store-reviews-monitor and .../google-play-reviews-monitor ($0.00015/review plus $0.005/run). The other 160 priced at or above our rate.

Why this tail had been invisible, and what it invalidates. The sweep was only possible because cycle 1780 fixed a 10x truncation in bin/niche-size and bin/niche-unnamed: both asked /v2/store?search=... for limit=100 when that endpoint reports total in the thousands and serves up to ~1000 hits in a single call. On this niche the same query set returned 577 distinct listings / 227 title-matched at limit=100 versus 1702 / 259 at limit=1000 — so every audit those two tools have ever backed, in this niche and fleet-wide, was drawn from roughly a tenth of the matchable Store. The counts in the earlier dated blocks above are therefore floors, not totals; the rivals they name were real and were priced live, but "complete tail" claims in them should be read as "complete within a truncated sample".

What this means honestly, as of the 2026-10-05 sweep: we are no longer near the bottom of this niche on price. Our $0.0001/review is now the modal rate — 20 listings tie it exactly — with roughly two dozen listings priced under it, most of them launched recently, and a cluster of them at $0.00005 or below. What this Actor still offers over the cheap end is the per-storefront ratings histogram verified against Apple's own published average (below), no Actor-start fee at any volume, and a record of these comparisons being re-verified against live pricing records rather than Store copy.

Two honest qualifications, both read off live input schemas rather than listings:

• sourabhbgp does expose a per-star ratings histogram — includeRatingsHistogram, on by default, in its app-details mode. What it does not do is attach it to reviews: modes are mutually exclusive, so a buyer who wants reviews and the distribution together pays for two runs and joins them. Here the breakdown rides along with the reviews in the same run, per storefront, for no extra charge, and is dropped if it fails to reconstruct Apple's published average.
• sourabhbgp also claims review depth past Apple's RSS 500-cap (schema verified 2026-10-01; it allows maxReviewsPerApp up to 100,000 and says it reads Apple's catalog endpoint, which we have not independently verified). If that holds it is a genuine depth advantage over this Actor, which is bounded by the RSS feed's hard 500/app/storefront ceiling and says so plainly throughout. Its own schema notes the trade: that endpoint "ignores both" sort orders and returns relevance order, so a date-ordered or mostHelpful pull is not what you get.

On the rest, all five schemas are clean (verified 2026-10-01): none has any watch/incremental input at all (no watchLabel-equivalent, no state key, no rating-edit diffing — theagents' until and sourabhbgp's sinceDate are one-shot date cutoffs, not baselines), and none exposes storefront-fallback or empty-page recovery (sourabhbgp's availability-matrix probes whether an app exists in a storefront, 200 vs 404 — not whether that storefront has reviews, and it does not re-route a reviews run).

One input the others have that this Actor does not (schema verified live 2026-10-01): johnvc's start_page offset. Its sort enum also offers mostfavorable/mostcritical, which this Actor matches as favorable/critical — but note those are not real Apple feed orders: probed live 2026-09-26 against itunes.apple.com/<cc>/rss/customerreviews/.../sortBy=<X>/, only mostRecent and mostHelpful return entries at all, and mostFavorable/mostCritical come back as an empty feed. This Actor therefore scans under mostRecent and re-orders by star rating itself; a scraper that passes those values straight through to the RSS feed gets nothing back.

Pricing decision, verified and shipped live 2026-10-16 (cycle 1781): moved from flat $0.0001/review to account-plan tiering, $0.0001 (Free) → $0.00009 (Bronze) → $0.00008 (Silver) → $0.00007 (Gold and up). The sweep above (cycle 1780) established that flat $0.0001 is no longer competitive: 14 unnamed rivals undercut it on at least one tier, the niche floor is $0.00005–$0.00008, and two no-fee listings (lergassy, workstream) beat it at every volume on every plan. A flat cut to match the floor was rejected — racing a handful of 2-user listings that may be abandoned to $0.00005 is not obviously winnable with 45 users and $0 revenue fleet-wide, and flattens the margin on every run regardless of who is paying. Tiering by account plan is the fix that was actually missing: every serious named rival in this niche tiers by plan and this Actor did not, which meant we were the dearest option for every buyer who had ever paid Apify a cent, even while quoting a rate that looked competitive to a Free-tier shopper. The new tiers keep the Free-tier rate unchanged (still ties the historical volume leaders thewolves/theagents), and make every paying tier cheaper than the old flat rate — Silver ties workstream's unconditional $0.00008, and Gold+ sits one tick above lergassy's $0.000056 Gold+ rate rather than matching it exactly, since lergassy has 2 users (re-verified 2026-10-19) and no track record and losing 0.000014/review to the single cheapest listing in a crowded niche is a reasonable price for not having raced to the bottom. Platform finding, not previously documented: Apify's tiered-pricing API silently collapses GOLD/PLATINUM/DIAMOND to one value — a publish that set PLATINUM to $0.00006 and DIAMOND to $0.000056 came back live with both read as $0.00007, identical to GOLD. Checked three other already-tiered fleet Actors (hacker-news-scraper, fda-recall-scraper, ats-jobs-scraper): all three already have GOLD = PLATINUM = DIAMOND, so this is an existing platform ceiling the fleet had already converged on by convention, not a new regression — filed in LEARNINGS so a future cycle doesn't waste a publish call trying to separate those three tiers again. apify-admin publish + bin/sync-apify-prices both re-verified clean against this live record; registry.json's apify_price now reads {shape: tiered, entry: 0.0001, floor: 0.00007}.

Never silently returns an empty result

Apple's public review feed is full of holes. For one app in one storefront, page 1 can be empty while pages 2 and 7 return a full 50 reviews each; an app can be completely empty under mostRecent and have hundreds under mostHelpful; and coverage differs per storefront. Most scrapers stop at the first empty page and hand you an empty dataset with a green "succeeded" run. This one:

• scans Apple's entire page range and skips over the empty pages instead of treating the first one as the end of the reviews;

• if the sort order you asked for is empty, retries under the other sort order — same review pool, and every row records which one it came from in sortUsed;

• re-requests an empty page as a different client before believing it. Whether a page comes back empty depends on what your HTTP client looks like to Apple: measured on 2026-09-10, Notion/us mostRecent page 4 returned nothing to a plain curl request in 4 out of 4 interleaved rounds while a browser and an iPhone client both got a full 50 — the same 50. Each recovered page is 50 reviews a single-client scrape silently drops, and the retry only costs a request when a page is actually empty. Rows carry clientClass so you can see which client served them;

• when a storefront really is empty, probes other storefronts and tells you which ones have reviews for that app;

• with countryFallback: true, fetches from a working storefront automatically — rows keep the real country plus requestedCountry and fallbackUsed: true, so nothing is mislabelled;

• sets a run status message explaining why a run returned few or no rows (empty Apple feed vs. your own rating/keyword filters vs. a storefront Apple refused);

• separates "Apple has no reviews here" from "Apple refused this request". A storefront code that is well-formed but isn't a real Apple store answers every request with HTTP 400; that pair ends on its first refusal rather than paging on, the message says what Apple actually returned, and if every pair in the run was refused the run fails instead of reporting an empty result. In watch mode a refused pair is deliberately left out of the baseline, so a broken storefront can never be silently recorded as "already delivered";

• retries connection-level failures up to 3 times before believing them. A dropped connection is not an answer, but got's own retry list doesn't cover the HTTP/2 connection faults measured at roughly 1 fresh connection in 4 across this fleet (2026-09-21), so one blip used to end an app's scan or quietly return ratingBreakdown: null. Every review-feed, lookup, search and ratings-page request now retries with backoff first. A real HTTP error from Apple (a wrong storefront code) still fails immediately with the explanation instead of looping;

• fails loudly instead of returning a misleading empty result when the fault is Apple's, not yours. Apple sometimes serves an empty feed for everything — measured 2026-09-16: every app, storefront, page, sort and client came back HTTP 200 with zero entries. From one app's response that is indistinguishable from "this app has no reviews", so when a run ends up with no reviews at all we re-check two control apps that always have hundreds of thousands of reviews (three attempts, spaced). If those are empty too, the run fails with a message naming the Apple-side fault, rather than telling you no reviews matched your filters. A watch-mode baseline is never written from such a run either — otherwise the next run would treat the app's whole review history as "new" and charge you for it.

• says all of that in a form a program can read, not just in English. Every run writes a RUN_SUMMARY record to its key-value store with one entry per app/storefront pair: how many reviews were scanned, how many delivered, how many your filters removed, how many ratings Apple declares the app has (declaredRatingCount), and a complete flag with the reason that made it false. A status message is for a human reading the run page; this is for the pipeline that never reads it (see FAQ).

You are never charged for empty pages, for retries, or for a run that fails this way.

FAQ

Can I be alerted when someone edits a review I already downloaded? Yes — that is what watchEvents is for. Apple lets a reviewer rewrite their own review (same review id, new star rating, only the feed's own updated date advances) — there is no "new review" event to catch that, since it isn't new. With a watchLabel set, this Actor also diffs the star rating each review had when it was last delivered and re-delivers it as watchEvent: "scoreChanged" with previousScore filled in. Restrict it with watchEvents: ["scoreChanged"] to track only rating edits (e.g. skip the noise of every brand-new review and pay only for reversals) or ["new"] to keep today's behavior. A baseline created before this existed needs one run to record the state it will diff against. There is no developer-reply field on this feed, so unlike Google Play there's no equivalent "developer replied" event to offer.

Why has my watch stopped finding anything new? Check whether you set a fixed reviewsBefore alongside watchLabel. reviewsBefore is applied client-side against each review's own updatedAt, which for a brand-new review is its post time — always "now". So once today's real calendar date passes a fixed reviewsBefore, no newly-posted review can ever be on or before that cutoff again, and the watch goes permanently quiet while still reporting the reassuring "nothing new" status every run. This run logs a warning (and sets RUN_SUMMARY.watchDeadDateBound: true) when it detects the combination. Drop reviewsBefore from a watched query (reviewsAfter alone is fine) or drop watchLabel if you actually want a one-off historical window instead of an ongoing alert.

Why did my run return 0 reviews with status SUCCEEDED? Check the run's status message first — it tells you whether Apple's feed was genuinely empty for that app/storefront or your own review filters (rating/keyword/length/votes/date) removed every row. What country codes does countries take? Apple storefronts are two-letter ISO-3166-1 alpha-2 codes — the UK is gb, not uk, and there is no usa/uk/eng. A wrong code used to look like an app with no reviews (Apple answers uk with HTTP 400 carrying valid JSON and no results); now a recognisable wrong code fails the run in about a second, before the first request and before any charge, and names the code you should have used. A well-formed code Apple simply doesn't run a store in (e.g. zz) ends that app/storefront pair on its first refusal instead of walking the rest of the page range, and the run says which pairs Apple refused. Can I get more than 500 reviews for one app? No — Apple's public feed caps at 500 most-recent reviews per app per country, and in practice it usually serves fewer. Its review RSS is served from a patchy index: measured 2026-09-22, the walk commonly ends on a full page well before page 10, so a heavily-reviewed app like Notion or Spotify returns ~100 rather than 500 per storefront. The Actor retries every empty page under a second client class to recover as much as it can, and when the feed quits early it says so explicitly (next FAQ) instead of letting a short result look complete. Widen countries for more coverage. Run on a schedule and deduplicate by reviewId to build a larger archive over time. Note that totalRatings/ratingBreakdown are not capped: they cover every rating the app has ever received in that storefront, so you still get the full-population distribution even though only 500 written reviews are reachable. How do I know whether Apple cut the feed off or the app simply has no more reviews? The run tells you, as of v0.1.51. Whenever the last page Apple served came back full and the Actor was still willing to take more, the run's status message names those app/storefront pairs, says which page the feed quit at and how many reviews it handed over, and states plainly that raising maxReviewsPerApp cannot reach the older ones (widen countries, or schedule with watchMode instead). This covers both the documented 500/10-page ceiling and the much more common early stop. A run that ends on a partial page genuinely exhausted what Apple serves for that pair — so a missing note is itself the "you got everything available" signal. Why is totalRatings different from ratingCount? They come from two different Apple sources and are both real. ratingCount is Apple's lookup API figure; totalRatings is the sum of the per-star histogram shown on the App Store product page, which updates on a slightly different schedule. Expect them to agree to within a fraction of a percent — if you need the number that matches ratingBreakdown exactly, use totalRatings. Does keyword handle accented words correctly? Yes, as of v0.1.29 — keyword and the review text it's matched against are Unicode-normalized before comparing, so an accented word (e.g. "café") matches regardless of which of Unicode's two equivalent representations (composed vs. decomposed) you typed it in. Is reviewUrl unique per review? No, and it isn't presented as such. It's Apple's own "related" link from the feed entry, which points at the app's review page for that storefront — the same URL for every review of that app in that country. Apple does not publish a per-review permalink; use reviewId as the unique key. Does countryFallback change the country field on rows I already have? No — fallback rows are clearly tagged with fallbackUsed: true and keep both the real country they came from and the requestedCountry you asked for. I listed two countries and countryFallback picked one I already asked for directly — do I get charged twice for the same review? No, as of v0.1.11. If an empty storefront's fallback lands on another storefront you also listed in countries (e.g. countries: ["us", "bt"] with countryFallback: true, and Bhutan's App Store has no reviews of its own so it falls back to the US feed you're already pulling directly), each real review is still only pushed and charged once — review IDs are deduplicated across every country for the same app within a run, not just within one storefront. Do I get charged for empty pages or retries? No — only reviews actually returned to the dataset are charged. Why does minVoteSum return nothing? Apple only populates helpfulness votes (voteSum/voteCount) on its mostHelpful feed. Every review served by the mostRecent feed comes back with 0 votes — that is real data (new reviews genuinely have no votes yet), not a gap we can fill, and it is why reviewsAfter (which forces mostRecent) can't be combined with a vote floor above 0. Set sort: "mostHelpful" and the filter works as expected; the run log warns you when it can't. How is webhookUrl different from Apify's own platform webhooks? Apify's platform webhooks are configured separately per Task/Actor via the Console or the Webhooks API — useful if you already live in the Apify Console, but extra setup if you're calling this Actor's API directly and just want a completion ping. webhookUrl is a plain input field: set it on the run itself and it POSTs a JSON body (actorRunId, defaultDatasetId, finishedAt, pushed, and — if watchLabel is set — watchSeeding/watchNewCount/watchSkipped, plus pairsIncomplete and the full per-pair pairs array described above) once the run finishes and every review has already been pushed and charged. It's best-effort — a slow or failing webhook only logs a warning, it never fails the run, changes the result set, or affects billing.

How do I check in code whether a run got everything? Read the run's RUN_SUMMARY key-value record — GET https://api.apify.com/v2/actor-runs/<runId>/key-value-store/records/RUN_SUMMARY (no webhook needed; the same data is also POSTed to webhookUrl as pairs if you set one). It holds run-level complete / incompleteReason / incompleteDetail, the counts pushed, pairsPlanned, pairsAttempted, pairsIncomplete, pairsUnknown, and a pairs array with one record per app/storefront:

{
  "app": "310633997", "country": "us", "status": "ok",
  "scanned": 50, "delivered": 50, "filteredOut": 0,
  "declaredRatingCount": 18632949,
  "complete": false, "incompleteReason": "apple-feed-ceiling",
  "scanDepthCap": 500, "feedStopPage": 4, "reason": null
}

That row is the honest version of a 50-row dataset for an app with 18.6 million ratings: you got everything Apple's public feed served, and Apple served a fraction of what exists. status is one of ok, empty (Apple's feed has nothing for that pair), filteredOut (reviews found, your filters removed all of them), watchBaselined, watchNoChanges, error (Apple refused the request — reason quotes it), badAppId (an apps entry no app id could be parsed from), notReached (the run stopped before it got there), or timedOut (the run was approaching its platform run timeout and stopped before this pair returned anything — this says nothing about whether Apple has reviews for it). complete is deliberately separate from status: a pair can deliver reviews perfectly normally and still have been cut short, and incompleteReason names which — apple-feed-ceiling (Apple stopped serving; no input value can reach deeper), max-reviews-per-app, max-results, charge-limit, baseline-cap, or time-budget (the run stopped itself short of the platform run timeout so the rows already collected would still be returned — narrow the input, raise the Actor's run timeout, or split the pairs across runs). complete: null and declaredRatingCount: null mean not observed, never zero (declaredRatingCount is only filled when includeAppInfo is on).

Just tell me if the run got everything — one field. Read the top-level complete on the same record. It is true only when every pair came back complete, false if any pair fell short or could not report at all, and null when no pair was attempted. incompleteReason names the first pair that fell short (same vocabulary as the per-pair field, plus storefront-error, bad-app-id, not-reached and time-budget for pairs that have no reason of their own), and incompleteDetail says which pair and how many others. This is the same complete / incompleteReason / incompleteDetail contract every FetchSmith Actor's RUN_SUMMARY carries, so one pipeline can check all of them the same way. Watch pairsUnknown too: it counts pairs with no completeness to report, which pairsIncomplete (known-short pairs only) deliberately excludes.

How does sort: "favorable"/"critical" work? Apple's feed has no server-side "sort by rating" — there is no such request you can make. Instead, the Actor scans that app/storefront pair under mostRecent exactly as usual (so maxReviewsPerApp/reviewsAfter mean exactly what they mean today), then re-orders everything it kept after filtering, before delivery: favorable is 5★-to-1★, critical is 1★-to-5★, and reviews tied on rating stay newest-first. Because the whole pair's result has to be assembled before anything can be ordered, it can't be combined with watchLabel (whose "only what's new" logic depends on delivering in scan order) — use mostRecent/mostHelpful for watches.

Why did I get fewer reviews than maxReviewsPerApp? maxReviewsPerApp is a scan cap, not a match count — it stops paging Apple's feed after that many reviews have been looked at, and the review filters (rating/keyword/length/votes/date) are applied after that, per review. A narrow filter combined with a low cap can miss real matches sitting deeper in the feed: on Spotify (324684580) with maxRating: 1, maxReviewsPerApp: 5 scans 5 reviews and keeps 0, but raising it to 100 finds 12 — the matches were always there, just unscanned. When this happens the log carries a WARN naming the cap and how many scanned reviews were dropped, and the run's status message says the same — raise maxReviewsPerApp to search deeper. Filtered-out reviews are not charged either way.

Notes

Apple exposes the most recent 500 reviews per app per country. For historical archives, run on a schedule and deduplicate by reviewId.

Related guides

Engineering write-ups behind this Actor:

• Apple's review feed has holes, and whether you hit one depends on your HTTP client
• The App Store's per-star ratings breakdown isn't in any of Apple's APIs — it's in the page's JSON blob
• Four ways an invisible character makes a scraper return zero rows
• We nearly charged our own buyers twice for rows they'd already paid for — a capped watch-mode baseline can silently evict old-but-current ids on a high-volume run, re-delivering (and re-billing) rows already paid for.
• App Store, Google Play and Steam reviews — three JSON APIs, three unrelated meanings of "empty" — how this Actor's specific silent-empty failure mode compares to the other two review platforms we scrape.
• Eight ways an "only new since last run" watch mode silently stops working — the fleet-wide survey of watch-mode failure shapes across all nineteen incremental Actors, this one included.

Only publicly available data is collected. Support: support@fetchsmith.com · Hosted API: https://fetchsmith.com/tools/app-store-reviews-scraper

Source code: https://github.com/Fetchsmith/fetchsmith/tree/main/actors/app-store-reviews-scraper