App Store Scraper

Read the Apple App Store as data. Search any country's storefront, look up specific apps by link or bundle id, list everything a developer has published, or pull a top chart. Every row carries the ratings, the price, the version history, the screenshots and the store description, and customer reviews can be attached to any of them.

Four ways to ask

Search. Give it terms, one per line, and get up to 200 apps per term with the full record for each. This is the mode for market research: what exists in a category, who publishes it, how it is rated and what it costs.

Specific apps. Paste App Store links, numeric ids or bundle ids in any mix. A link copied from any storefront works, tracking parameters and all. Use this to track a set of competitors over time.

Developer's apps. Give it a developer id and get their whole catalogue. The id is on every app row as developer_id, so you can search once, spot a publisher worth watching, and pull everything they have made.

Top charts. Top free, top paid, top grossing and new, per country, with the rank on every row. Narrow to a category with a genre id, for example 6014 for Games or 6008 for Photo & Video.

Storefronts are not interchangeable

Everything Apple returns is per country: which apps exist, what they cost, how they are rated and what people wrote about them. An app can rank in the US and not be listed in Germany at all. The Storefront input takes a two-letter country code and every row records which storefront it came from, so a run across several countries stays sortable rather than silently mixed.

If a lookup returns nothing, the country is the first thing to check. That is reported as not_found with the storefront named, rather than as a bad id.

Reviews, and the honest limits

Turn on Include reviews and each app gets a reviews array: the rating, the title, the text, the author, the app version reviewed and the date.

Two things to know, because they are properties of Apple's feed rather than choices this actor makes.

The ceiling is 100 reviews per app per storefront. Apple serves reviews in pages of fifty and stops after two. This was measured rather than assumed: the first two pages return fifty each with no overlap between them, and the third page was never served across twenty attempts. Asking for more returns the ceiling. If you need more than 100, run the same app against several storefronts; the reviews differ per country.

The feed answers most requests with nothing, so it has to be retried. The same reviews URL returns fifty reviews on one attempt and an empty page on the next, minutes apart, with no error either time. This actor retries until it is served, which is what the Review retry budget input controls. The default of 10 is comfortable; lower it and you get fewer reviews rather than a failure.

Because of that, every row says which outcome it got in reviews_status:

Value	Meaning
complete	Both pages served
partial	One page served, the other was refused
none	Served, and the app genuinely has no reviews
not_served	The feed refused every attempt. We do not know whether reviews exist

That last distinction is the one that matters. Plenty of tools report an empty reviews feed as "this app has no reviews", which is a confident and wrong statement about an app with millions of them. This one tells you it could not find out, and lists the app under reviews_not_served in the errors record so you can rerun just those.

What a row looks like

• app_id, bundle_id, title, url — the identifiers
• developer, developer_id, developer_url, seller, seller_url
• price, currency, is_free
• rating, rating_count, rating_current_version, rating_count_current_version
• version, released_at, updated_at, release_notes, size_bytes
• description, primary_genre, genres, genre_ids, content_rating, advisories
• minimum_os, supported_devices, languages
• icon_url, screenshots, ipad_screenshots
• country, search_term, position, and chart_rank on chart rows
• reviews, review_count_returned, reviews_status when reviews were asked for

Ratings come in two flavours on purpose. rating and rating_count cover the app's whole history; rating_current_version covers only the release that is live now. A big gap between them usually means a recent update changed how people feel about it, which is the signal you actually want.

Errors

An input that fails becomes an entry in the errors record rather than a missing row:

Code	Meaning
bad_input	Not an App Store link, id or bundle id
not_found	No app with that id in the storefront you chose
no_results	The search term matched nothing
fetch_failed	Apple could not be reached after several attempts
reviews_not_served	The reviews feed refused every attempt for that app

Run sizes

The catalogue side is fast: search, lookup, developer and chart calls come back in well under a second each, and a run of a hundred apps finishes in seconds.

Reviews are the slow half, because of the retrying described above. Budget roughly a few seconds per app and prefer smaller batches when you want reviews. If you are collecting catalogue data only, leave Include reviews off and runs stay fast and cheap.

The default memory of 512 MB is comfortable for any run size, since nothing is held but JSON.

Related actors

For the Google Play side of the same question, use Google Play Scraper. For what people search for in an app store rather than what is in it, look at the keyword actors. For reviews on the open web rather than in the store, use Trustpilot Reviews or G2 Reviews.