App Store Localization Gap Finder

Only ~12% of top-100 apps properly localize their App Store/Play Store listings beyond basic translation. Most apps ship the same screenshots and near-identical copy to every country storefront — Japan, South Korea, and Germany are consistently the highest-opportunity underserved markets, the countries most likely to be getting a reused-default listing instead of a real localization pass. This actor finds out which of those gaps exist for a specific app, yours or a competitor's.

What it does

Pulls an app's listing (title, description, screenshots) across every country storefront you give it, diffs each one against the default (us) listing, and classifies each country:

• identical_to_default — reused default listing, no real localization done (the opportunity)
• partial — some elements localized (e.g. description translated, screenshots not)
• fully_localized — title, description, and screenshots all genuinely differ from default

Also rolls up a per-app summary: X of N countries localized, with the highest-opportunity countries surfaced first.

Verified, not guessed

Unlike some of the platform-specific scraping in this actor set, both fetchers here were tested against real, live data while building this actor — not assumed to work:

• iOS uses Apple's iTunes Lookup API (itunes.apple.com/lookup?id=...&country=...) — a genuinely public, keyless, documented endpoint. Confirmed live that country=us vs. country=jp returns real, independently-translated description text for the same app.
• Android has no public listing API for third-party apps (Google's official Play Developer API only exposes the calling developer's own apps), so this reads the same embedded JSON state block (AF_initDataCallback({key: 'ds:5', ...})) the Play Store page itself hydrates from — no JS execution needed, it's present in the plain HTML response. The exact index path used (data[1][2][0][0] = title, data[1][2][72][0][1] = description, data[1][2][78][0] = screenshots) was verified live against two unrelated real apps (Facebook, Spotify) and confirmed to return genuinely translated content across en/us, ja/jp, and de/de locales.
• Screenshot hashing (average-hash/aHash) was verified by decoding two different real App Store screenshots and confirming distinct hashes, then re-decoding the same screenshot twice and confirming identical hashes.
• A full end-to-end run was executed against real data for both platforms during development (Facebook on iOS across us/jp/de, Spotify on Android across us/jp/de/kr) and produced correct, sensible localization classifications.

One caveat that doesn't go away with testing: the Android path reads undocumented Google page-render internals, not a stable public contract. It can drift if Google changes how the page renders, unlike the iOS fetcher's official API. If Android checks start returning no listing returned, that's the first thing to check.

Neither platform needs a browser

Both fetchers work over plain HTTP with realistic headers — no Playwright, no JS execution, no anti-bot cat-and-mouse. This runs on the lightweight apify/actor-node:20 base image, not the heavier Playwright/Chrome image most of this portfolio uses.

The keyword limitation — read this before relying on keywords

keywords is not the real ASO keywords field, for either platform, for any app — including your own. Apple's keyword field is private to the app's own developer via App Store Connect and isn't exposed by any public API. Google Play has no public keywords field at all. What this actor outputs instead is a simple word-frequency inference from the visible title+description text — genuinely useful as a rough signal, but not authoritative ASO data. Two specific limitations:

• Non-Latin scripts (Japanese, Korean, Chinese) don't use spaces between words, so whitespace-based extraction degrades to near-useless there — expected, not a bug.
• Stopword filtering is English-only. German, French, Spanish, etc. keyword lists will include foreign function words ("und", "deine", "mit") since there's no per-language stopword list. Treat non-English keywords output as a rougher signal than the English default.

Input schema

{
  "appId": "284882215",
  "platform": "ios",
  "targetCountries": ["us", "gb", "jp", "kr", "de"],
  "compareKeywords": true,
  "compareScreenshots": true
}

appId — iOS: numeric App Store track ID. Android: Play Store package name (e.g. com.spotify.music). The us listing is always fetched as the comparison baseline even if you don't list it in targetCountries.

Output schema

Per-country rows (recordType: "country"):

{
  "appId": "string",
  "country": "string",
  "title": "string | null",
  "description": "string | null",
  "keywords": ["array — inferred, see limitation above"],
  "screenshotUrls": ["array"],
  "isLocalized": "boolean",
  "localizationGapType": "identical_to_default | partial | fully_localized",
  "titleIdentical": "boolean",
  "descriptionIdentical": "boolean",
  "screenshotsIdenticalCount": "number",
  "screenshotsTotalCount": "number",
  "checkedAt": "ISO timestamp",
  "status": "success | failed"
}

Plus one summary row per run (recordType: "summary") with countriesChecked, countriesLocalized, localizationScorePercent, and topOpportunityCountries.

Pricing

Event	Price
Run started	£0.05
Country checked (localized)	£0.02
Gap detected (identical to default)	£0.03
Country check failed	free

n8n integration

• Workflow A (trigger): scheduled run against the user's own app(s) across all target countries.
• Workflow B (processing): generate a localization scorecard (X% localized) from the summary row, flagging Japan/South Korea/Germany first if they show up in topOpportunityCountries — the underserved-market pattern this actor is built around.