Paste an App Store link and get the reviews back as rows - author, rating, title, full text, the review date, and the app version each review was written against. That last column is the one that matters: it turns a wall of feedback into a per-release read on what you shipped.
The input is the App Store page itself. Open the listing you care about, copy the URL, and hand it over - no identifiers to look up first.
One row per review, tagged with the query it came from - so a run across several apps still reconciles back to your input list.
Every review carries the version it was written against. Group by it and a rating dip stops being a mystery - you can see the build it started on.
Sort before you pull. Most Recent for release monitoring, Most Helpful for the feedback other users actually voted up - a very different sample.
Both live on apps.apple.com and both collect reviews. If you publish a show as well as an app, the same tool covers the listening side.
Taken from real exports, and every one of them arrives filled - across 821 reviews there was not a single empty cell in any column.
No blanks to plan around. Across 821 reviews from 37 separate runs, all eight columns were populated on every row - unusual, and it means version in particular can be relied on for the per-release analysis below rather than treated as best-effort. Review text arrives with no preprocessing, so anything you run over it reads the user's own wording.
Most review analysis treats feedback as one undifferentiated pile. App reviews don't have to be read that way.
An App Store rating is cumulative, which means a bad release doesn't announce itself - it shows up as a slow drift in an average that already has thousands of reviews behind it. By the time the number moves visibly, the build that caused it may be two releases old.
Because every review carries the app version it was written against, you can cut the same dataset by build instead. Ship 4.2, pull the reviews tagged 4.2, and compare their rating distribution and complaint language against 4.1. A regression that would take weeks to surface in the headline rating is visible in the first few hundred reviews.
The timestamp matters here too. updated is the only date in the file, so a review that moves later than you expect is a reviewer who came back and edited theirs - often a user whose problem was fixed, or wasn't. There is no separate original-post date to compare it against.
A few examples of how teams use App Store review data.
Pull Most Recent reviews after a launch and group them by version. If the new build's one-star share jumps and the same phrase keeps appearing, you have both the signal and the likely cause before support tickets pile up.
Point it at a competitor's listing and sort by Most Helpful - the reviews other users voted up are the ones that resonated. What their users keep asking for is the clearest roadmap input you'll get for free.
Podcast listings collect reviews the same way apps do, and there's no analytics dashboard that shows you the text. Exporting it gives producers actual listener wording instead of a star average.
No subscription, no minimum. Your first 500 reviews are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked, full feature set - enough to cut your last release by version and see whether it holds up.
Roughly $2 per 1,000 reviews. The pre-flight estimator shows the count and credit cost before a run starts - no surprises, no compute units to translate.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for continuous monitoring across a portfolio of apps. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Feedback rarely lives on one platform.
The same job for physical products - reviewer name, verbatim text, rating and date from a product list, across 17 Amazon marketplaces.
Find who you're up against for a keyword. Apple never shows which apps ranked alongside yours, so capturing the search is the only way to see the competitive set.
Short answer: yes for the public review content - and that is all we ever collect.
Reviews are published to be read. Apple shows the reviewer's display name, the title, the text, the rating and the version to anyone visiting the listing, signed in or not. Collecting publicly visible feedback for product research is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
Two caveats we'd rather state than bury. Apple's terms restrict automated access, so this is a terms question as well as a legal one - if you have a developer agreement with Apple, check it. And every review carries the reviewer's display name, which makes the output partly personal data: analysing feedback on a release is a defensible purpose, building a picture of an individual reviewer is not.
We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
query, app_id, author, rating, title, review, version and updated. That is the header row of real exports - 37 runs, 821 reviews - and every column was populated on every row. Full descriptions are in the data dictionary above.500 one-time free reviews on every new account - no expiry. After that it's $0.002 per review, pay-as-you-go - no card on file until you say so.
Livescraper's AppStore Reviews Scraper turns an App Store listing into review data. You paste the page link or the app ID, choose whether to sort by Most Helpful or Most Recent, set a limit per query, and download the result as CSV, JSON or Excel - no parser to write and no identifier to hunt down first.
Each row carries eight columns: the query you submitted, the app's numeric identifier, the author's display name, the star rating, the title and full text, the version of the app the review was written against, and the review timestamp. Across 821 reviews pulled in 37 separate runs, every one of those columns arrived populated on every row. Text comes back verbatim, so downstream sentiment work reads the user's own wording rather than ours.
The version field is what separates app review data from most other feedback. Store ratings are cumulative, so a bad release drifts an average that already has thousands of reviews behind it - by the time the headline number moves, the build responsible may be two releases old. Cutting the same export by version shows a regression in the first few hundred reviews instead.
Product teams use it to check a launch for regressions and to see which complaints other users voted up. Competitive teams read a rival's Most Helpful reviews as free roadmap input. Podcast publishers use it because listings collect written reviews the same way apps do, and no analytics dashboard shows that text. Start free - your first 500 reviews cost nothing and need no credit card.