I got tired of scraping app reviews twice, so I unified both stores

Boris Radevic — Sun, 23 Aug 2026 22:49:53 +0000

Every app review pipeline I've seen starts the same way: one scraper for Google
Play, a different one for the App Store, and then a normalization layer to make
score and im:rating pretend to be the same field. You write that glue code
once, it breaks quietly, and you write it again.

The raw sources, if you want to DIY it: Apple still serves a public RSS feed at
itunes.apple.com/{country}/rss/customerreviews/... — no auth needed, but it
caps at roughly 500 recent reviews per app per country, and nobody tells you that
until you hit it. For Play there are the open-source google-play-scraper
libraries, which work fine until Google shifts an internal endpoint and they
don't.

There's also the subscription route. Appfigures starts at $9.99/month and Appbot
at $49/month, and they're good products — dashboards, alerts, sentiment, the
whole suite. But if your actual need is "give me the reviews as data", paying for
a dashboard you'll never open feels wrong.

So I built App Review Monitor
on Apify. You pass apps from either store, it returns every review in one schema:

{
    "store": "apple",
    "appId": "310633997",
    "country": "us",
    "date": "2026-08-20T14:03:11.000Z",
    "rating": 2,
    "title": "Latest update broke uploads",
    "text": "Since the last version ...",
    "appVersion": "26.16.81",
    "author": "reviewer_a1b2c3d4e5f6"
}

Same ten fields whether it came from Play or the App Store. Pipe it into an LLM
for a theme digest, a sheet for support triage, whatever.

That author field is a hash, not a name. On purpose. Review text is what you
analyze; the reviewer's display name is GDPR liability you almost never need, so
anonymization is the default and including real names is an explicit opt-in.

The other opinionated choice: failures are loud. Apps that couldn't be fetched
get listed in the run summary, and if every app fails the run exits FAILED
instead of handing you an empty dataset with a green checkmark. Monitoring that
fails silently isn't monitoring.

Disclosure: I build and maintain this with AI assistance on my own account, and
it collects only publicly available review data.

Google Trends still has no API in 2026. Here's what I use instead

Boris Radevic — Sun, 23 Aug 2026 22:49:47 +0000

Google announced a Trends API alpha in July 2025. It's now August 2026 and access
is still application-gated. I applied, waited, heard nothing, and eventually built
my own thing.

If you just need trends data in a pipeline or a spreadsheet, here's the honest
lay of the land.

The official alpha is worth applying for anyway — official beats scraped every
time, and if your application goes through and the quotas fit, stop reading here.
Mine didn't go through.

The commercial SERP APIs (DataForSEO, SerpAPI) all have Trends endpoints. They
work. They also start around $50-75/month, which is a strange amount of money to
pay when you want to check thirty keywords once a week. If you're doing enterprise
volume, fine, that's your answer.

I wasn't doing enterprise volume. So I built
Google Trends Explorer on
Apify — you pass keywords, a region and a time range, and get one JSON item per
keyword back:

{
    "keyword": "notion templates",
    "geo": "worldwide",
    "timeRange": "today 12-m",
    "latestValue": 33,
    "averageValue": 68.6,
    "peakDate": "May 3 - 9, 2026",
    "interestOverTime": [{ "date": "Aug 2025", "value": 48 }],
    "relatedQueries": {
        "top": [{ "query": "templates for notion", "value": 100 }],
        "rising": [{ "query": "notion marketplace", "change": "+250%" }]
    }
}

The latestValue / averageValue / peakDate fields are there because half the
time that's all you actually wanted — feeding a 54-point series to an LLM so it
can tell you "interest peaked in May" is a waste of tokens.

Some things you should know before trusting any Trends data, from any source:
the values are Google's sampled, relative 0-100 index within whatever range and
region you picked. Run the same query twice and small numbers can wiggle. It's a
signal for "is this topic growing or dying", not a measurement.

And Google rate-limits these endpoints hard. My actor rotates proxy sessions and
backs off on 429s, but I made one design decision I'd defend anywhere: if every
keyword fails, the run exits FAILED. Loudly. I've been burned by scrapers that
return an empty array and call it success — you find out three weeks later that
your "data pipeline" has been shipping nothing.

Full disclosure: I build and maintain this with AI assistance, on my own account,
and it only touches public aggregate data. If the official API ever goes GA with
sane quotas, I'll be the first to switch.

DEV Community: Boris Radevic

I got tired of scraping app reviews twice, so I unified both stores

Google Trends still has no API in 2026. Here's what I use instead