Apple App Store Review Scraper: Complaint & Bug Finder

Apple App Store Review Scraper — Complaint & Bug Finder

Pull Apple App Store customer reviews for any iOS app and get back a pre-triaged feed of complaints and bug reports, not the whole review firehose. The Actor reads Apple's public customer-reviews feed, runs every review through a seven-stage keep/drop filter, and tags each surviving row with a deterministic issue category — crash, billing, login, sync and more — plus the exact phrases that triggered the tag. Every response is structured JSON, ready to load into a spreadsheet, a bug tracker, or an LLM context window. Point it at any App Store link and start triaging.

---

What is Apple App Store Review Scraper: Complaint & Bug Finder?

It is an Apple App Store review scraper that reads Apple's public itunes.apple.com customer-reviews feed for any app — no Apple ID, no Apple Developer account, and no login required — and passes every review through a configurable keep/drop funnel before it reaches the dataset. What sets it apart from a plain review scraper is issues.py: a published, word-boundary keyword lexicon that tags each review with an issueType (the topic it discusses), lists every issueSignals phrase that fired for that tag, and computes a separate isComplaint verdict driven by star rating. Nothing here calls a language model — the classification is deterministic and reproducible, which means the same review always gets the same tag.

Key capabilities:

• Reads any App Store link or bare numeric app ID, in any store region the link points to.
• Two feed orders: mostRecent (newest first) or mostHelpful (user-upvoted, populates vote counts).
• Six independent filter stages: star rating, required keywords, excluded keywords, minimum helpful votes, minimum review length, and duplicate-ID suppression — each one counted and reported in the run log.
• Deterministic issue tagging across ten categories, with an auditable issueSignals trail for every tag.
• isComplaint scoring that separates topic (what the review is about) from sentiment (whether it is actually a complaint).
• Per-app pacing controls (pagesPerApp, pageDelaySeconds) and automatic proxy escalation only when Apple starts refusing requests.

---

What data can you get with Apple App Store Review Scraper: Complaint & Bug Finder?

Every kept review comes back as one flat JSON row combining the original review text, Apple's engagement metrics, and this Actor's own issue classification.

Result type	Extracted fields	Primary use case
Review content	title, content, contentLength, rating, ratingStars, version, author, date, dateIso	Reading the actual complaint or bug description
Engagement signals	helpfulVotes, totalVotes, sortUsed	Prioritizing reviews other users already validated
Issue classification	issueType, issueTypes, issueSignals, isComplaint, matchedKeyword	Auto-triaging bug/complaint categories without reading every row
Provenance & identity	reviewId, reviewerProfileUrl, appStoreUrl, appId, country	Deduplication, audit trail, cross-run tracking
Run accounting	rowType, errorReason, scrapedAt	Spotting apps or pages that failed to load — logged without being billed

Deterministic issue tagging

tagIssues (default true) runs each review's title and body through ten ordered keyword categories — crash, bug, login_auth, billing, data_sync, performance, ads, ui_ux, support, feature_request — using word-boundary regex matching (crash matches "the app crashed" but not "crashers"). The first category with a hit becomes issueType; every category that hit becomes an entry in issueTypes; the literal phrases that fired go into issueSignals, so any tag can be checked against the source text:

{
  "issueType": "billing",
  "issueTypes": ["billing", "support"],
  "issueSignals": ["subscription", "refund", "customer service"],
  "isComplaint": true
}

A review that matches nothing gets issueType: null — never a guessed category. issueType marks the topic, not the sentiment: a 5-star review that says "premium with no ads" is still tagged ads.

Helpful-vote engagement data

helpfulVotes (Apple's im:voteSum) and totalVotes (im:voteCount) tell you how many other App Store users already validated a review before you read it. Apple's own feed populates these two fields far more reliably on the mostHelpful feed than on mostRecent — the Actor's schema documents a measurement taken 2026-07-19 across two independent 10-app samples of the US storefront (pages 1–3, n=1,500 reviews each): 44.5–47.7% of mostHelpful reviews carried a non-zero vote count, versus 3.1–3.9% of mostRecent reviews. Use sortBy: mostHelpful when helpfulVotes matters to your triage.

---

⚠️ Why not build this yourself?

Apple does not publish a search or query API for reading an arbitrary app's reviews. The only Apple-hosted alternative is the App Store Connect API, and it only returns reviews for apps you own, gated behind a signed JWT and a developer account — it cannot audit a competitor's app or a portfolio you don't control. The only route to third-party App Store reviews is the same public customerreviews RSS/JSON feed this Actor reads, and building a reader for it yourself means re-solving several problems this Actor already handles:

• The pagination ceiling isn't documented anywhere — you find it by hitting HTTP 400 on page 11. This Actor hard-stops at page 10 (HARD_PAGE_CEILING) so a misconfigured pagesPerApp never wastes a request on a page Apple will reject.
• Two of the four sort values silently die. mostCritical and mostFavorable return HTTP 500 with zero entries (measured live 2026-07-19, 24/24 trials) — a naive client would see an empty result and assume the app has no reviews.
• Blocking escalation — this Actor starts every app with no proxy at all, and only steps up to a datacenter, then a locked-in residential proxy, if Apple's feed starts refusing requests. Building that tiering yourself means writing and testing retry/backoff logic from scratch.
• Turning raw review text into a triage queue means building and maintaining your own keyword lexicon — this Actor ships one, with an audit trail, out of the box.

Building your own reader makes sense if you need a shape this Actor doesn't produce. For triaging complaints and bugs out of Apple's public review feed, this Actor already does the parsing, the pacing, and the classification.

---

What is the difference between an App Store review scraper and a bug/complaint tracker?

A plain App Store review scraper returns the raw feed: every star rating, every one-line "great app!" review, and every real complaint mixed together — you still have to read all of it to find the handful of reviews that describe an actual defect. A bug/complaint tracker, by contrast, is a review scraper that also classifies: it decides which reviews are actionable feedback and which are just noise.

That distinction matters because the raw feed doesn't scale past a handful of apps — a popular app can carry hundreds of reviews per store region, and most of them are pure sentiment with no describable issue. What changed is that teams now want the triage step done at collection time, not after a human has read 500 rows.

Apple App Store Review Scraper: Complaint & Bug Finder returns both. Every row carries the raw review (title, content, rating) exactly as Apple wrote it, and the classification layer (issueType, issueTypes, issueSignals, isComplaint) sits alongside it in the same JSON object — so you can use it as a plain review scraper by ignoring the tag fields, or as a bug tracker feed by filtering on onlyReviewsWithIssues.

---

How to scrape Apple App Store reviews with Apple App Store Review Scraper: Complaint & Bug Finder?

1. Open the Actor on its Apify Store listing and click Try for free (or Run, if you already have it saved).
2. Add App Store links. Fill in appStoreLinks with one App Store URL or bare numeric app ID per row — e.g. https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194.
3. Set the funnel. Pick sortBy, restrict keepStarRatings (1–2 stars for complaint triage), add mustContainKeywords / mustNotContainKeywords, and set onlyReviewsWithIssues if you only want tagged rows.
4. Start the run. The Console shows a live log line per page scanned, and a per-app summary of how many rows each filter stage dropped.
5. Download or stream the results as JSON, CSV, Excel, or XML from the run's dataset, or pull them with the Apify API / apify-client.

Real request body using the Actor's own parameter names:

{
  "appStoreLinks": ["https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194"],
  "sortBy": "mostHelpful",
  "keepStarRatings": ["1", "2"],
  "onlyReviewsWithIssues": true
}

How to run multiple apps in one job

appStoreLinks accepts an array of stringList rows, so a competitor sweep or a multi-app portfolio audit is one run: add one link per app and every one shares the same funnel settings. Internally the Actor processes apps one at a time in sequence inside a single shared HTTP session — it does not fetch multiple apps in parallel — so a large appStoreLinks list with a high reviewsPerApp will take proportionally longer, not shorter, per additional app.

---

⬇️ Input

All 14 parameters are optional — the Actor runs with defaults if you supply nothing but appStoreLinks.

Parameter	Required	Type	Default	Constraints
appStoreLinks	No	array of string	[]	editor: stringList. One URL or bare app ID per row. Base keys url / urls are merged in.
reviewsPerApp	No	integer	20	min 1, max 500
sortBy	No	string	"mostRecent"	enum "mostRecent", "mostHelpful"
keepStarRatings	No	array of string	[]	enum items "1"–"5"
mustContainKeywords	No	array of string	[]	editor: stringList, case-insensitive substring
mustNotContainKeywords	No	array of string	[]	editor: stringList, case-insensitive substring
minHelpfulVotes	No	integer	0	min 0
minReviewLength	No	integer	0	min 0, counts characters of content
dedupeByReviewId	No	boolean	true	—
tagIssues	No	boolean	true	—
onlyReviewsWithIssues	No	boolean	false	forces tagIssues on if it was off
onlyIssueTypes	No	array of string	[]	enum: crash, bug, login_auth, billing, data_sync, performance, ads, ui_ux, support, feature_request
pagesPerApp	No	integer	10	min 1, max 10
pageDelaySeconds	No	integer	2	min 0, max 30
proxyConfiguration	No	object	{ "useApifyProxy": false }	editor: proxy

Full parameter notes (from the input schema):

• appStoreLinks — the store region is read from the /xx/ segment of the link (apps.apple.com/gb/app/... → gb); a link with no region segment, or a bare app ID, defaults to us.
• reviewsPerApp — counts kept rows, not scanned ones. With a tight funnel, the Actor may scan all 500 available reviews to fill 20 slots.
• minHelpfulVotes — only meaningful with sortBy: mostHelpful; on mostRecent almost no reviews carry a vote count (see the engagement-data section above), so a threshold there drops nearly everything. The run log prints a warning when you combine them.
• onlyIssueTypes — restricts kept rows to the listed primary issueType values; leaving it empty keeps every tagged (and untagged) row that otherwise passes the funnel.
• pagesPerApp — the base keys max_pages / maxPages are also accepted, for input JSON copied from the base actor.
• pageDelaySeconds — the base keys delay_between_pages / delayBetweenPagesSeconds are also accepted. A small random jitter is added on top of whatever value you set.
• proxyConfiguration — Apple's review feed is keyless and works with no proxy configured at all; the Actor only escalates to a datacenter, then a residential, proxy tier if the store starts refusing requests.

Example JSON input

{
  "appStoreLinks": [
    "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194"
  ],
  "reviewsPerApp": 50,
  "sortBy": "mostHelpful",
  "keepStarRatings": ["1", "2"],
  "mustNotContainKeywords": ["love it", "five stars"],
  "minHelpfulVotes": 3,
  "minReviewLength": 120,
  "dedupeByReviewId": true,
  "tagIssues": true,
  "onlyReviewsWithIssues": true,
  "onlyIssueTypes": ["crash", "bug", "billing"],
  "pagesPerApp": 10,
  "pageDelaySeconds": 2
}

Common pitfall: setting minHelpfulVotes while leaving sortBy on its default (mostRecent) will drop almost every review, because Apple barely populates vote counts on the recency feed. Switch sortBy to mostHelpful first, then apply a vote threshold.

The filter funnel, in order

Every scanned review runs through these stages, top to bottom. A review only reaches the next stage if it survives the one before it, and every drop is counted per app in the run log:

#	Stage	Controlled by	Drops a review when
1	Duplicate suppression	dedupeByReviewId	its Apple reviewId was already kept earlier in the run
2	Star rating	keepStarRatings	its ratingStars isn't in the selected set (skipped if empty)
3	Required keyword	mustContainKeywords	none of the listed terms appear in title + body (skipped if empty)
4	Excluded keyword	mustNotContainKeywords	any listed term appears in title + body
5	Helpful-vote threshold	minHelpfulVotes	helpfulVotes is below the threshold
6	Minimum length	minReviewLength	contentLength is below the threshold
7	Issue-tag filter	onlyReviewsWithIssues / onlyIssueTypes	the row has no issueType, or its issueType isn't in the selected set

A row that survives every stage is pushed to the dataset and counted toward reviewsPerApp.

---

⬆️ Output

Every result is typed, normalized JSON with a consistent schema across runs. Export it as JSON, CSV, Excel, or XML from the dataset, or read it directly with the Apify API.

Output field reference

A kept review (rowType: "review") carries all 25 of these fields. An accounting row (rowType: "error") carries only rowType, errorReason, appStoreUrl, appId, country and scrapedAt — the rest are absent, not null.

Field	Type	Description
rowType	string	"review" for a kept review, "error" for an uncharged accounting row
issueType	string | null	Highest-priority issue category that fired, or null if nothing matched
issueTypes	array of string	Every issue category that fired, in lexicon priority order
issueSignals	array of string	The literal phrases matched, deduplicated — the audit trail for the tag
isComplaint	boolean	true at 1–2 stars, or 3 stars with a non-feature_request tag; always false at 4–5 stars
ratingStars	integer | null	rating parsed to an integer, so the dataset table sorts numerically
helpfulVotes	integer | null	Apple's im:voteSum — how many users marked the review helpful
totalVotes	integer | null	Apple's im:voteCount — total votes cast on the review
title	string	Review title, as written
content	string	Review body, as written
matchedKeyword	string | null	Which mustContainKeywords term fired on this row, if that stage ran
author	string	Reviewer's public nickname
version	string	App version the review was written against
dateIso	string | null	Review date normalized to UTC, YYYY-MM-DDTHH:MM:SSZ
date	string	Apple's original timestamp, with its store-region UTC offset
contentLength	integer	Character count of content
sortUsed	string	Which feed (mostRecent / mostHelpful) produced this row
reviewId	string | null	Apple's stable review ID — the dedup and cross-run tracking key
reviewerProfileUrl	string | null	Reviewer's Apple profile URL
appStoreUrl	string	The App Store link supplied in appStoreLinks for this row's app
appId	string | null	Numeric Apple app ID, parsed from the link
country	string	Store region code parsed from the link, or us if none was present
rating	string	Apple's raw rating string, unchanged
errorReason	string | null	Typed failure reason on an accounting row; null on a review row
scrapedAt	string	UTC timestamp the row was written

🐞 Scraped results

A kept review row (rowType: "review") carries all 25 fields the Actor writes. Here are three, showing a billing complaint, a crash tag, and a 5-star review that still gets a topic tag without being marked a complaint:

[
  {
    "rowType": "review",
    "issueType": "billing",
    "issueTypes": ["billing", "support"],
    "issueSignals": ["subscription", "refund", "customer service"],
    "isComplaint": true,
    "ratingStars": 1,
    "helpfulVotes": 62,
    "totalVotes": 96,
    "title": "Cancelled and still charged",
    "content": "I cancelled my subscription in April and was still charged in May. Customer service never answered my refund request.",
    "matchedKeyword": null,
    "author": "Renee CatWig",
    "version": "3.9.1",
    "dateIso": "2026-07-16T12:52:31Z",
    "date": "2026-07-16T05:52:31-07:00",
    "contentLength": 118,
    "sortUsed": "mostHelpful",
    "reviewId": "11994640656",
    "reviewerProfileUrl": "https://itunes.apple.com/us/reviews/id1286065133",
    "appStoreUrl": "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194",
    "appId": "1449777194",
    "country": "us",
    "rating": "1",
    "errorReason": null,
    "scrapedAt": "2026-07-19T10:31:04Z"
  },
  {
    "rowType": "review",
    "issueType": "crash",
    "issueTypes": ["crash", "bug"],
    "issueSignals": ["force close", "stuck on loading"],
    "isComplaint": true,
    "ratingStars": 1,
    "helpfulVotes": 41,
    "totalVotes": 55,
    "title": "Unusable since the update",
    "content": "App force closes every time I open the budget tab. Been stuck on loading for a week now, please fix.",
    "matchedKeyword": "crash",
    "author": "budgetbrianna",
    "version": "3.9.1",
    "dateIso": "2026-07-14T18:03:12Z",
    "date": "2026-07-14T11:03:12-07:00",
    "contentLength": 103,
    "sortUsed": "mostHelpful",
    "reviewId": "11987552310",
    "reviewerProfileUrl": "https://itunes.apple.com/us/reviews/id1102384772",
    "appStoreUrl": "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194",
    "appId": "1449777194",
    "country": "us",
    "rating": "1",
    "errorReason": null,
    "scrapedAt": "2026-07-19T10:31:06Z"
  },
  {
    "rowType": "review",
    "issueType": "ads",
    "issueTypes": ["ads"],
    "issueSignals": ["ad free"],
    "isComplaint": false,
    "ratingStars": 5,
    "helpfulVotes": 9,
    "totalVotes": 11,
    "title": "Worth every cent",
    "content": "Premium is ad free and the sync across devices just works. Best budgeting app I've tried.",
    "matchedKeyword": null,
    "author": "finance_nerd22",
    "version": "3.9.0",
    "dateIso": "2026-07-11T09:44:01Z",
    "date": "2026-07-11T02:44:01-07:00",
    "contentLength": 92,
    "sortUsed": "mostHelpful",
    "reviewId": "11970118845",
    "reviewerProfileUrl": "https://itunes.apple.com/us/reviews/id1355029210",
    "appStoreUrl": "https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194",
    "appId": "1449777194",
    "country": "us",
    "rating": "5",
    "errorReason": null,
    "scrapedAt": "2026-07-19T10:31:07Z"
  }
]

If an app can't be read at all (blocked, bad link, or every review filtered out), the Actor writes an uncharged accounting row instead of silently returning nothing. That row only carries six fields — the rest are simply absent, not null:

{
  "rowType": "error",
  "errorReason": "invalid_app_url",
  "appStoreUrl": "not-a-real-app-url",
  "appId": null,
  "country": "us",
  "scrapedAt": "2026-07-19T10:31:09Z"
}

errorReason takes one of: network_error, http_<status> (e.g. http_403), invalid_app_url, or all_reviews_filtered_out (every scanned review for that app was dropped by your funnel).

---

Pay-per-event pricing

This Actor charges on the row_result event, fired once per kept review row (Actor.push_data(row, charged_event_name="row_result")). Accounting rows (rowType: "error") are pushed without a charged-event name and are not billed — a blocked app, an invalid link, or a run where every review was filtered out never costs you anything beyond the rows that did get kept. To isolate the uncharged rows in your own export, filter on rowType == "error".

---

How can I use the data extracted with Apple App Store Review Scraper: Complaint & Bug Finder?

• 📱 Product and QA teams: filter to keepStarRatings: ["1","2"] plus onlyIssueTypes: ["crash","bug"] right after a release ships, and get a version-tagged (version field) list of defect reports instead of reading every incoming review by hand.
• 🤖 AI engineers and LLM developers: run the Actor, receive structured JSON with content and issueSignals already attached, and pass it straight into an LLM as grounding context for an automated triage or summarization agent — no separate classification step needed before the prompt.
• 📈 Market researchers and competitive intelligence: point appStoreLinks at a competitor's app ID, sort by mostHelpful, and read only the billing or support tagged rows to see what is actually driving their churn.
• 🎧 Support and ASO teams: use matchedKeyword and issueType together to spot a recurring named-feature complaint (a specific screen, a specific integration) that is dragging the star rating down, before it becomes a support-ticket spike.

---

📈 How do you monitor complaint and bug trends over time?

Monitoring here means running the same appStoreLinks set on a recurring schedule and diffing the issue-tag mix between runs, not re-reading every review from scratch each time. Because tagIssues is deterministic, the same review always produces the same issueType — so a shift in the distribution between two runs reflects a real change in what users are reporting, not noise from a classifier.

The fields worth diffing run over run: the count of rows per issueType (is crash suddenly the top tag after a release?), the isComplaint rate at a given version, and the matchedKeyword hits if you're tracking a named feature or bug by keyword. Cross-reference spikes against version to catch a regression the moment reviews start naming it, days before it would otherwise reach a support queue.

A concrete loop: save a run configuration as an Apify task with a fixed appStoreLinks list and onlyReviewsWithIssues: true, attach an Apify schedule (daily or weekly), and after each run compare the new dataset's issueType counts against the previous run's — either by hand, by exporting to a spreadsheet, or by piping both datasets through a script. Alert when a category's share jumps sharply between two runs of the same app.

---

Integrate Apple App Store Review Scraper: Complaint & Bug Finder and automate your workflow

Apple App Store Review Scraper: Complaint & Bug Finder works with any language or tool that can send an HTTP request, through the Apify API and its official client libraries.

REST API with Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/apple-app-store-review-scraper-complaint-bug-finder").call(
    run_input={
        "appStoreLinks": ["https://apps.apple.com/us/app/quicken-simplifi-budget-smart/id1449777194"],
        "sortBy": "mostHelpful",
        "keepStarRatings": ["1", "2"],
        "onlyReviewsWithIssues": True,
    }
)

for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(row["issueType"], "-", row["title"])

Swap <YOUR_APIFY_TOKEN> for your Apify API token (Console → Settings → Integrations) and <YOUR_USERNAME> for the account this Actor is saved or published under. The same pattern works from Node.js with apify-client, or from any HTTP client via POST https://api.apify.com/v2/acts/<actor-id>/runs.

Scheduled monitoring and delivery

The Actor has no built-in scheduler of its own; recurring runs are handled by the Apify platform. Save an input as a task, attach an Apify schedule (cron-based), and either poll the dataset via the API after each run or fire an Apify webhook on ACTOR.RUN.SUCCEEDED to push new rows into your own service, Slack, or a database.

---

Is it legal to scrape Apple App Store reviews?

Yes — Apple App Store review text is publicly accessible on any app's public listing page, and this Actor returns only what any visitor to that page can already read. Courts have found that scraping publicly accessible web data does not, by itself, violate the U.S. Computer Fraud and Abuse Act (hiQ Labs, Inc. v. LinkedIn Corp., 9th Cir., 2019).

App Store reviews are consumer feedback about a business's product, not personal data in the GDPR/CCPA sense — Apple exposes a pseudonymous nickname and profile URL, never a real name, email, or contact detail. The applicable framework here is Apple's own terms of service governing automated access, plus ordinary database-rights considerations, rather than data-protection law. Scraping for a one-off research report and scraping to build a permanently stored, continuously updated dataset carry different risk profiles. Consult your legal team for commercial use cases involving bulk data storage.

---

❓ Frequently asked questions

Do I need an Apple Developer account or API key?

No. The customer-reviews feed this Actor reads is public and keyless — no Apple ID, no App Store Connect credentials, no API key of any kind.

Which App Store regions can I scrape?

Whichever one appears in the link you give it. The store region is read from the /xx/ segment of the App Store URL (apps.apple.com/gb/app/... → the UK store); a link with no region, or a bare app ID, defaults to us. There is no separate country dropdown — the URL is the region control.

What's the difference between sortBy: mostRecent and mostHelpful?

mostRecent returns the newest reviews first; mostHelpful returns the reviews other users voted up, and is the feed where Apple actually populates helpfulVotes and totalVotes (see the engagement-data section above). Apple's other two sort values, mostCritical and mostFavorable, are retired — they return HTTP 500 on every app tried — so only these two are offered in the sortBy dropdown.

How does this Actor handle Apple's anti-bot measures?

It starts every app with no proxy at all, since the feed is normally open. If Apple's feed starts returning 403/429 or empty responses, the Actor retries with backoff, then escalates to a datacenter proxy, then locks in a residential proxy for the rest of that app's run. You don't need to configure any of this — proxyConfiguration is optional and defaults to no proxy.

Does the issue tagging use AI?

No. tagIssues runs a fixed, published keyword lexicon (crash, bug, login_auth, billing, data_sync, performance, ads, ui_ux, support, feature_request) against each review's title and body with word-boundary regex matching — no model call, no API key, no extra request. Every tag ships with the literal issueSignals phrases that produced it, and a review that matches nothing gets issueType: null rather than a guessed category.

How many reviews can I get per app?

Up to reviewsPerApp's maximum of 500 — that's Apple's own hard ceiling for a single app in a single store region (the feed serves 50 reviews per page and page 11 returns HTTP 400). reviewsPerApp counts rows that passed your funnel, not rows scanned, so a tight filter can mean the Actor reads all 500 available reviews to fill a smaller reviewsPerApp target.

Why did my run scan hundreds of reviews and keep only a handful?

Your filters did their job. Every stage that drops a row — duplicate ID, star rating, required/excluded keyword, vote threshold, length, issue-type filter — is counted, and the final log line for each app reports the breakdown (for example, "scanned 500, kept 12 — dropped 401 × star rating, 87 × keyword not found").

How do I monitor complaint and bug trends over an app's reviews over time?

Save the run as an Apify task with onlyReviewsWithIssues: true, attach a schedule, and compare each new run's issueType counts (and isComplaint rate) against the previous run for the same app. See the monitoring section above for the full loop.

Does this Actor work with Claude, ChatGPT, and AI agent frameworks?

It is callable as a standard HTTP endpoint via the Apify API and apify-client, which any agent framework can call — an agent issues a run, retrieves the structured JSON dataset, and grounds its answer in real review text and issue tags. This Actor does not currently ship an MCP server integration.

How does this Actor compare to other Apple App Store review scrapers?

As observed on the Apify Store, checked 2026-07-25: the base scraped/apple-app-store-review-scraper listing returns raw reviews with no filtering or tagging and states the same 500-review Apple ceiling this Actor documents. jdtpnjtp/apple-app-store-scraper's listing advertises app metadata, developer-response text, and time-period filtering (1d/7d/30d/etc.) across "50+ countries," none of which this Actor extracts. johnvc/apple-app-store-reviews-api's listing advertises a mostcritical/mostfavorable sort option, MCP server integration, and pay-per-event pricing of $0.02 setup + $0.0015/review — figures from their listing, not measured here. None of the three advertise deterministic issue-type classification or an issueSignals audit trail; that keep/drop funnel and tagging layer is what this Actor adds on top of the raw feed.

Can I use this Actor without managing proxies or App Store credentials?

Yes. There are no Apple credentials to supply at all — the feed is public. Proxy handling is fully automatic: the Actor runs with no proxy by default and only escalates tiers itself if Apple's feed starts refusing requests, so proxyConfiguration can be left at its default in almost every run.

---

💬 Your feedback

Found a bug, a field that doesn't match what Apple actually sends, or an issue-tag lexicon gap? Let us know through the Apify Console's Issues tab on this Actor's page, or via the Scrapier support contact listed on the Actor's Store page. Bug reports and lexicon suggestions get folded back into the next update.