App Store Reviews Dataset: Getting Review and Ratings Data from iOS and Google Play

Whether you’re benchmarking your own app, hunting for under-served niches, or building a sentiment model, you eventually need app store review data — and discover that neither Apple nor Google offers a bulk download. The data exists in public view (hundreds of millions of reviews), but getting it in analyzable form means scraping, paying an intelligence platform $2,000+/month, or settling for a stale Kaggle dump. This guide covers the practical acquisition routes, their limits, and why for many jobs the smarter buy is derived metrics rather than raw text.

How people actually get review data

Apple’s RSS feed. iTunes exposes a public JSON feed of recent reviews per app, per storefront — but only the most recent ~500 reviews (10 pages × 50):

import requests

app_id = "310633997"  # WhatsApp, US storefront
url = f"https://itunes.apple.com/us/rss/customerreviews/page=1/id={app_id}/sortby=mostrecent/json"
for e in requests.get(url).json()["feed"]["entry"][1:]:
    print(e["im:rating"]["label"], "|", e["title"]["label"], "|", e["content"]["label"][:80])

Great for monitoring your own app; useless for history or scale.

Google Play scraping libraries. google-play-scraper (Python/Node) paginates through an app’s reviews via the same internal endpoints the Play website uses. It works, at the cost of fragility (breaks when Google changes internals), throttling at scale, and living in a ToS gray zone for systematic collection.

Official APIs — for your own apps only. App Store Connect and Google Play Developer APIs return reviews for apps you publish. Perfect for reply workflows; irrelevant for competitive analysis.

Kaggle datasets. A handful of decent corpora exist for NLP coursework. All frozen snapshots of arbitrary app selections — fine for training a toy classifier, wrong for market analysis in 2026.

Intelligence platforms. Sensor Tower, data.ai, AppFollow do this well, priced for enterprises (commonly $tens of thousands/year).

The under-rated option: derived metrics instead of raw text

Here’s the thing most buyers realize late: for decision-making (as opposed to model training), raw review text is an intermediate product. What you actually want to know is:

• What share of my app’s negative reviews are about crashes, vs ads, vs billing, vs login?
• Is that share normal for my category, or am I an outlier?
• Which categories have structurally miserable users (opportunity!) — the classic strategy of hunting for high-demand, low-rating niches?

Those are classification outputs. Our complaint benchmarks dataset ships exactly that layer: 802k negative reviews from 5,592 apps classified into complaint topics, aggregated into per-app complaint profiles plus category baselines (P25/P50/P75/P90 percentile bands) for 47 App Store and Google Play categories — with per-topic “worst offender” leaderboards in the top tier. You can see the category-level layer free in our App Complaint Heatmap.

Working with profiles is ordinary dataframe work:

import pandas as pd

profiles = pd.read_csv("app_complaint_profiles.csv")
bench = pd.read_csv("category_benchmarks.csv")

# Apps whose billing-complaint share is above their category's P90
merged = profiles.merge(
    bench[["store", "primaryGenre", "billing_subscription_p90"]],
    on=["store", "primaryGenre"],
)
outliers = merged[merged["billing_subscription_share"] > merged["billing_subscription_p90"]]
print(outliers[["appName", "primaryGenre", "billing_subscription_share"]].head(10))

-- Categories where crashes dominate complaints (engineering-quality gaps)
SELECT store, "primaryGenre",
       crash_bug_p50    AS median_crash_share,
       "appsCovered"
FROM category_benchmarks
ORDER BY crash_bug_p50 DESC
LIMIT 10;

For teams that do want app-level metadata + sentiment over time (ratings, ranks, sentiment scores, topic tags, monthly trend history), that’s a separate line: our App Store & Google Play apps dataset covers 6,700+ apps across five categories as a monthly snapshot.

Reading the benchmarks like a strategist

A worked example of how the category baselines turn into decisions. Suppose you’re evaluating whether to build a budgeting app. Pull the Finance category row from the heatmap: if the median app’s negative reviews are dominated by login/account complaints (bank-connection failures are endemic to the category via aggregator APIs), that’s a structural complaint — hard for you to fix better than incumbents, since you’ll use the same aggregators. But if the P90 apps show billing-complaint shares several times the median, that’s a behavioral complaint — incumbents choosing aggressive subscription patterns — and a “fair billing” positioning attacks it directly. The percentile bands are what make this reasoning possible: a median tells you what’s normal, the P75/P90 spread tells you whether the category’s pain is concentrated in a few bad actors (opportunity via differentiation) or endemic (opportunity only via technical breakthrough).

The same logic runs defensively. Before a big release, compare your app’s complaint profile against your category’s bands: if your crash share sits at the category P75, you have quality debt that ASO spending cannot paper over — store algorithms weight recent rating trends, and crash-driven 1-star runs are the fastest way to lose a rank you paid to win. Teams that check the baseline first spend their next sprint on stability instead of acquisition, which is usually the higher-ROI call.

What people build with this

• Competitive benchmarking. “Our crash-complaint share is 2× category median” is a roadmap argument no exec ignores.
• Opportunity scanning. High-download, low-rating categories with concentrated fixable complaints are where indie replacements win.
• ASO and support triage. Complaint mix tells you what to fix before it tells the store algorithm.
• NLP research. Benchmarks make honest eval baselines for review-classification models.

If you do go the raw-collection route for a specific competitive study, one methodological tip that saves embarrassment: sample reviews by time window, not by “most recent N”. Review APIs return recency-ordered pages, so a naive pull over-represents whatever happened last month — a bad update, a viral moment — and your topic distribution reflects an episode, not the app. Pull across a fixed window (say, 12 months), weight by review volume per month, and report the window explicitly. Every benchmark number in our dataset states its collection window for exactly this reason.

Options compared

	DIY scraping	Intelligence platforms	DataForge benchmarks
Cost	Your time + breakage	$1,000s/month	From $99 one-time
History	Recent only (Apple ~500)	Deep	Snapshot editions
Coverage	Apps you pick	Huge	5,592 apps, 47 categories, both stores
Output	Raw text you must classify	Dashboards	Classified topics + category percentile baselines, CSV/Parquet
Category baselines	Build yourself	Partial	Included — the core product

Honest guidance: monitoring your own app? Use the free RSS feed / official APIs. Need raw text for a handful of specific competitors? A scraping library over a weekend works. Need to know how complaint patterns compare across a category — with baselines — that’s what the benchmarks are for, at two orders of magnitude below platform pricing. The free 500-row sample shows the exact schema.

FAQ

Is review data legal to use? Reviews are public content. We distribute derived aggregates and classifications in the benchmarks product (topic shares, percentiles), not bulk raw review text — which also sidesteps most redistribution concerns.

Which stores and countries? iOS App Store and Google Play, US storefronts, 47 categories combined.

How were topics classified? Negative reviews are classified into a fixed complaint taxonomy (crashes/bugs, ads, billing/subscription, login/account, performance, UX, support, privacy/permissions…). The datasheet documents method and validation; the heatmap tool shows the resulting category medians.

How fresh is it? Editions are dated snapshots; each package states its collection window in the datasheet.

Why not just fine-tune a sentiment model on a Kaggle corpus and classify reviews myself? You can, and for a one-off study of a few apps it’s a fine weekend project. Three things make it worse than it looks at scale. First, the collection problem doesn’t go away — you still need current reviews for the apps you care about, which puts you back in scraping territory. Second, complaint classification is harder than star-level sentiment: “love the app but the subscription tripled” is a positive-tone billing complaint, and generic sentiment models miss the topic entirely; a useful taxonomy needs labeled training data per topic. Third and least obvious: without category baselines your numbers have no meaning. Knowing your app’s billing-complaint share is 12% is useless until you know whether the category median is 4% or 20% — and building baselines means classifying reviews for hundreds of apps you don’t care about, purely for context. That context layer is most of the compute and most of the value, which is why it’s the product.

Does review data predict downloads or revenue? Directionally, within categories, with caveats. Rating level correlates with conversion on the store page (Apple and Google both surface it in search), and complaint spikes precede rating declines by days to weeks — useful as an early-warning signal. But cross-category comparisons mislead (games run structurally lower ratings than utilities), and downloads are dominated by acquisition spend you can’t see in reviews. Treat review metrics as quality diagnostics and competitive context, not as a revenue crystal ball — and be wary of anyone selling them as one.