Definition
App Store Locale System refers to how Apple, Google, and Amazon define and manage languages/locales in their stores, and which metadata is shown to users in each region. Each platform has a different approach: Apple uses 36 distinct locales (e.g., "English (United States)", "English (United Kingdom)", "French (France)", "French (Canada)"), each with separate metadata; Google uses 77+ language codes with device language as the primary lever; Amazon uses a per-marketplace model. Understanding how locales map to countries and how metadata cascades is critical for international ASO strategy, as it determines which keywords and metadata reach which users.
How It Works
Apple App Store: Locale-Centric Model
Apple offers 36 distinct locales. Each locale is a language + country/region combination. The key mechanics:
Locale Definition: Each locale has distinct metadata fields. An app can have:
- English (United States) metadata
- English (United Kingdom) metadata
- English (Australia) metadata
- French (France) metadata
- French (Canada) metadata
- Spanish (Spain) metadata
- Spanish (Mexico) metadata
- ...and 28 others
Regional Cascade & Fallback:
When a user in a specific country opens the App Store, Apple shows metadata for that country's primary locale. If the developer hasn't provided metadata for that locale, Apple falls back to a secondary locale:
Example:
- Australia (primary locale: English (Australia))
- If developer provided English (Australia) metadata → show it
- If not → fallback to English (United States)
- New Zealand (primary locale: English (Australia))
- If developer provided English (Australia) metadata → show it
- If not → fallback to English (United States)
The Dual-Locale Quirk (Search Implications):
A critical mechanics: Some countries inherit keyword coverage from multiple locales.
- United States: Sees English (United States) keywords only
- Mexico: Sees Spanish (Mexico) keywords primarily, but may also inherit Spanish (Spain) keywords in search (unclear)
- Canada: Sees English (Canada) keywords and French (Canada) keywords depending on user's device language setting
Strategic implication: If you optimize English (United States) aggressively with keywords like "budget planner", and a user in Canada has their device set to English (US), they may see those keywords twice (once from English (US), once from English (Canada) if similar). This can lead to keyword cannibalization.
Indexing & Ranking by Locale:
- Title, subtitle, keyword field are indexed per-locale
- Rankings are computed per-locale (your ranking in English (US) is independent of ranking in English (UK))
- An app can rank #1 in English (US) and #50 in French (France)
- Keywords in title/subtitle are indexed but with different weights per locale (e.g., some locales weight exact title matches higher)
Metadata Update Timing:
- Changes to a locale's metadata typically appear in that locale within 24 hours
- Changes are NOT simultaneous across all locales; updating English (US) doesn't immediately affect English (UK)
Google Play: Language-Based Model
Google Play uses 77+ language codes but does NOT create region variants within a language. The structure:
Language Definition: Metadata is tagged with a language code (en, es, fr, de, zh, ja, ko, etc.) but not a country code.
Geographic Routing: When a user's device language is set to Spanish, they see Spanish metadata regardless of their physical location. A user in Spain with device language set to English sees English metadata; a user in Mexico with device language set to Spanish sees Spanish metadata.
Single vs. Multiple Versions: Developers can provide:
- One Spanish translation (serves Spain, Mexico, Colombia, Argentina, etc. simultaneously)
- No per-country translation option (unlike Apple)
Keyword Deduplication: Unlike Apple's per-locale indexing, Google uses semantic deduplication. If an app has keywords "task,todo,list" in English and "tarea,lista,tareas" in Spanish, Google indexes both vocabularies but doesn't treat them as duplicates. This is cleaner but less flexible for regional optimization.
Ranking by Language:
- Rankings are per-language, not per-country
- An app ranks #1 in Spanish (across all Spanish-speaking regions) or it doesn't
- No way to optimize differently for Spanish (Spain) vs. Spanish (Mexico)
Amazon Appstore: Marketplace-Based Model
Amazon structures around physical marketplaces (Appstore for US, Appstore for UK, Appstore for Germany, etc.). Each marketplace has independent metadata:
Marketplace Definition: Amazon operates separate stores for major regions:
- Amazon Appstore (United States)
- Amazon Appstore (United Kingdom & Ireland)
- Amazon Appstore (France)
- Amazon Appstore (Germany)
- Amazon Appstore (Spain)
- Amazon Appstore (Italy)
- Amazon Appstore (Mexico)
- ...and others
Language Per Marketplace: Each marketplace has a primary language. US marketplace is English; Germany marketplace is German. Metadata is provided per-marketplace, not per-language within marketplace.
Metadata Synchronization: Developers can:
- Provide separate metadata for each marketplace
- Use "Base Marketplace" (usually US) as a template and adapt per marketplace
- Amazon also allows automatic translation (powered by Amazon Translate) for marketplaces where manual translation not provided
Ranking & Keywords:
- Each marketplace has independent search rankings
- Keywords in Amazon's keyword field (up to 100 chars) are indexed per-marketplace
- No cross-marketplace keyword sharing or inheritance
Formulas & Metrics
Locale Coverage Index (Apple):
Coverage = (Locales with Custom Metadata / Total Locales) × 100
Track how many of Apple's 36 locales have localized metadata.
Language Coverage Index (Google Play):
Coverage = (Languages with Custom Metadata / Total App Availability Languages) × 100
Keyword Cannibalization Risk (Apple):
Risk = Similar Keywords Across Multiple Locales / Total Keywords × 100
High risk = revise keyword strategy to avoid duplicate keywords in similar locales.
Best Practices
- Start with primary locale — fully optimize the #1 market (usually English (US) for global apps) before expanding to secondary locales.
- Understand your fallback chain — know which fallback locale applies to each secondary market. Don't assume Australia sees only English (US); it might inherit English (Australia) if available.
- Avoid keyword cannibalization — don't use "fitness tracker" in both English (US) and English (Australia); differentiate by market-specific keywords or primary keyword focus.
- Plan for per-locale testing — use A/B tests on Google Play (limited per-locale testing) and App Store experiments to optimize per-locale, not globally.
- Track per-locale metrics — monitor search visibility, CVR, and revenue per-locale. Don't assume all locales have equal value.
- Use soft-launch strategically — Google Play's soft-launch (100+ countries) lets you test metadata in specific locales before committing to full localization.
- Document your locale strategy — create a spreadsheet of which locales you'll support, primary keywords per locale, and fallback expectations.
Examples
Locale Inheritance Example (Apple):
Scenario: Fitness app with English (US), English (UK), and French (France) metadata
| User Location | User Device Language | Shown Metadata | Shown Keywords |
|---|---|---|---|
| United States | English (US) | English (US) | English (US) keywords |
| United Kingdom | English (UK) | English (UK) | English (UK) keywords |
| Australia | English (US) | English (US) (fallback) | English (US) keywords |
| Canada (English) | English (Canada) | English (US) (fallback) | English (US) keywords |
| Canada (French) | French (Canada) | French (France) (fallback) | French (France) keywords |
| France | French (France) | French (France) | French (France) keywords |
Google Play Simplicity (No Regional Variants):
Scenario: Same fitness app on Google Play with English and Spanish
| User Location | User Device Language | Shown Metadata |
|---|---|---|
| Spain | Spanish | Spanish (single version for all Spanish) |
| Mexico | Spanish | Spanish (same version) |
| Colombia | Spanish | Spanish (same version) |
| Argentina | Spanish | Spanish (same version) |
| Brazil | Portuguese | Not available (no Portuguese) |
Dependencies
Influences (this term affects)
- Localization Strategy — locale system determines how many localizations to create
- Keyword Localization — locale structure determines per-locale keyword strategy
- Keyword Field — keywords are indexed per-locale/language
- Metadata Optimization — metadata structure matches locale boundaries
Depends On (affected by)
- Platform's technical locale definitions (Apple: 36, Google: 77+)
- Regional availability and App Store presence by country
- Company's localization budget and bandwidth
Platform Comparison
| Aspect | Apple App Store | Google Play | Amazon Appstore |
|---|---|---|---|
| Locale structure | 36 locales (lang + country) | 77+ languages (lang only) | ~30 marketplaces (regional) |
| Regional variants | Yes (e.g., English (US) vs. English (UK)) | No (one Spanish for all) | Yes (per-marketplace) |
| Metadata per-locale | Independent | Independent per language | Independent per marketplace |
| Ranking per-locale | Yes (separate rankings per locale) | Yes (separate rankings per language) | Yes (separate rankings per marketplace) |
| Fallback behavior | Defined chain (e.g., AU → US English) | All language searches fall back to English if provided | Per-marketplace defaults |
| Keyword deduplication | Limited (exact match within locale) | Semantic deduplication across languages | Per-marketplace only |
| Easiest to localize | Google Play (single per language) | Google Play | Amazon (fewer marketplaces) |
Related Terms
- Localization Strategy
- Keyword Localization
- Metadata Localization
- Keyword Field
- Apple Search Algorithm
- Google Play Search Algorithm
- App Title
Sources & Further Reading
- Apple: App Store Localization Guide
- Google: Play Store Localization Checklist
- Amazon: Appstore Metadata Guidelines by Region
- SplitMetrics: Locale-Specific Strategy Guide