App Store Scraper

App Store Scraper

Scrape the Apple App Store with no API key and no anti-bot headaches. This actor talks directly to Apple's public iTunes / App Store JSON endpoints, so results are fast, clean, and structured — app metadata and customer reviews, ready for analysis.

What it does

Two modes:

1. Search — give a searchTerm (e.g. notion) and get back matching apps with full metadata: name, developer, average rating, rating count, price, genre(s), version, release dates, description, App Store URL, artwork, screenshots, minimum OS, content rating, file size. 2. Look up by ID — give appIds (numeric trackIds like 1232780281, or bundleIds like net.shinyfrog.bear) to fetch those exact apps. Turn on Include reviews to also pull each app's customer reviews (author, rating 1–5, title, body, app version, date).

Input

Output

One dataset item per app (ok: true), with all metadata fields. In ID mode with includeReviews, each app item also carries a reviews array and a reviewsCount.

Each review: reviewId, author, rating, title, body, version, voteSum, voteCount, updated.

Nullable fields: the row always contains every documented field, but individual values can be null when Apple doesn't provide them for an app — e.g. averageUserRating, userRatingCount, releaseNotes, sellerUrl, price/formattedPrice, version. Treat any field as possibly null rather than assuming completeness.

Reviews are best-effort. reviewsCount is the number actually fetched. Apple's reviews feed serves ~50 reviews per page over up to 10 pages, and many apps simply have fewer reviews than your maxReviews. If the feed ends early or a page errors, the actor logs a warning, keeps what it collected, and still returns the app — so reviewsCount may be lower than maxReviews. That is not an error; it usually means there were no more reviews available.

If something goes wrong (bad input, rate limit, network, no results) the actor pushes a single diagnostic row with ok: false and an errorCode instead of failing silently — and never charges for it.

Sample output row

{
  "ok": true,
  "trackId": 1232780281,
  "bundleId": "net.shinyfrog.bear",
  "appName": "Bear - Markdown Notes",
  "developer": "Shiny Frog Ltd.",
  "averageUserRating": 4.6,
  "userRatingCount": 18342,
  "price": 0,
  "formattedPrice": "Free",
  "primaryGenre": "Productivity",
  "version": "2.1",
  "appStoreUrl": "https://apps.apple.com/us/app/bear-markdown-notes/id1232780281",
  "reviewsCount": 100,
  "reviews": [ { "author": "...", "rating": 5, "title": "...", "body": "..." } ]
}

Pricing

Pay-per-result: charged per app row returned (search results or looked-up apps). Diagnostic and empty rows are never charged.

Notes

• Apple's legacy customer-reviews RSS feed is occasionally empty for short periods or for apps

with few recent reviews; the actor handles this gracefully and still returns the app metadata.

• The iTunes APIs are public and unauthenticated, so **no proxy is needed and none is used by

default**. Only enable a proxy if you hit per-IP rate limits at high volume — routing this public API through Apify Proxy otherwise just spends proxy credits for no benefit.

Troubleshooting

• charged count lower than apps returned? Every successful app row is charged once; if a

charge failed: ... warning appears in the log, that row was pushed but the billing call failed (you were not billed for it). The numbers in the final Done. log line (apps, charged) are authoritative.

• Got a diagnostic row (ok: false) instead of apps? Read its errorCode/error: BAD_INPUT

means no searchTerm/appIds (or an invalid country code) — fix the input and rerun. RATE_LIMITED means lower the volume or enable a proxy. NO_RESULTS means the query matched nothing. Diagnostic rows are never charged.

• Fewer reviews than maxReviews? The app simply has fewer reviews available; see "Reviews are

best-effort" above.