Apple App Store Reviews Scraper — App Reviews & Ratings

An Apple App Store reviews scraper that returns every customer review of any iOS app as structured rows: the 1–5 star rating, title, review text, reviewer nickname, app version, date, edited flag and the developer's public reply — apple app reviews from every country storefront in a single run, each row tagged with its country. It reads the same JSON endpoint the App Store's own web page calls, so it pages far past the 500-review cap of Apple's old RSS feed (which now answers empty for most apps) and works for ios app reviews in the tens of thousands per app.

Give it app ids, App Store URLs, or plain app names. No login, no apple app store reviews api key, no browser. It bills per review row, and four filters cut what you pay for before billing: a rating band, a since-date, written-text-only, and a per-app cap. It is built for app review monitoring on a schedule as much as for one-off exports.

Last verified working: 2026-08-29.

What does the App Store reviews scraper do?

You give it apps and storefronts. It gives you their app store reviews as rows you can sort, filter and export.

• review rows — rating (1–5), title, text, author, version, is_edited, review_date (ISO 8601) and review_day (YYYY-MM-DD), developer_response and developer_response_date, country, app_id, app_name, url, fetched_at. These are the rows you pay for.
• app rows — free context per app and storefront: app_name, developer, seller, bundle_id, genre, price, currency, version, age_rating, rating_avg, rating_count, rating_avg_current, rating_count_current, the star histogram hist_1, hist_2, hist_3, hist_4, hist_5, written_reviews, released, updated, icon, app_url and reviews_fetched.
• status rows — free: per app and country (target is the id, URL or name you gave), what was harvested (reviews, filtered, pages, duplicates), whether the app was not_found on that storefront, and why anything failed (error).

Every row of a type carries every column, so the dataset drops straight into a spreadsheet or a database without a cleaning step.

App store reviews by country, in one run

Reviews live per storefront. A US-only export of a global app misses most of its app reviews by country, and the incumbent tools make you run once per storefront. Here countries is a list:

{ "appIds": ["310633997"], "countries": ["us", "gb", "de", "fr", "jp", "br", "in"], "maxReviewsPerApp": 200 }

That is one run, seven app rows (one per storefront, each with its own rating histogram), and up to 1,400 review rows, every one tagged with country. Apple occasionally lists the same review on two storefronts; the first storefront to deliver it keeps it, so you never pay for a review twice.

Forty-eight storefronts are known by their two-letter code (us, gb, ca, au, de, fr, it, es, nl, se, no, dk, fi, ch, at, be, ie, pt, pl, cz, ru, tr, il, ae, sa, eg, za, ng, ke, br, mx, ar, cl, co, pe, jp, kr, cn, tw, hk, sg, in, nz, ph, id, my, th, vn).

Apple app reviews by id, by URL, or by name

Most tools want Apple's numeric id first. All three inputs work here, and they can be mixed:

• appIds — the digits after /id in any App Store link, e.g. 310633997. Fastest, and what an earlier run's app_id gives you.
• startUrls — App Store pages such as https://apps.apple.com/us/app/whatsapp-messenger/id310633997. The id is read from the URL for you.
• appNames — the name as you would type it into App Store search: Duolingo. Each is resolved to the top hit on each storefront through Apple's own search API.

A URL and its id are the same app, and an app is harvested once per storefront however many inputs point at it.

App store negative reviews without paying for the happy ones

minRating and maxRating keep only reviews inside a star band, and they run before billing. A complaints feed:

{ "appIds": ["310633997"], "countries": ["us", "gb"], "sort": "most_critical", "maxRating": 2, "requireText": true, "maxReviewsPerApp": 300 }

reads up to 300 reviews per storefront in most-critical order and delivers — and bills — only the 1★ and 2★ ones that actually say something. The status row's filtered column shows how many were dropped for free. sinceDate does the same for time: "7 days" with "sort": "most_recent" is a daily new-reviews feed that never goes stale.

Input

field	what it does
appIds	Apple's numeric app ids.
startUrls	App Store app URLs; the id is read from each.
appNames	App names, resolved through Apple's search API on each storefront.
countries	Storefront codes to read each app on. Default ["us"].
maxReviewsPerApp	Per app and storefront. 0 = everything Apple pages out; N = the first N in the chosen order. The main cost control. Default 100.
sort	most_recent (schedule this), most_helpful (the App Store's own order), most_critical (1★ first), most_favorable (5★ first).
minRating / maxRating	0 = all; 1–5 = keep only reviews inside the band. Filters before billing.
sinceDate	Keep reviews on or after a date: 2026-08-01, or relative — "7 days", "2 weeks", "3 months". Filters before billing.
requireText	Drop reviews that are a rating with no words. Filters before billing.
includeAppRow	Emit the free app row per app and storefront (default on).
sessions / perIp	Parallel proxy sessions and the per-IP pace. Apple answers about one request a second per IP.
proxyConfiguration	Apify Proxy (default datacentre group). Apple's endpoints need no login, but a large run needs several IPs to stay under the per-IP cap.

Example: a scheduled new-reviews feed for your own app

{ "appIds": ["570060128"], "countries": ["us", "gb", "de", "jp"], "sort": "most_recent", "sinceDate": "1 day", "maxReviewsPerApp": 200 }

Example: the full US corpus for a competitor set, by name

{ "appNames": ["Duolingo", "Babbel", "Memrise"], "countries": ["us"], "maxReviewsPerApp": 0, "sort": "most_helpful" }

Example: only what the developer has replied to, from the last quarter

{ "startUrls": ["https://apps.apple.com/us/app/whatsapp-messenger/id310633997"], "countries": ["us"], "sinceDate": "3 months", "maxReviewsPerApp": 2000 }

then filter the dataset on developer_response — the reply, its date, and the review it answers sit on the same row.

Output

A review row:

{
  "type": "review",
  "review_id": "13657831289",
  "app_id": "310633997",
  "app_name": "WhatsApp Messenger",
  "country": "us",
  "rating": 5,
  "title": "WhatsApp not bad",
  "text": "WhatsApp's not bad at all—it's actually great for what it does. End-to-end encryption keeps your actual messages and calls private…",
  "author": "Ed Bradway",
  "version": null,
  "is_edited": false,
  "review_date": "2026-01-21T04:48:38Z",
  "review_day": "2026-01-21",
  "developer_response": null,
  "developer_response_date": null,
  "url": "https://apps.apple.com/us/app/id310633997?see-all=reviews",
  "fetched_at": "2026-08-29T06:10:04+00:00"
}

An app row carries rating_avg 4.68, rating_count 18,484,827, hist_1 … hist_5 (630,438 one-star ratings against 15,611,785 five-star), written_reviews 198,881, genre "Social Networking", price 0, version, released, updated, icon and app_url. The dataset has five views — Overview, Reviews, Complaints, Apps and Run status — and exports to CSV, Excel or JSON from the Apify Console or API.

How much does it cost?

Pay per delivered review row, and nothing else: app rows, status rows, filtered reviews, apps with no reviews, unknown apps and failed jobs are free. A 200-review pull of one app on one storefront is 200 rows; a complaints feed that reads 300 reviews and keeps 40 bills 40. Apple pages ten reviews per request, so cost tracks rows, not requests. The price per row is on the pricing tab, and a spending limit on the run caps the total — whatever the limit refuses is never delivered.

App store reviews scraper in Python, JavaScript, curl, n8n, Make or an AI agent

Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")
run = client.actor("kestrel/app-store-reviews-scraper").call(run_input={
    "appIds": ["310633997"], "countries": ["us", "gb", "de"],
    "sort": "most_recent", "maxReviewsPerApp": 100,
})
rows = client.dataset(run["defaultDatasetId"]).list_items().items
reviews = [r for r in rows if r["type"] == "review"]
for r in reviews[:5]:
    print(r["country"], r["rating"], r["title"], "—", (r["text"] or "")[:80])

JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });
const run = await client.actor('kestrel/app-store-reviews-scraper').call({
    appNames: ['Duolingo'], countries: ['us'], sort: 'most_critical', maxRating: 2, maxReviewsPerApp: 300,
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
const complaints = items.filter(r => r.type === 'review');
console.log(complaints.length, 'low-star reviews');

curl

curl -X POST "https://api.apify.com/v2/acts/kestrel~app-store-reviews-scraper/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>&timeout=300" \
  -H "Content-Type: application/json" \
  -d '{"appIds":["310633997"],"countries":["us"],"sinceDate":"7 days","sort":"most_recent","maxReviewsPerApp":200}'

n8n / Make / Zapier — call the same run-sync-get-dataset-items URL from an HTTP Request node with a Header Auth credential (Authorization: Bearer <token>), filter rows on type === 'review', dedupe on review_id in the workflow's static data, and route new 1–2★ reviews to Slack, a Google Sheet or a ticket queue. Relative sinceDate values keep a daily schedule from ever going stale. Apify's native n8n and Make apps work too.

AI agents / MCP — the actor is on Apify's MCP server, so an agent with Apify MCP access can call it by name with the same input and read the rows back. The input and output schemas are complete, which is what lets an agent fill the input from a plain-English request.

Is it legal to scrape App Store reviews?

Reviews are public content that Apple shows to anyone without an account, and this actor reads them through the same public endpoints a browser uses, with no login, no circumvention of access controls and no personal data beyond the public nickname a reviewer chose. Whether you may store and process the data depends on your jurisdiction and purpose — GDPR treats a nickname plus review text as personal data, so keep what you need, and read Apple's terms for the App Store website. This is not legal advice.

Limits and honest notes

• Depth. Apple's endpoint pages ten reviews at a time by offset and keeps answering deep into an app's history (tens of thousands for the biggest apps). A run's maxReviewsPerApp and its spending limit decide when to stop; 0 means "everything Apple pages out".
• Ratings versus reviews. An app's rating_count counts star ratings, most of which have no text. Only written reviews are pageable; written_reviews on the app row is how many the storefront holds.
• Version. Apple's current endpoint does not always attach the app version to a review; the column is null when it is absent.
• Pace. Apple answers roughly one request a second per IP and replies 429 beyond that. The fetcher paces each session and rotates on 429, so a big run is slower with one IP than with several — use Apify Proxy for anything over a few hundred rows.
• Names. appNames takes the top search hit on each storefront; when a name is ambiguous, use the id.

FAQ

Does it need an Apple developer account or API key?

No. Everything is read from public endpoints. The App Store Connect API gives developers their own app's reviews only; this reads any app's.

Can I download App Store reviews as CSV or Excel?

Yes. Every run writes an Apify dataset; open it in the Console and export as CSV, Excel, JSON or XML, or fetch it from the API with ?format=csv. This is the download app store reviews and app store reviews csv path — an app store reviews export with no extra step.

How do I get only App Store negative reviews?

Set maxRating to 2 (or 1), sort to most_critical, and optionally requireText. Five-star reviews are dropped before billing.

Can I scrape reviews for many countries at once?

Yes — that is the point of countries. Each storefront gets its own app row and its own review rows, all in one dataset with a country column, which makes app store reviews by country a pivot rather than a project.

How many reviews can one app return?

As many as Apple pages out, which for large apps is tens of thousands per storefront. The old RSS feed stopped at 500; this does not use it.

Does it include the developer's reply?

Yes — developer_response and developer_response_date on the review row, which makes an app store developer response audit a filter.

Can I use it as a general app review API?

Yes: call run-sync-get-dataset-items and you have an app store review api that returns JSON for any app and storefront. Pair it with a Google Play reviews source to cover both stores.

Can I scrape App Store reviews without an API?

That is what this is: scrape app store reviews with a JSON input and get rows back, no Apple API, no browser.

What does bulk work cost?

Rows delivered times the per-row price, nothing for the rest. A filtered run pays for what it keeps. For competitor app reviews across a portfolio, cap per app and per storefront and let a schedule spread the work.

Which order should I schedule?

most_recent with a relative sinceDate. Every other order is for one-off pulls.

App review monitoring across a portfolio

For a studio or an agency the unit of work is a list of apps and a list of storefronts, run daily:

• appIds for every app you ship or track, countries for every market that matters, sort: "most_recent", sinceDate: "1 day".
• Route by rating: 1–2★ to support, 5★ to marketing, anything with developer_response null and rating ≤ 2 to the reply queue.
• Keep app rows: rating_avg, rating_count and the histogram per storefront per day is the app store ratings history nobody exports for you.

App review analysis that keeps its structure

Because every row carries country, version, rating and the dates, an app review analysis does not need a parser: group by version to see whether a release moved the rating, by country to find a market with a localisation problem, by week to spot a spike. iOS app feedback with the text, the stars and the metadata in the same row is what makes sentiment and topic models useful.

What this does not do

It does not read Google Play (a different store), it does not read ratings without text (Apple does not expose them per user), and it does not write reviews or replies.

Choosing between sort orders

most_helpful is what a shopper sees first and what the App Store defaults to; most_recent is chronological; most_critical and most_favorable front-load one end of the star scale and are the cheap way to sample complaints or praise.

Related scrapers

Reviews from other places customers talk, with the same row discipline, the same pay-per-delivered-row billing and the same scheduling story:

• Indeed Company Reviews Scraper — employee reviews with five sub-ratings, pros and cons, job title and location, and the employer's reply.
• Trustpilot Reviews Scraper — company reviews and TrustScore from Trustpilot, past the 200-review wall an anonymous reader normally hits.
• Google Play Reviews Scraper — the Android half of this pair: Play Store reviews per language and country, matching columns and the same pre-billing filters.
• Amazon Reviews Scraper — product reviews across 20 marketplaces, with pre-billing filters.
• Airbnb Reviews Scraper — guest reviews of any listing, minRating bills only what you keep.
• Agoda Reviews Scraper — hotel reviews with separate positives and negatives.
• Amazon Best Sellers Scraper — the Top 100 of any category with every rank filled.

All of them bill per delivered row, never charge for rows a filter or a spending limit removed, and write an Apify dataset you can export to CSV, Excel or JSON.