A developer publishing under the handle rel8ble has released an Apify actor, App Store & Google Play Reviews Scraper, that pulls reviews from Apple's App Store and Google Play into a single dataset with identical field names, according to the author's own write-up on dev.to. The post is a first-person account by the tool's builder, so every performance, pricing and coverage figure below is an author claim rather than an independently verified measurement.
The stated motivation is operational rather than analytical: the author argues that store reviews surface release breakage before crash reporting does, that the two stores expose different formats, and that Apple's public feed stops early. The actor is positioned as a way to avoid checking two separate consoles. The author describes himself as an 18-year-old engineering student and states the actor is a paid tool on Apify with a free trial credit.
The actor, the author says, mechanically reads public web data using plain HTTP; neither a headless browser nor a login is involved. From Apple's public iTunes lookup endpoint, and from data embedded in the Play app page, app metadata is drawn, whereas reviews are obtained at 200 per request from the public endpoints each store's website uses. Across Spotify and Uber on both stores, a test run of 20,000 reviews, the author reports, finished in under 30 seconds, with zero failed requests and zero duplicates. For that figure, no methodology, hardware, region or independent reproduction is offered.
Input handling is deliberately mixed: a single app list can contain App Store URLs or numeric IDs alongside Play URLs or package names, with country, language, sort order and a per-app review cap as parameters. The author documents Python and Node client calls, and notes that sort can be set to newest or mostHelpful. Output is one row per review, with fields a given store does not supply left null.
The schema differences are the substantive part of the claim. App Store rows carry a title and an isEdited flag but no per-review version, because Apple's public data does not include it. Play rows include a version field for roughly 84 percent of reviews, which the author says is what allows complaints to be tied to a specific release. A trimmed example Play row shows store, appId, appName, country, reviewId, rating, title, text, reviewDate, reviewerName, version, thumbsUp, developerReply, developerReplyDate, appRating, appRatingCount, appInstalls and appUpdated.
The author's worked example is a daily Slack alert: fetch only reviews since yesterday, filter to 1 and 2 stars, and post them to a channel through an incoming webhook. The sample code computes a since date one day back, passes stars [1, 2] and reviewsSince to the actor, formats each row with rating, store label, version where present and a truncated review body, then posts the joined lines. The author states that with sort set to newest and reviewsSince supplied, the run stops once it reaches older reviews, so a daily run only pays for new ones.
Pricing is stated as $0.25 per 1,000 reviews, with reviews filtered out by star or date filters billed as free, as are apps that turn out not to exist, and no start fee. The author estimates a mid-size app's daily alert at often under a hundred reviews a day, costing a few cents a month, and puts a 100,000-review research dataset at $25. Apify's free plan is described as providing $5 of monthly credit, about 20,000 reviews at that rate. These are vendor-side figures relayed by the tool's author and were not checked against Apify's published pricing in the supplied material.
Several constraints are stated plainly. App Store reviews have no app version. Google Play returns one language per run, so two languages require two runs. Reviews are per country, so us and gb must be run separately. Star filtering on Play is walked one star at a time, meaning [1, 2] returns newest 1-star reviews first and then 2-star reviews, because Play has no most-critical sort. The author also flags that reviewer names and avatars are personal data under GDPR and CCPA and that a lawful basis is needed before storing them.
For freelancers and small studios, the practical appeal is the normalised schema rather than the scraping itself: one table with consistent field names removes the per-store parsing work that otherwise sits in a client reporting pipeline. The version field on Play rows is the most useful column for client work, because it is the only documented way in this dataset to connect a complaint to a release, and the author's own suggested heuristic is that Android rows clustering on one version probably indicate a regression. That heuristic is the author's interpretation, not a tested finding.
The daily-alert pattern is also the cheapest supported use case, since the author says date and star filters are not billed. A freelancer monitoring a handful of client apps could plausibly run it on Apify's free monthly credit, though the author gives no worked cost for a specific app and the estimate depends on review volume that varies by app and country.
The tradeoffs are structural. Apple's missing per-review version means iOS complaints cannot be tied to a release through this data at all. Country and language fragmentation multiplies runs and therefore cost for any app with a global user base. Play's star-by-star walk means a combined 1- and 2-star pull is not a single sorted stream, which matters if the alert is expected to be chronological. And the actor is a paid third-party dependency on Apify, so availability, rate limits and continued endpoint compatibility rest with the author and the platform.
What remains unverified is substantial. The 20,000-review, sub-30-second, zero-failure result is a single author-reported test with no described method. The 84 percent Play version coverage figure has no stated sample. The pricing and free-credit figures are relayed rather than sourced to Apify's own documentation. The claim that the actor uses only public endpoints without login is the author's description of his own tool. And the post itself carries a disclosure that it was drafted with AI and published by the author, which is relevant to how the technical detail should be weighed.
The author also points readers to the actor's Issues tab for problems, which is the only stated support channel in the material. No release date, version number or changelog for the actor appears in the supplied text, so the timing of the release itself is not established here.
The honest conclusion for this audience is that the actor is worth evaluating as a normalisation layer, not as a novel data source: the underlying reviews are public and the endpoints are the stores' own. The value on offer is the shared schema, the version column where Play supplies it, and the filter-based billing model that makes a narrow daily alert cheap. Anyone relying on it for client reporting should verify the version coverage and per-country behaviour on their own target apps before quoting a cost, and should treat the performance and pricing numbers as the builder's claims until confirmed independently.