How to get App Store and Google Play data

Two stores, two completely different doors

Apple and Google both publish app data, and the way you get at it could not be more different. Knowing which door you are standing in front of saves you a day.

Apple has an official lookup API. It is free, it needs no key, and it returns a clean JSON object per app: title, developer, price, rating, category, version, release notes, screenshots. For single lookups it is genuinely all you need.

Google Play has no official API for app listings. There is a publishing API for your own apps, which is not the same thing at all. Anything that reads other people's listings is reading the web page, and that has consequences you will meet below.

The free routes, and where each one stops

Apple's lookup endpoint. Free and stable, but it is a lookup, not a search index: you need the app id or a bundle id up front. It also rate limits, gently at first and then not gently, which is exactly the moment your list of two thousand apps is halfway done.

Open-source scrapers. There are well-known libraries for both stores and they work on your laptop. On a server they run into the usual wall: the Play listing is rendered and localised, the markup shifts, and requests from datacentre addresses meet different pages than your browser does. The library is not badly written; it is doing something the store never promised to keep stable.

Doing it by hand. Fine for ten apps. If you are tracking a category, a competitor set, or your own portfolio week over week, the clicking is the job.

The thing that trips up rank tracking

App store rankings are per country and per language, and they are not a global truth. A keyword that puts you at four in the Netherlands can put you at forty in the United States, and a scrape that does not pin the storefront explicitly gives you whichever storefront the requesting address looks like it belongs to. Any ASO dataset built without pinning the country is not wrong in an obvious way, which is worse: it is quietly measuring somewhere else.

The same holds for prices and availability. Both are storefront-specific, and half the confusion in app data comes from mixing storefronts in one table.

What to decide before you pull

• Which storefronts. Decide the list up front and keep it fixed, so your numbers stay comparable week over week.
• Listing data or ranking data. Details about a known app is one job. Finding which apps rank for a keyword is a different one, with different inputs.
• How often. Listings change slowly, rankings change daily. Pulling both on the same schedule wastes money on one and misses movement on the other.
• Joining the two stores. There is no shared id. You match on developer and title, and you will need a manual pass for the awkward ones.

What we charge for it

Apple listing details are billed per app fetched at $1.50 per 1,000. The Play equivalent is $2.00 per 1,000, a little higher because the source is a rendered page rather than an official API. Keyword rank data for the App Store is billed per ranked app row at $0.70 per 1,000, which is the cheapest of the three because one run returns many rows.

For a portfolio of fifty apps checked daily across three storefronts, you are at a few cents a month. The cost only becomes a number worth looking at when you are tracking whole categories, and at that point you are doing market research rather than housekeeping.