Run an App Store search and keep the result set as rows. Apple gives developers their own download numbers but never the competitive picture - no Search Console, no rank report, no view of who else appears for the terms that matter to you. Capturing the search itself is the only way to see it.
You describe the search you'd otherwise type into the App Store, and the job hands back the apps it returned as rows you can sort, diff and file.
One row per app returned, tagged with the query it came from - so a run across a whole keyword set still reconciles back to your input list.
App Analytics tells you how your own app performed. It says nothing about who else showed up for a term, or where you sat among them. That view has to be collected.
Competitors aren't the apps you'd name in a deck - they're the ones a user sees alongside you when they search. A result set defines that set for you.
Search results are a point in time. Re-run the same keyword set on a cadence and the diff between exports is your visibility trend - entries, exits and movement.
Each run gives you the App Store listings that came back for your terms, one row per app, tagged with the query that produced it - so a keyword set becomes a table rather than a series of screenshots.
We don't print a fixed column list on this page. Store layouts and the detail exposed in a result change over time, and a list that drifts out of date is worse than none - the header row of an actual run is always the authoritative answer. That's part of what the free tier is for: pull one keyword set, read the columns, then decide how to model it.
Taken from real exports of 700 results. Two of the nine came back empty on every single row, and what the search returns is broader than apps - both are covered below.
audiobook, feature-movie, tv-episode, song and podcast.Two things this export does not do. rating and reviews are present as columns but were empty on all 700 rows, so no rating analysis is possible from this output. And the results were entirely store media rather than apps - 383 audiobooks, 107 films, 93 TV episodes, 74 songs and 43 podcasts, with no app result in the set. Order is still meaningful as returned, so the position a result holds for a term is readable; treat the item type as whatever kind says rather than assuming an app.
Anyone who has done SEO expects a rank report. App Store optimisation doesn't come with one.
On the web you have two independent views: Search Console tells you how your pages performed, and a SERP scrape tells you the whole competitive picture. On the App Store you only get the first half. Apple's App Analytics reports impressions and conversions for your app, but nothing about the result page it appeared on - not who ranked above you, and not what changed when your position moved.
That asymmetry is why keyword visibility work on mobile is so often done from memory or from a screenshot someone took last month. Capturing the result set turns it into something you can hold: a table per keyword, dated, diffable against the last run.
One caveat, stated rather than buried: in the exports behind the data dictionary above - 700 results across four runs - every row came back as store media rather than an app: audiobooks, films, TV episodes, songs and podcasts. The result set for a term is captured faithfully and in order, but if app-specific rank tracking is what you need, check a search of your own on the free tier first and confirm the kind column returns what you expect.
The useful pairing is with reviews. Search tells you who you're up against for a term; the AppStore Reviews Scraper tells you why users pick them - and, cut by version, whether their latest release helped or hurt.
A few examples of how teams use App Store search data.
Fix a keyword set that matters to your category and re-run it on a cadence. The diff between exports shows where you gained or lost ground - and, unlike a rating average, it moves fast enough to attribute to a metadata change.
Search a term you care about and read what actually comes back. Teams routinely discover that the app taking their traffic is one nobody in the building had heard of, because it wasn't on the internal competitor list.
Before committing to an app idea, search the terms your future users would. A dense result set of established apps is a different proposition from a thin one - and far cheaper to discover now than after a build.
No subscription, no minimum, no per-keyword licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked, full feature set - enough to pull a keyword set and see how you want to model it.
Roughly $2 per 1,000 results. The pre-flight estimator shows the count and credit cost before a run starts - no surprises, no compute units to translate.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for continuous visibility tracking across a big term list. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Search finds the competitive set. Reviews explain it.
Take the apps a search surfaced and pull their reviews - rating, verbatim text, votes and the version each was written against. The clearest read on why users choose them.
Plenty of app discovery still starts on the web. Track the same terms on Google to see which landing pages and review roundups send installs your way.
Short answer: yes for the public result set - and that is all we ever collect.
Search results are public. Apple shows anyone the apps that come back for a term, signed in or not, and nothing in a result set is private to a developer. Collecting publicly visible listings for competitive and market research is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
The caveat we state on every platform page: Apple's terms restrict automated access, so this is a terms question as much as a legal one. If you have a developer agreement with Apple, check it - that call is yours to make, not ours to make for you.
We touch nothing behind a login, collect no user or install data, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
500 one-time free rows on every new account - no expiry. After that it's $0.002 per row, pay-as-you-go - no card on file until you say so.
Livescraper's AppStore Search Scraper turns an App Store search into structured rows. You enter the terms you want covered, pick an output format, and download the apps that came back as CSV, JSON or Excel - one row per result, tagged with the query that produced it.
The reason this data is worth collecting is that Apple doesn't provide it. App Analytics reports impressions and conversions for your own app, but says nothing about the result page it appeared on - not who ranked above you, not your position among them, and not what shifted when that position moved. There is no App Store equivalent of Search Console's competitive view, so the only way to see the result set is to capture it.
Growth and ASO teams fix a keyword set and re-run it on a cadence, using the diff between exports as a visibility trend that moves fast enough to attribute to a metadata change. Competitive teams routinely discover that the app taking their installs was never on the internal competitor list. Product teams search the terms their future users would, because a dense result set of established apps is a very different proposition from a thin one - and far cheaper to learn now than after a build.
Because store layouts and the detail exposed in a result change over time, the header row of an actual run is the authoritative column reference rather than a list printed on a page. Pair it with the AppStore Reviews Scraper and the picture completes: search tells you who you're competing with for a term, reviews tell you why users pick them. Start free - your first 500 rows cost nothing and need no credit card.