DEV Community: MrAdex77

ASO for Developers: Get App Users Without Paying for Ads

MrAdex77 — Sat, 17 Oct 2026 15:42:59 +0000

You can ship a solid app, pass review, and still watch the downloads counter sit in single digits. In December 2025 a developer posted on the Apple Developer Forums that their app had about 40 downloads two months after launching on both stores, even after a new icon and new screenshots (Apple Developer Forums). A reply in the same thread said Apple Ads hadn't produced a single download for them either.

Before you buy installs, fix how the stores find your app. That's App Store Optimization (ASO), and every part of it can be done for free, a lot of it with a few lines of code. This post covers the playbook, two Node snippets you can run today, and the open-source ASO tool I maintain.

TL;DR

Apple says 70% of App Store visitors use search to discover apps (2022 data). Your metadata decides whether you show up in those searches.
The App Store indexes a 30-character name, a 30-character subtitle and a private 100-character keyword field. Google Play indexes a 30-character title, an 80-character short description and a 4,000-character description.
New apps win long, specific phrases first. On 2026-10-17 the top US result for "habit tracker" in Apple's iTunes Search API had 148,007 ratings, while the #2 result for "habit tracker for couples" had 4.
Track your rank every day down to position 200. A new app starts deep in the results, and a top-50 check shows nothing while it climbs.
Buy ads after your listing ranks and converts. Apple Ads uses the same metadata to judge relevance.

Why not start with paid ads?

Paid installs cost money every time and stop when the budget does. SplitMetrics put the average Apple Ads cost per acquisition at $3.76 in its 2025 campaign data, $13.28 for finance apps and $19.74 for sports apps (SplitMetrics, September 2026). At the average, 1,000 installs cost $3,760, and the next 1,000 cost the same again.

Ads also depend on the work ASO does. Apple's help pages say "your app title, descriptions, and keywords are all considerations Apple Ads uses to assess your app's relevance for specific search queries" (Apple Ads Help). And if people tap your ad and bounce off a weak page, you paid for taps that never became installs.

Ads do have a place. Apple reports tap-through install rates above 60% for ads at the top of search results (Apple Ads, November 2024 to October 2025). Once your listing ranks for a few phrases and converts, a small budget is a good way to test new keywords or push a launch.

What is App Store Optimization?

App Store Optimization is the practice of improving how an app ranks and converts in App Store and Google Play search. It covers which keywords you target, where you put them in your store metadata, how your listing compares with competing apps, and the ratings, icon and screenshots that turn a search result into an install.

Search is the main way people find apps. Apple says 70% of App Store visitors use search to discover apps and almost 65% of downloads happen directly after a search (Apple Ads, figures from 2022). Apple's 2025 Transparency Report lists 2,172,472 apps on the App Store.

Apple describes its ranking inputs as "text relevance (matches for your app's title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more)" (App Store search). Google says Play ranks apps on "a combination of ratings, reviews, downloads, and other factors" (Play Console Help). Text relevance is the part you control on day one.

Which store fields count for search?

Field	App Store	Google Play
App name or title	30 characters, indexed	30 characters, indexed
Subtitle	30 characters, indexed	Doesn't exist
Keyword field	100 characters, private, indexed	Doesn't exist
Short description	Doesn't exist	80 characters
Full description	Not in Apple's list of search inputs	Up to 4,000 characters
Promotional text	Apple says it doesn't affect ranking	Doesn't exist

Sources: Apple's Creating your product page, App Store search and Platform version information; Google's Create and set up your app.

Rules for the App Store keyword field

Apple's guidance for the field (Creating your product page):

Separate keywords with commas and no spaces.
Don't repeat words from your app name, subtitle or category.
Don't add plurals of words you already use in singular form.
Leave out category names, filler words like "the" and the word "app".
Leave out competitors' app names and trademarked terms. Apple lists them as reasons for rejection.

Here's a made-up but very typical field for an app named "Habit Tracker: Daily Goals" with the subtitle "Build routines that stick", run through AsoBeast's free keyword field checker:

Before, 83 of 100 characters:
habit tracker, daily habits, the best app, goals, routine, routines, free, reminder

After, 8 of 100 characters:
reminder

Spaces after commas, filler words, words already in the name and subtitle, and plurals of words already used took up 75 characters. Use the space for phrases you don't rank for yet.

Rules for Google Play

Google Play has no keyword field, so your phrases go into the title, short description and description. Google's advice is to "give an overview of your app or game using everyday language, not a list of keywords" (Best practices for your store listing). Its metadata policy says to "avoid using repetitive or unrelated keywords or references" and bans ranking claims such as "#1" in the title, icon or developer name (Metadata policy).

How do you find keywords a new app can win?

Collect 30 to 50 candidate phrases, then keep the ones that real people search where the current top results look beatable.

Store autocomplete is the cheapest source of real search phrases. On Google Play you can read it with @mradex77/google-play-scraper, the scraper from my Stackademic post on scraping Google Play:

import { suggest } from '@mradex77/google-play-scraper';

for (const term of ['habit tracker', 'habit tracker for']) {
  const suggestions = await suggest({ term });
  console.log(`${term}: ${suggestions.join(', ')}`);
}

Output on 2026-10-17:

habit tracker: habit tracker, habit tracker free, habit tracker app, habit tracker widget, habit tracker free app
habit tracker for: habit tracker for adhd, habit tracker for couples, habit tracker for free, habit tracker for study, habit tracker for students

Ending a seed with "for" or another preposition pulls out the audience-specific phrases. Check those next, because the apps ranking for them can be small. I looked up the top App Store results in the US for two of these phrases through Apple's iTunes Search API on the same day:

"habit tracker": the #1 app had 148,007 ratings, and the #4 had 764,669.
"habit tracker for couples": the #2 app had 4 ratings, and the #4 had none.

Apple gives the same advice in its own search guide. Popular terms "are highly competitive", especially for newer or smaller apps, while less common terms bring less traffic and less competition (App Store search). Start where an app with 4 ratings can rank, and move to the head terms once your ratings and downloads grow.

Two more sources are worth a pass: the names and subtitles of the top 10 apps for your main phrase, and reviews, yours and your competitors'. People describe an app in the words they search with.

How do you check your App Store rank in code?

Apple's public iTunes Search API returns up to 200 apps for a search term, which is enough for a rank check. This needs Node 22 or newer and no dependencies:

const [appId, term, country = 'us'] = process.argv.slice(2);

const url = new URL('https://itunes.apple.com/search');
url.search = new URLSearchParams({ term, country, entity: 'software', limit: '200' });

const { results } = await (await fetch(url)).json();
const position = results.findIndex((app) => String(app.trackId) === appId) + 1;

console.log(position ? `#${position} for "${term}" in ${country.toUpperCase()}` : `Not in the top ${results.length}`);

$ node rank.mjs 570060128 "learn spanish" us
#1 for "learn spanish" in US
$ node rank.mjs 570060128 "spanish vocabulary" de
#10 for "spanish vocabulary" in DE

The app id is the number after id in your App Store URL (570060128 is Duolingo). Keep the request rate low: Apple documents the Search API limit as "approximately 20 calls per minute (subject to change)", which is why AsoBeast's free rank tracker checks at most 10 keywords at a time. The API returns iPhone apps, and a search on your own phone can differ because Apple Ads results and your history change what you see.

Run it every day and store the result, and check all 200 positions. A new app usually first shows up far down the list. With a top-50 check you'd see "not ranked" while the app climbs from 180 to 60, and conclude that nothing worked.

If you'd rather not write a cron job, AsoBeast's free App Store keyword rank tracker does the same check in your browser for up to 10 keywords in any of 175 countries, with no signup.

How do you research competitors?

Your competitors are whoever holds the top 10 for your target phrases, which may not be the apps you had in mind. For each, note the name and subtitle, the rating count and the date of the last update. Phrases where they rank and you don't are gaps. Phrases where nobody strong ranks are openings.

Keep watching them. A competitor that rewrites its title or subtitle may be going after a new keyword, and you can follow its rank on that phrase for a few weeks without spending one of your own releases on the experiment. Their one- and two-star reviews tell you what to promise in your screenshots.

How should you ship and measure ASO changes?

Treat the first update as the baseline. Clean up the keyword field and put your main phrase in the name, subtitle or title in one release, because wasted characters cost you every day they stay. After that, change one field per release and wait about two weeks before you judge it. Change three fields at once and you won't know which one moved your rankings.

On the App Store, the keyword field sits on your version page in App Store Connect, so new keywords ship with a version you submit for review. On Google Play, listing edits can go through review too.

Track three numbers: your daily rank for each target phrase, installs from search, and the conversion rate from page view to install. In App Store Connect, App Analytics splits downloads by source, and App Store Search is one of them.

Where do keyword installs show up in Google Play Console?

Under "Google Play explore". Play Console's "Google Play search" source counts only people who searched for your app's name or a closely associated brand. Generic searches like "racing game" and taps on autocomplete suggestions count as explore, and the Search term dimension shows what people typed (Play Console Help).

How do you turn rankings into installs?

Once you rank, the icon, the first screenshots and the rating decide whether people install. Both stores give you the tools for free:

Ask for a rating after the user has done something that worked. On iOS, SKStoreReviewController shows Apple's prompt, up to three times in a 365-day period (Ratings, reviews, and responses). On Android, use the Google Play In-App Review API.
Test the page. Apple's product page optimization runs up to three alternate versions of your icon, screenshots and app previews against the original. Google Play's store listing experiments test the icon, feature graphic and screenshots, and localized experiments can test descriptions.

AsoBeast: the open-source ASO tool I maintain

The snippets above are fine for ten keywords in one country. AsoBeast does it daily for hundreds of keywords across countries, in both stores, and keeps the history. It's an App Store Optimization tool for the App Store and Google Play: it tracks keyword rankings daily, watches competitors and reviews, and turns it all into a to-do list ranked by impact. I wanted that workflow without paying per keyword or sending my keyword list to a vendor, so the whole thing is AGPL-3.0 with no open core.

AsoBeast / asobeast

Open source, self-hosted App Store Optimization toolkit for the Apple App Store and Google Play.

AsoBeast

AsoBeast is an App Store Optimization (ASO) tool and keyword rank tracker for the Apple App Store and Google Play.

Use the hosted service at asobeast.com, or self-host the open source edition on your own server.

Website ·
Quickstart ·
Self-host ·
MCP server ·
API ·
Changelog

What is AsoBeast?

AsoBeast is an App Store Optimization (ASO) tool and keyword rank tracker for the Apple App Store and Google Play. It imports a listing, tracks keyword rankings daily to a depth of 200, watches competitors, reviews and metadata, and turns that history into a prioritized queue of ASO work. This repository is the free, open source edition that you run on your own server, and the hosted service at asobeast.com runs the same code.

Every store request runs on the machine hosting AsoBeast as an ordinary public search or page request, so Apple and Google see each…

View on GitHub

What it does in v1.11.0:

Imports an App Store or Google Play link and checks its keywords daily to position 200, in any of 175 App Store storefronts and 225 Google Play countries. One search per keyword covers your app and all of its competitors.
Scores keyword popularity and difficulty, shows where each number comes from, and suggests keywords from your metadata, search results, similar apps, competitors and reviews.
Finds competitors in live search results, lists keyword gaps and records the title, subtitle and description changes it detects.
Syncs reviews and rating history and groups reviews into themes.
Runs an Action Center: fifteen deterministic rules read the stored history and produce items like "Push 'make memes' from #12 into the top 10", each with its evidence and a check that the fix worked. AI is optional and never invents or reorders an action.
Ships a REST API and an MCP server that reads by default, so Claude Code, Claude Desktop or Cursor can query your rankings.

The stack is TypeScript throughout: NestJS, Prisma, PostgreSQL 18, BullMQ, Redis 8 and Next.js, in a pnpm and Turborepo monorepo. The Google Play side runs on the same @mradex77/google-play-scraper as the snippet above. There's no telemetry, and apart from the store searches themselves, nothing leaves your server unless you turn on an integration such as webhook alerts or email.

To run it, you need Docker with Compose and roughly 2.5 GB of memory. This uses the published images, with no clone or build:

curl -fsSLO https://raw.githubusercontent.com/AsoBeast/asobeast/main/docker-compose.pull.yml
printf 'POSTGRES_PASSWORD=%s\nAUTH_SECRET=%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
chmod 600 .env
docker compose -f docker-compose.pull.yml up -d --wait

Open http://localhost:3001, create the owner account (registration closes after that), and import a store link. Tracking starts right away. The quickstart covers the rest, including a one-click Railway deploy. There's also a hosted version at asobeast.com that runs the same code, if you'd rather not run a server.

It has limits, and the README lists them. Popularity and difficulty are estimates built from public store data. The stores' rate limits, not your hardware, cap how many keyword markets one instance can track. Backups and upgrades are your job when you self-host.

FAQ

Is ASO free?

The work is. App Store Connect and Google Play Console analytics and listing tests are free, the iTunes Search API and store autocomplete are public, and open-source tools like AsoBeast are free to self-host. Paid ASO tools save time once you track hundreds of keywords in many countries.

How long does ASO take to work?

A metadata change goes live with your next approved App Store version, or once Google reviews your listing update. Rankings move over the following weeks. Give each change about two weeks before you judge it.

Should I run Apple Ads at launch?

Only once the listing converts. Apple judges ad relevance from your title, description and keywords, so ASO comes first either way. After that, ads are a good way to test a phrase before you put it in your title.

Your first hour

Run suggest() on your main phrase with "for", "with" and "without" appended, and write down 30 phrases.
Check your rank for the ten most relevant ones with the snippet or the free rank tracker.
Paste your keyword field into the keyword field checker and fill the characters it frees.

If AsoBeast saves you an ad budget, a star on GitHub helps other developers find it, and issues and pull requests are welcome.

There's No Google Play API. Here's How I Scrape the Play Store in Node.js (2026)

MrAdex77 — Thu, 09 Jul 2026 10:04:24 +0000

Ask Google for an API to read Play Store listings, search results, or reviews. The answer is the same in 2026 as it was a decade ago: there isn't one. The Google Play Developer API only manages apps you publish. Reading anyone else's public store data has no official endpoint at all.

That's a strange hole for a store this size. Google Play lists about 1.9 million apps (AppBrain, 2026) and serves 2.5 billion+ monthly users across 190+ countries. It made $49.2 billion in 2025 (Business of Apps, Google Play Statistics, 2026). Every ASO tool, market report, and research paper built on that data got it one way: scraping.

I maintain @mradex77/google-play-scraper, an open-source, strict-TypeScript Google Play scraper for Node.js. This post is the full working guide: install, app details, search, top charts, paginated reviews, and not getting rate limited. Every snippet comes from the repo's runnable examples, so you can clone and reproduce all of it.

MrAdex77 / google-play-scraper

Google Play scraper for Node.js with a fully typed TypeScript API. App details, search, top charts, reviews, permissions and data safety. A modern replacement for the unmaintained google-play-scraper.

google-play-scraper

Scrape Google Play app data in Node.js with a fully typed TypeScript API. Fetch app details, search results, top charts, developer pages, similar apps, user reviews, permissions and data safety information directly from the Play Store. Built for ASO research, app market analysis, competitor tracking, review monitoring and data pipelines.

This is a modern TypeScript rewrite of the popular but unmaintained google-play-scraper package. The public method names, options and constants match the original, so migrating is usually just a matter of swapping the import.

Why this library

Fully typed results. Every method returns a precise TypeScript type derived from a zod schema that validates the scraped data at runtime.
No HTTP dependency. Runs on the native fetch of Node.js 22 and newer.
Resilient by design. Every fragile Google Play array path lives behind a spec layer with ordered fallback paths, so a single moved index does not take a…

View on GitHub

Key Takeaways

No official Google Play Store API exists for listings, search, or reviews; scraping public pages is how every app-intelligence dataset gets built.

@mradex77/google-play-scraper rewrites the unmaintained classic in strict TypeScript, validates everything with zod at runtime, and tests against live Google Play daily in CI.

npm install, one import, await app({ appId }): 55 typed fields per app.

What Makes Google Play So Hard to Scrape?

Not the fetching. The parsing. Google Play ships its data as enormous, deeply nested JavaScript arrays with zero labels, and the array positions shift a few times a year. Your scraper doesn't break because Google blocks you. It breaks because data[1][2][72][0][1] quietly became data[1][2][74][0][1].

The monetization layout raises the stakes. In 2026, roughly 97% of Play Store listings are free (42matters, Google Play Statistics and Trends, 2026). That makes reviews, install counts, and IAP flags the analytically interesting fields. Those live deepest in the unlabeled arrays. Android's ~72% global OS share (StatCounter Global Stats, 2026) means that data describes most of the world's mobile users.

So the real engineering question isn't "how do I scrape Google Play?" It's "how do I keep a Google Play scraper alive?" Everything below is designed around that question.

Why Not Just Use the Original google-play-scraper?

Because nobody's maintaining it. facundoolano/google-play-scraper defined this space and still moves about 94,000 npm downloads a week as of July 2026 (npm registry download counts, 2026). But when Google shuffles an index now, the fix has to come from a fork or a monkey-patch in your own code.

My rewrite keeps the exact public surface — same method names, same options, same constants — and rebuilds the internals:

Capability	@mradex77/google-play-scraper	Original google-play-scraper
Language	TypeScript, strict mode	JavaScript
Type definitions	Generated from zod schemas	Community typings
Runtime validation	zod on every input and output	None
Error handling	Typed error classes	Plain `Error`
Module formats	ESM + CommonJS + `.d.ts`	ESM only
Breakage detection	Daily live contract tests in CI	None
Maintenance	Active	Unmaintained

The two internals that matter most:

Spec layer with fallback paths. Every fragile array index lives in a per-feature specs.ts file as a typed constant with ordered fallback candidates. A moved index degrades one field, and extraction throws a single SpecError listing every broken field plus every path it tried. Nothing silently returns garbage.
Daily live contract tests. CI runs the e2e suite against real play.google.com every day and auto-opens a labeled GitHub issue on failure. The maintainer finds out before your pipeline does.

Installation

Node.js 22.12+, native fetch, no HTTP dependency:

npm install @mradex77/google-play-scraper

Named exports or an aggregate default export (the default export is drop-in compatible with the original package):

import { app, search, reviews } from '@mradex77/google-play-scraper';

import gplay from '@mradex77/google-play-scraper';

const details = await gplay.app({ appId: 'com.google.android.apps.translate' });
console.log(details.title, details.score);

CommonJS also works:

const gplay = require('@mradex77/google-play-scraper').default;

gplay.search({ term: 'panda' }).then((results) => {
  console.log(results.length);
});

No API keys, no headless browser, no Python sidecar.

How Do You Fetch App Details?

app() takes an appId and returns 55 typed fields: title, description, rating histogram, installs, price, screenshots, developer info, and the rest. The appId is sitting in every Play Store URL as the ?id= parameter:

Adapted from examples/all-methods.ts:

import { app } from '@mradex77/google-play-scraper';

const details = await app({ appId: 'com.adex77.WhereAmI' });

console.log('Title:', details.title);
console.log('Developer:', details.developer);
console.log('Score:', `${details.score?.toFixed(2)} / 5 (${details.reviews} reviews)`);
console.log('Installs:', details.installs);
console.log('Price:', details.free ? 'Free' : details.priceText);
console.log('Genre:', details.genre);
console.log('Updated:', new Date(details.updated).toDateString());

Here's the repo's example script hitting live Google Play while I wrote this post:

The zod layer is what makes this pleasant in a TypeScript codebase. details autocompletes all 55 fields, and if Google ships something malformed, you get a validation error at the boundary instead of undefined surfacing three layers into your pipeline.

Different market? Every method takes lang and country:

const german = await app({
  appId: 'com.adex77.WhereAmI',
  lang: 'de',
  country: 'de',
});

How Do You Search the Play Store Programmatically?

search() returns up to 250 results per query. Roughly 2,400 new apps land on Google Play every day in 2026 (Business of Apps, 2026), so keyword rankings rot fast. Automating this is the only way to keep up.

import { search, suggest } from '@mradex77/google-play-scraper';

const results = await search({ term: 'where am i geography quiz', num: 5 });

results.forEach((item, index) => {
  console.log(`#${index + 1}: ${item.title} (${item.appId})`);
});

Results carry title, appId, icon, developer, price, and score; fullDetail: true upgrades each to the full 55-field record. There's also suggest(), which exposes Play's own autocomplete. That's free ASO keyword research:

const suggestions = await suggest({ term: 'where am' });
console.log(suggestions.join(', '));

How Do You Pull Top Charts and Competitors?

list() fetches the ranked collections (top free, top paid, top grossing) per category:

import { list, collection, category } from '@mradex77/google-play-scraper';

const topGames = await list({
  collection: collection.TOP_FREE,
  category: category.GAME,
  num: 5,
});

topGames.forEach((item, index) => {
  console.log(`#${index + 1}: ${item.title}`);
});

Constants are exported, frozen, and typed (collection.TOP_FREE, category.GAME_PUZZLE, category.FAMILY, …), so the editor autocompletes what other libraries make you copy from a README.

developer() returns a publisher's entire portfolio. similar() returns the "similar apps" rail. That's effectively Google naming your competitor set for you:

import { developer, similar } from '@mradex77/google-play-scraper';

const portfolio = await developer({ devId: '5700313618786177705' });
const competitors = await similar({ appId: 'com.adex77.WhereAmI' });

How Do You Scrape Reviews (All of Them)?

Reviews hide behind Google's internal batchexecute endpoint with token-based pagination — the single most annoying thing to reverse-engineer by hand. reviews() wraps it, and every response is a { data, nextPaginationToken } envelope:

import { reviews, sort } from '@mradex77/google-play-scraper';

const firstPage = await reviews({
  appId: 'com.adex77.WhereAmI',
  sort: sort.NEWEST,
  num: 5,
});

firstPage.data.forEach((review) => {
  console.log(`${review.score}★ by ${review.userName}: ${review.text}`);
});

if (firstPage.nextPaginationToken) {
  const nextPage = await reviews({
    appId: 'com.adex77.WhereAmI',
    paginate: true,
    nextPaginationToken: firstPage.nextPaginationToken,
  });
}

Loop until the token comes back undefined and you've walked every review: score, text, ISO 8601 date, thumbs-up count, app version, developer reply.

Bonus pair almost no scraper exposes — permissions() and datasafety():

import { permissions, datasafety } from '@mradex77/google-play-scraper';

const perms = await permissions({ appId: 'com.adex77.WhereAmI' });
const safety = await datasafety({ appId: 'com.adex77.WhereAmI' });

console.log('Permissions:', perms.length);
console.log('Collected data types:', safety.collectedData.length);
console.log('Privacy policy:', safety.privacyPolicyUrl);

That's the full permission list plus the parsed Data Safety panel: collected data, shared data, declared security practices. Useful far beyond ASO — privacy research runs on exactly these fields.

How Do You Stay Under the Rate Limits?

Three levers, all built in. Use all three for anything bigger than a handful of requests.

throttle caps requests per second; exponential backoff with Retry-After support is automatic:

import { app } from '@mradex77/google-play-scraper';

const details = await app({
  appId: 'com.adex77.WhereAmI',
  throttle: 5,
  requestOptions: { timeoutMs: 15000, retries: 3 },
});

memoized() wraps every method in an in-memory LRU cache, so repeated calls inside the TTL never touch Google. In the repo's example run the second call returns in a fraction of a millisecond:

import { memoized } from '@mradex77/google-play-scraper';

const client = memoized({ maxAgeMs: 60000, max: 500 });

const first = await client.app({ appId: 'com.adex77.WhereAmI' });
const second = await client.app({ appId: 'com.adex77.WhereAmI' });

Typed errors let your pipeline branch on the cause instead of regex-matching messages:

import { app, NotFoundError, RateLimitError, SpecError } from '@mradex77/google-play-scraper';

try {
  const details = await app({ appId: 'com.does.not.exist' });
} catch (error) {
  if (error instanceof NotFoundError) {
    console.error('No such app');
  } else if (error instanceof RateLimitError) {
    console.error('Backing off — Google is rate limiting');
  } else if (error instanceof SpecError) {
    console.error('Google changed its layout:', error.failures);
  } else {
    throw error;
  }
}

SpecError.failures is the underrated one. It names every field that stopped resolving and every path that was tried — a complete, machine-generated repair ticket for the next layout change.

Is It Legal?

The library reads only what any browser can: public pages. Scraping still lives in a gray zone, so the Google Play Terms of Service and your local laws are on you, particularly for the personal data inside reviews. My working rules:

Throttle everything; spread big jobs over time
Cache hard; never re-fetch what you already hold
Analyze, don't republish Google's content wholesale
Treat reviewer names and avatars as personal data under GDPR-style regimes

Not affiliated with or endorsed by Google. Scrape responsibly.

FAQ

Is there any official API for Google Play Store data?

No. Google's APIs only cover apps you publish yourself. For reading public listings, search results, top charts, or reviews of arbitrary apps, no official API exists in 2026. That's why open-source scrapers parsing play.google.com are the standard approach.

How do I scrape Google Play reviews in Node.js?

Install @mradex77/google-play-scraper, then call reviews() with the target appId and paginate: true. Keep feeding the returned nextPaginationToken back until it's undefined. Add throttle so apps with millions of reviews don't trip Google's rate limits.

What data can a Google Play scraper get?

App details (55 fields including installs, ratings histogram, and screenshots), search results, autocomplete suggestions, top charts by category, developer portfolios, similar apps, paginated reviews, permissions, and the parsed Data Safety section. That coverage spans the ~1.9 million apps live on Google Play (AppBrain, 2026).

Can I migrate from the original google-play-scraper package?

Yes, usually by swapping one import. Method names, options, and constants match. You gain strict TypeScript types from zod schemas, runtime validation, typed error classes, dual ESM/CommonJS builds, and daily live contract tests that the unmaintained original lacks.

Why can't I run this in the browser?

Google Play's pages don't send CORS headers permitting cross-origin reads, so no browser-based scraper can work. The library targets Node.js 22.12+ and uses its native fetch.

Wrap-Up

Google Play scraping in 2026 in three sentences. There's no official API and there won't be one soon. The data sits in unlabeled arrays that shift under you. Pick a tool that treats breakage as a first-class design problem, or become the maintainer yourself at 2 a.m.

npm install @mradex77/google-play-scraper

import gplay from '@mradex77/google-play-scraper';

const details = await gplay.app({ appId: 'com.google.android.apps.translate' });

The README documents every method and return shape, and examples/all-methods.ts runs the entire API end to end.

If this saved you from reverse-engineering batchexecute, a star on GitHub genuinely helps the project. And if a field ever stops resolving, open an issue with the SpecError output. Fastest bug report format there is.

Sources: Business of Apps, Google Play Statistics, retrieved 2026-07-08. AppBrain, Number of Android apps on Google Play, retrieved 2026-07-08. StatCounter Global Stats, Mobile OS Market Share Worldwide, retrieved 2026-07-08. 42matters, Google Play Statistics and Trends, retrieved 2026-07-08. npm registry, weekly download counts for google-play-scraper, retrieved 2026-07-08.

Building "Where Am I?": A GeoGuessr Alternative for Mobile

MrAdex77 — Wed, 08 Jan 2025 18:34:46 +0000

Hi Dev Community! 👋

I’m thrilled to share with you the journey of building Where Am I?, a mobile app designed as a free alternative to GeoGuessr and CityGuessr. It’s a location-guessing game that immerses players in street walk videos from around the globe. As a solo developer, this project has been a labor of love, and I wanted to give you a behind-the-scenes look at how it all came together from a tech perspective.

The Idea

The inspiration for Where Am I? started during the COVID-19 pandemic. With everyone stuck indoors, I wanted to create a game that offered a sense of exploration and adventure. Initially, the app was a simple prototype with basic features. It gained traction with over 50,000 downloads and amazing user feedback. Encouraged by the positive response, I decided to rewrite the app from scratch, making it more robust, feature-rich, and scalable.

Tech Stack

To bring this project to life, I chose the following technologies:

Frontend: React Native

Where Am I? is a cross-platform mobile app built with React Native. This allowed me to deliver a seamless experience for both Android and iOS users using a single codebase. The frontend was developed with a combination of JavaScript and TypeScript to ensure type safety and scalability.

Key libraries and tools:

Expo: Simplified the development process and provided access to native APIs.
React Navigation: For smooth navigation between screens.
Reanimated: For fluid animations and transitions.
Redux: To manage the global state, including user progress, leaderboards, and campaign data.

Backend: NestJS (Node.js Framework)

The backend is powered by NestJS, a progressive Node.js framework built with TypeScript. NestJS provided a modular structure, making the backend easier to maintain and scale.

Backend highlights:

RESTful APIs: Exposed endpoints for user authentication, leaderboard management, and campaign data.
PostgreSQL: The relational database for storing user data, scores, and game content.
Redis: For caching frequently accessed data like leaderboards.
JWT Authentication: Secured user sessions with JSON Web Tokens.

Cloud & Hosting

AWS (Amazon Web Services): Hosted the backend and database for scalability and reliability.
Cloudflare: Handled CDN and DDoS protection to ensure fast and secure gameplay.

Key Features

Immersive Gameplay: Watch high-quality street walk videos and guess the location.
Campaigns: Explore themed challenges like "Southern Europe's Sunlit Secrets" or "Unlock the UK's Royal Secrets."
Multiplayer Modes: Compete with friends in duels or join global tournaments.
Leaderboards: Track your progress and aim to become the "King/Queen of the World."
Collectibles: Earn badges and unlock monuments as you play.

Challenges & Lessons Learned

Cross-Platform Compatibility: React Native made cross-platform development easier, but handling platform-specific quirks required extra attention.
Video Optimization: Ensuring smooth playback of street walk videos on both high-end and low-end devices was challenging. I used adaptive bitrate streaming to address this.
Scalability: With an ever-growing user base, designing a backend that scales while maintaining fast response times was crucial. Redis caching was a game-changer here.
Localization: Adding support for languages like Spanish (ES) and Portuguese (PT) helped make the app accessible to a broader audience.

Why "Where Am I?" Stands Out

While GeoGuessr and CityGuessr are fantastic games, Where Am I? offers a unique twist:

Completely Free: No paywalls or subscriptions.
Mobile-First: Designed specifically for Android and iOS devices.
Immersive Campaigns: Themed challenges that take players on curated adventures.
Community-Centric: Player feedback drives new updates and features.

What’s Next?

The journey doesn’t stop here! I’m actively working on:

Custom Multiplayer Modes: Letting players create their own rules and challenges.
New Campaigns: Expanding the game with more countries and themes.
Augmented Reality (AR): Exploring ways to integrate AR for an even more immersive experience.

Try It Out!

If you’re looking for a fun, educational, and free GeoGuessr alternative, give Where Am I? a try. I’d love to hear your feedback and ideas for future updates.

Website: whereamigame.app
Google Play: Download on Android
App Store: Download on iOS

Thank you for reading! If you have any questions about the tech stack or the development process, feel free to drop them in the comments below. 🙌