Apple App Store Review Scraper By Country & Storefront

Apple App Store Scraper — Reviews, Storefront Summaries & Rating Gaps

Apple App Store Scraper pulls customer reviews from the App Store's own review feed, one country storefront at a time, and returns typed JSON — reviewer, star rating, title, body, version, and a UTC-normalized date on every row. Unlike a scraper that returns raw HTML, every field arrives ready for a spreadsheet, a database, or an LLM context window with no parsing step. Apple's feed hard-stops at 500 reviews per app per storefront, so this Actor's real differentiator is what happens next: it sweeps as many storefronts as you list, then adds a per-storefront star-spread summary with the rating gap against the best-performing market in the same run. This guide covers every input and output field, and how ASO, research and monitoring teams actually run it.

What Does Apple App Store Scraper Do?

Apple App Store Scraper is an Apify Actor that reads Apple's public customerreviews RSS/JSON feed and returns three kinds of dataset rows: individual reviews, per-storefront rating summaries, and typed accounting rows for a storefront that returned nothing. It accepts an app by numeric App Store ID or by a full App Store URL, and a list of two-letter storefront country codes — no Apple ID, App Store Connect account, or developer login is required anywhere in the run.

• Sweeps one app across any number of country storefronts in a single run, each with its own independent review budget
• Accepts bare numeric App Store IDs (storefront-independent) alongside full App Store URLs
• Normalizes every review's date to UTC while preserving Apple's original store-local timestamp
• Builds a 1–5 star distribution, a sampled average rating, and a 1–2 star share per storefront
• Computes the cross-market rating gap between every storefront and the best-scoring one in the run
• De-duplicates reviews by Apple's own review ID across pages and across a run
• Records a skipped or blocked storefront as an uncharged, typed row instead of silently dropping it

⚡ Features & Capabilities

Apple App Store Scraper's feature set splits into three layers: what it extracts, how it survives Apple's feed limits, and where it sits next to the other tools people reach for.

Core features. Every review row carries Apple's raw fields — author, rating, version, title, content, date — plus fields this Actor adds on top: reviewId, reviewUrl, reviewerProfileUrl, ratingNumber (the star count as a sortable integer), dateIso (UTC), storefrontCountry, and scrapedAt. Turn on includeStorefrontSummary and every storefront also gets one roll-up row with star1Count…star5Count, sampledAverageRating, sampledNegativeShare, and ratingGapVsBestStorefront. A storefront Apple's feed refuses or has withdrawn produces a typed error row with errorReason and message — never a silent gap in your dataset.

The engine also filters page-1 entries on Apple's actual rating marker rather than assuming a fixed feed layout, so the newest review of every app on every run is kept rather than discarded — a correctness detail that only shows up once you compare review counts against the App Store page itself.

Storefront yield is app-dependent, not a fixed rate. In testing, a globally popular app returned a full page of reviews in 16 of 18 storefronts checked, while a single-market finance app returned reviews in only 2 of 18. Add storefronts where the app plausibly has an audience — an empty storefront still costs one accounting row, just not a charged one.

How it compares to other Apple App Store review scrapers. Checked on the Apify Store listings snapshot dated 8 July 2026:

Feature	Apple App Store Scraper (this Actor)	scraped/apple-app-store-review-scraper	jdtpnjtp/apple-app-store-scraper
Output format	Typed JSON dataset, 32 documented keys across 3 row types	Not documented on their listing	JSON, CSV, Excel (per their listing)
Multi-storefront sweep, one run	Yes — countries list, one 500-review budget per storefront	Not documented; their listing describes US-only scraping	Yes — country: "all" claims 40 major markets (per their listing)
Per-storefront rating comparison	Yes, built in — star spread + gap vs. best storefront	Not offered	Not offered
App metadata / keyword discovery	Not offered — reviews only	Not offered	Yes — a search mode and app-info bundling (per their listing)
Anti-blocking approach	Tiered proxy escalation (direct → datacenter → residential) with browser-accurate TLS	Not documented	Not documented
Pricing model	Pay-per-event	Flat monthly price (per their listing)	Pay-per-event
Stated review ceiling	500 reviews per app per storefront — Apple's feed hard-stop, documented and clamped to	500-review cap, stated directly on their listing	Advertises "no 500-review cap... thousands of reviews per app" on their listing

If your use case is feeding structured review data to an LLM or a BI pipeline, the output-format row is the decision-maker — every field here is already typed and named, so there's no HTML-parsing step to keep working as Apple's front end changes. On the last row: Apple's own feed answers HTTP 400 on page 11 for every app and storefront this Actor has tried, so a claim of "thousands of reviews, no cap" for one app most likely reflects sweeping several countries or time windows behind the scenes — the same technique countries gives you here, just not exposed as a control.

When another tool might suit you better. If you don't yet know which app you're targeting, jdtpnjtp/apple-app-store-scraper's keyword search mode and bundled app metadata save a lookup step this Actor doesn't do — it expects an app ID or link you already have. If you want a zero-code, MCP-first agent connector wired up for you out of the box, johnvc/apple-app-store-reviews-api documents that path on their own listing. This Actor's focus is narrower and deeper on one thing: getting past the per-storefront 500-review ceiling cleanly and honestly, with the accounting to prove what was and wasn't collected.

Apple App Store Scraper within the Scrapio data stack. This is currently Scrapio's only Apple App Store Actor — it covers reviews and per-storefront rating comparisons. There is no sibling Actor yet for App Store search results, app metadata, or ranked charts. For review-style datasets on other platforms inside Scrapio, see Goodreads Review Scraper and Facebook Pages Scraper in the related-tools table below.

Why do developers and data teams scrape Apple App Store reviews?

Review text is the largest source of unfiltered customer opinion Apple exposes without a developer login, and the audiences that pull it split cleanly by what they do with it.

🏢 ASO and product teams. A product manager tracking a competitor's iOS app sweeps its App Store ID across the markets it's live in, sets maxReviewsPerCountry to the newest 100–200 per storefront, and reads ratingGapVsBestStorefront to find which market is quietly underperforming before it shows up in the aggregate rating. version lets you group complaints by build number to catch a regression a specific release introduced.

📊 AI training data and RAG indexing. content and title are the two fields with the most consistent free text per row — long enough to carry real sentiment, short enough to chunk cleanly for a vector store. For RAG enrichment, indexing content alongside appId and storefrontCountry lets an agent answer "what are German users complaining about in this app" against live data instead of a stale summary. For training data, ratingNumber, version and dateIso are the fields with the most stable structure across every row, useful as labels or filters alongside the free text.

📱 Competitive and market intelligence. Re-run the same app ID weekly and diff sampledAverageRating per storefrontCountry against the prior run to catch a rating slide before it's visible on the App Store page itself, since Apple's headline rating blends years of ratings that outnumber written reviews many times over.

🔬 Research and academic use. Cross-cultural reception studies and market-research datasets built from App Store reviews are a recognized use of this kind of public data — storefrontCountry gives you the market boundary for free, so a comparative study doesn't need a second data source to segment by region. Scope stays to publicly accessible reviews only.

🎥 Product and SaaS development. Review-monitoring dashboards, ASO tooling, and customer-feedback aggregators built on top of App Store data use reviewId as the natural dedup key across scheduled runs, and errorReason to distinguish "no reviews yet" from "the feed refused this request" in a monitoring UI.

🍚 Input Parameters

All ten parameters accepted by the input schema, in schema order. None are required — the Actor falls back to its own defaults if a run supplies nothing at all.

Parameter	Required	Type	Constraints	Description
countries	No	array	editor: stringList	Two-letter Apple storefront codes, e.g. us, gb, de, jp, br. Leave empty to use only the country already present in each App Store link. ru and cn are skipped automatically — Apple no longer serves review feeds for them and they return zero entries.
appIds	No	array	editor: stringList	Bare numeric App Store IDs, e.g. 324684580. The ID is storefront-independent, so one ID sweeps every country listed in countries. id324684580 and full store URLs pasted into this field are also accepted.
maxReviewsPerCountry	No	integer	default 60; min 1; max 500	How many reviews to collect for each app in each storefront. Apple's hard ceiling is 500 per app per storefront — a run's real ceiling is this number multiplied by the number of storefronts. Example: 200 with 3 markets = up to 600 reviews for one app.
includeStorefrontSummary	No	boolean	default true	Appends one extra row per storefront with the 1-to-5 star spread, the sampled average, and the rating gap versus the best-performing storefront in the same run. These rows are marked type: "storefront_summary" and are never billed as review rows.
url	No	array	editor: stringList	Full App Store URLs, one entry per app — for example https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194.
urls	No	array	editor: stringList	A second link list, merged with url and de-duplicated. Kept so existing input files built for the base engine keep working unchanged.
max_review	No	integer	min 1; max 10000	Same meaning as maxReviewsPerCountry, kept under its original name. Values over 500 are accepted and clamped to 500 with a warning in the run log, because Apple's feed cannot return more per storefront.
max_pages	No	integer	default 10; min 1; max 10	Each page returns up to 50 reviews. Apple serves 10 pages at most — page 11 answers HTTP 400 — so values above 10 are clamped. Lower it for a faster, smaller sample.
pageDelaySeconds	No	integer	default 2; min 0; max 30	Seconds to wait between page requests. Raise it if a long multi-market sweep starts hitting rate limits. The original delay_between_pages key is still read first when present, including fractional values.
proxyConfiguration	No	object	editor: proxy	Optional Apify Proxy settings. Left off, the run goes direct and escalates automatically only if Apple starts refusing pages.

A precedence rule worth knowing before you mix old and new input files: the code checks legacy keys first. If both max_review and maxReviewsPerCountry are set, max_review wins. If delay_between_pages is set alongside pageDelaySeconds, delay_between_pages wins. This is deliberate — it's what lets an input file built for the original engine keep behaving exactly as it did — but it means the newer, documented field can silently be overridden if an old key is still present in your input JSON.

{
  "appIds": ["1449777194"],
  "countries": ["us", "gb", "de", "jp"],
  "maxReviewsPerCountry": 200,
  "includeStorefrontSummary": true,
  "pageDelaySeconds": 2
}

Supported input formats. Apps can be identified two ways, and both can be combined in the same run. A bare numeric ID in appIds — 324684580 — sweeps every storefront listed in countries. A full URL in url or urls — https://apps.apple.com/us/app/id324684580 — always sweeps its own embedded country code (us, above) in addition to whatever is listed in countries. A bare ID pasted into the url field also works; the Actor extracts the digits and treats it the same as an appIds entry. countries itself accepts a plain string ("us, gb, de"), a list, or values with mixed separators — it's normalized, lower-cased and de-duplicated regardless of how it arrives.

📦 Output Format

Every row lands in one dataset table with the same 32 keys available across the run, distinguished by the type field: "review", "storefront_summary", or "error". Each row type populates only the keys that apply to it — the rest are simply absent from that row, not padded with nulls. Only "review" rows are billed, under the row_result charged event; "storefront_summary" and "error" rows are pushed without a charged event, so they never add to your bill. To pull billed rows only from the dataset, filter on type == "review".

Review rows

{
  "type": "review",
  "isSummary": false,
  "storefrontCountry": "us",
  "country": "us",
  "appId": "1449777194",
  "appStoreUrl": "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194",
  "reviewId": "12086543210",
  "dateIso": "2026-07-16T12:52:31Z",
  "date": "2026-07-16T05:52:31-07:00",
  "rating": "5",
  "ratingNumber": 5,
  "title": "Finally a budgeting app that clicks",
  "content": "Switched from a spreadsheet and haven't looked back. Syncing is fast and the categorization is smart.",
  "author": "budgetnerd22",
  "reviewerProfileUrl": "https://itunes.apple.com/us/reviews/id123456789",
  "version": "3.14.2",
  "reviewUrl": "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194?see-all=reviews",
  "scrapedAt": "2026-07-25T09:12:44Z"
}

storefrontCountry and country are always the same value — country is kept for compatibility with input files built for the original engine, storefrontCountry is the field to use going forward. rating is Apple's raw text label; ratingNumber is the same value parsed to an integer, or null when it can't be parsed. date is Apple's original store-local timestamp with its own UTC offset; dateIso is that same instant normalized to UTC, so you can sort or compare across storefronts without doing timezone math yourself.

Storefront summary rows

{
  "type": "storefront_summary",
  "isSummary": true,
  "storefrontCountry": "gb",
  "country": "gb",
  "appId": "1449777194",
  "appStoreUrl": "https://apps.apple.com/gb/app/id1449777194",
  "reviewsCollected": 60,
  "sampleSize": 60,
  "sampledAverageRating": 4.317,
  "star1Count": 3,
  "star2Count": 2,
  "star3Count": 5,
  "star4Count": 14,
  "star5Count": 36,
  "sampledNegativeShare": 0.0833,
  "bestStorefront": "de",
  "ratingGapVsBestStorefront": 0.216,
  "storefrontsCompared": 3,
  "scrapedAt": "2026-07-25T09:14:02Z"
}

These figures describe only the reviews actually collected in this run — the newest N per storefront, capped by maxReviewsPerCountry — never the app's lifetime App Store rating, which blends far more ratings than written reviews. reviewsCollected is every review row pushed for that storefront; sampleSize is the subset of those with a parseable 1–5 star rating, so the two can differ slightly and the denominator behind every ratio is always visible rather than assumed. bestStorefront and ratingGapVsBestStorefront are both null unless at least two storefronts in the run returned usable data — a gap against a single data point isn't meaningful, so the Actor doesn't compute one.

Error / accounting rows

{
  "type": "error",
  "isSummary": false,
  "storefrontCountry": "cn",
  "country": "cn",
  "appId": "1449777194",
  "appStoreUrl": "https://apps.apple.com/cn/app/id1449777194",
  "errorReason": "storefront_unavailable",
  "message": "Storefront cn is not served by the Apple review feed.",
  "scrapedAt": "2026-07-25T09:11:58Z"
}

errorReason takes one of: storefront_unavailable (Apple has withdrawn or segregates that store — ru and cn are pre-filtered into this automatically), invalid_input (a pasted link or ID had no extractable numeric App Store ID), feed_not_found, or http_<status> / network_error (the feed could not be loaded after the full retry ladder was exhausted). message is a plain-language explanation of the same event. These rows exist so a run that hits zero reviews for a storefront is auditable in the dataset rather than simply missing — and because they're pushed without a charged event, checking why a storefront came back empty never costs you anything.

Field names stay stable across runs regardless of what Apple changes on the visible App Store page — the Actor reads Apple's underlying feed structure, not rendered HTML, so a front-end redesign doesn't touch this schema. Export the dataset as JSON, CSV, Excel, XML or RSS directly from the Apify Console, or read it programmatically through the Apify API or apify_client.

Apple App Store Scraper Strategy Guide

Strategy 1: Real-time enrichment pipeline. Trigger a run on demand — from a support ticket, a competitor-tracking cron, or a manual check — with a single appIds entry and the storefronts you need. Read the pushed rows back through client.dataset(run["defaultDatasetId"]).iterate_items(), append ratingNumber, content and storefrontCountry to whatever record the app already has in your system (a CRM row, a support queue, an internal app registry), and write it back. Because reviews are keyed on reviewId, a second enrichment run for the same app only adds what's new if you diff against previously stored IDs.

Strategy 2: Scheduled monitoring and alerting. Use an Apify Schedule to run the same appIds and countries weekly. After each run, diff sampledAverageRating and star1Count per storefrontCountry against the previous run's storefront_summary rows for the same app, and alert when ratingGapVsBestStorefront widens past a threshold you set — that's the signal a specific market is degrading relative to the rest, often before it's visible in Apple's own aggregate rating.

Strategy 3: Bulk dataset build. For a research or training-data build, list every app you need in appIds and every market in countries in one run, and let the Actor sweep the full combination sequentially. Set maxReviewsPerCountry and max_pages to control the size and pace of the sweep — there is no separate concurrency setting to tune beyond those two, since one run processes its apps and storefronts in sequence. Export the finished dataset directly to CSV from the Apify Console, or pull it with apify_client and aggregate however your pipeline needs.

Strategy comparison at a glance

Strategy	Best for	Run pattern	Output format
Real-time enrichment	Support and product teams reacting to one app right now	Single on-demand run, small appIds/countries list	JSON via Apify API
Scheduled monitoring	Tracking rating drift over time, market by market	Recurring Apify Schedule, same input every run	Dataset diffed run over run, JSON or CSV
Bulk dataset build	Research or training corpora across many apps/markets	One large run, full appIds × countries combination	CSV or Excel export

🌴 Related Apple App Store Scrapers & Tools

Scrapio does not yet publish a second Apple App Store Actor — no dedicated app-search or app-metadata companion exists alongside this one, so pairing App Store review data with app metadata currently means combining this Actor's output with a separate source. For review-style datasets on other platforms, these Scrapio Actors cover the same entity — reviews — on different sources:

Scraper Name	What it extracts
Goodreads Review Scraper — Sentiment & Theme Analysis	Public Goodreads book reviews with sentiment labels, theme/aspect mining, and a per-book positive/negative rollup
Facebook Pages Scraper: Review Sentiment Analysis	Facebook page visitor reviews/recommendations with a per-page recommend-rate rollup

How to integrate Apple App Store Scraper with your stack

Apple App Store Scraper works with any language or tool that can make an HTTP request to the Apify API. All examples below use apify-client, the official client library, and run against <YOUR_USERNAME>/apple-app-store-review-scraper-by-country-storefront.

Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/apple-app-store-review-scraper-by-country-storefront").call(
    run_input={
        "appIds": ["1449777194"],
        "countries": ["us", "gb", "de"],
        "maxReviewsPerCountry": 150,
        "includeStorefrontSummary": True,
    }
)

rows = list(client.dataset(run["defaultDatasetId"]).iterate_items())
reviews = [r for r in rows if r.get("type") == "review"]
summaries = [r for r in rows if r.get("type") == "storefront_summary"]

for r in reviews:
    print(r["storefrontCountry"], r["ratingNumber"], r["title"])

for s in summaries:
    print(s["storefrontCountry"], s["sampledAverageRating"], s["ratingGapVsBestStorefront"])

Node.js

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('<YOUR_USERNAME>/apple-app-store-review-scraper-by-country-storefront').call({
    appIds: ['1449777194'],
    countries: ['us', 'gb', 'de'],
    maxReviewsPerCountry: 150,
    includeStorefrontSummary: true,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
const reviews = items.filter((row) => row.type === 'review');
console.log(`${reviews.length} review rows collected`);

Async and scheduled pipelines. Apify Schedules run this Actor on a cron interval without any code — set one up from the Actor's Console page for recurring monitoring. For fire-and-forget large sweeps, start a run with client.actor(...).start(...) instead of .call(...), poll client.run(run_id).get() for status, and read the dataset once it reports SUCCEEDED. Apify webhooks can also notify an external endpoint when a run finishes, if you'd rather not poll.

🎯 Who Needs Apple App Store Review Data? (Use Cases & Industries)

🏢 ASO and product teams. Pull the newest reviews for your own app across every storefront it ships in, sort by ratingNumber to surface the harshest recent feedback first, and use version to confirm whether a complaint predates your last release or is a fresh regression.

📊 Data and analytics teams. Feed content, ratingNumber, storefrontCountry and dateIso into a BI dashboard or a sentiment model, refreshed on a schedule, to track review volume and rating trend per market over time without re-deriving the storefront segmentation yourself.

📱 Competitive intelligence teams. Point the same run at a competitor's App Store ID instead of your own — appIds doesn't care whose app it is — and use ratingGapVsBestStorefront to spot which of their markets is their weakest, a common signal for where a competitor is under-investing in localization or support.

🔬 Researchers. Cross-cultural and market-research studies on mobile app reception use storefrontCountry as a ready-made regional boundary and content as raw text for coding or NLP analysis. Scope stays to publicly accessible App Store reviews only — no login-gated data is collected.

Is it legal to scrape Apple App Store reviews?

Scraping publicly accessible web data is broadly permitted under U.S. law; hiQ Labs v. LinkedIn (9th Cir. 2019) is the most frequently cited precedent holding that accessing data with no login barrier does not violate the Computer Fraud and Abuse Act. Apple App Store Scraper only reads Apple's public review feed — the same reviews any visitor sees on the app's App Store page — with no account, cookie, or authentication of any kind.

That said, "legal to scrape" and "compliant with Apple's Terms of Service" are separate questions. Automated collection of App Store content may fall outside Apple's terms of use, which is a contractual matter between you and Apple, not a criminal one — but it's still worth reading before large-scale or commercial use, and especially before republishing review text at scale rather than analyzing it internally. Review text and star ratings are user-generated content rather than structured business records, and the author field carries the reviewer's public display name, which Apple shows to every visitor rather than a private identifier — but if your jurisdiction treats a public username as personal data, standard data-protection obligations (lawful basis, retention limits, deletion on request) sit with you as the data controller once you store it.

Apple App Store Scraper returns only publicly accessible data. What you do with that data is your responsibility — consult legal counsel for commercial applications, especially any involving reviewer-identifiable information.

❓ Frequently asked questions

Does Apple App Store Scraper work without an Apple account? Yes. Apple's customerreviews feed is public and keyless — no Apple ID, App Store Connect account, or developer login is used or required anywhere in the run. The only credential involved is your own Apify token, for calling the Actor itself.

How does it handle Apple's anti-scraping measures? Requests carry browser-accurate TLS fingerprinting (via impit, with a plain HTTP fallback) and a real desktop User-Agent. On a blocked or rate-limited response the Actor escalates through proxy tiers — direct, then Apify Datacenter, then Apify Residential — with exponential backoff and jitter between retries, and locks onto residential once it's needed for the rest of that storefront sweep. Each page fetch gets up to five attempts within a tier before escalating further, and a page that comes back with zero entries is retried rather than treated as end-of-feed immediately, since Apple occasionally serves an empty page mid-feed rather than at its actual end. A 404 is treated as "feed not found" and a 400 as the page-11 ceiling — both end that storefront's sweep cleanly rather than being retried, since retrying either would just waste requests on an outcome that won't change.

Can I run it at scale without getting blocked? The Actor retries through its full proxy ladder before giving up on a page, and a storefront that ultimately can't be loaded is recorded as an uncharged error row rather than silently dropped — so a large multi-app, multi-country sweep degrades gracefully instead of failing outright. No uptime or success-rate figure is published, since that depends on Apple's feed behavior at request time, not on the Actor alone.

How fresh is the data it returns? Fully live. Every run fetches the review feed directly at request time — nothing is cached or served from a prior run. scrapedAt records exactly when each row was collected.

Why can't I get more than 500 reviews for one app in one storefront? Apple's feed itself stops there — page 11 answers HTTP 400 for every app and storefront tested, regardless of what maxReviewsPerCountry or max_review is set to above 500. The only way past that ceiling is more storefronts, via countries; there is no parameter that bypasses Apple's own limit.

Which fields work best for AI training and RAG indexing? For RAG: content and title carry the most descriptive free text per review and chunk cleanly on their own. For training data: ratingNumber, version, storefrontCountry and dateIso are the most structurally consistent fields across every row — always present, always the same type. All fields return as typed primitives, so no normalization pass is needed before indexing.

Does reviewer information count as personal data? The author and reviewerProfileUrl fields carry the public display name and profile link Apple shows to any App Store visitor — not a private identifier. Apple App Store Scraper collects only what's already public, but lawful basis for storing and using that data once you have it is your responsibility as the data controller, particularly for any use beyond aggregate analysis.

Does it work with Claude, ChatGPT, and other AI agent tools? It's callable as a standard Apify Actor run through the Apify API, so any agent framework that can make an HTTP request — LangChain, CrewAI, a custom tool definition, or a direct API call — can invoke it and get typed JSON back with no parsing step.

How does it compare to other Apple App Store review scrapers? Checked on the Apify Store listings snapshot dated 8 July 2026: scraped/apple-app-store-review-scraper is the simplest option — single-market scraping under a flat monthly price, with no multi-storefront or summary features documented. jdtpnjtp/apple-app-store-scraper adds an app-search mode, bundled app metadata, and a stated 40-market country: "all" option, on pay-per-event pricing. johnvc/apple-app-store-reviews-api leads with MCP-first agent integration and sort-order options (most recent, most helpful, most favorable, most critical). This Actor's edge is depth on one narrow job: an honest accounting of Apple's per-storefront 500-review ceiling, a built-in cross-market rating comparison, and typed rows for every storefront outcome — collected, empty, or blocked.

Disclaimer

Apple App Store Scraper extracts only publicly available data from Apple's App Store review feed. This tool is intended for lawful use cases only. Users are responsible for complying with Apple's terms of service and applicable data protection laws in their jurisdiction, particularly for any commercial use involving reviewer-identifiable information.