Localized Pricing for Mobile Apps: The Complete Guide

If you're selling an app, subscription, or in-app purchase globally, and you've already decided that one USD price for the whole world isn't enough, this is the guide for setting up localized pricing properly. Not the argument for why it matters. The execution.

I've been shipping mobile apps for over a decade and running localized pricing across my own catalog of 8 apps for years. This post walks through what localized pricing actually means, how to produce a per-country price that feels right in each market, how the App Store and Google Play diverge on the mechanics, and how to keep it from silently drifting out of alignment six months later.

If you want the upstream argument, why localized pricing is an ASO lever as well as a revenue lever, that's covered separately in how app store pricing affects your ASO rankings. Everything below assumes you're past that and want the operational playbook.

What "localized pricing" actually means

Localized pricing means setting country-specific prices intentionally, so your app or subscription is priced appropriately for local purchasing power in every market where you sell.

That definition rules out two very common setups that often get called localized pricing but aren't.

The first is exchange-rate auto-conversion. When you set a base price in App Store Connect or Google Play Console and let the store convert it into local currency, you get a number in rupees, lira, or reais. That number is mathematically correct for current FX rates. It has nothing to do with what the price feels like in that country.

The second is manual per-country prices that still anchor on the base country's number. Setting ₹1,659 in India because that's the closest price tier to the $19.99 FX conversion is the same trap wearing a different hat. You picked a rupee number; you didn't pick a rupee price.

Real localized pricing uses Purchasing Power Parity (PPP) as the input, not exchange rates. PPP asks: what rupee number produces roughly the same affordability burden for an Indian user as $19.99 does for a US user? For a US median monthly income around $5,000 per BLS Q1-26 data, $19.99 is about 0.4%. For an Indian individual median income somewhere between ₹15,000 and ₹27,000 depending on source, the PPP-equivalent local price is typically much lower than the FX-converted ₹1,660. For deeper background on the reframing, see the pillar post on app store localization.

Why the default (auto-convert) underperforms

The default, store-managed currency conversion is convenient. It also quietly underperforms for three structural reasons.

It ignores purchasing power. A $19.99 subscription at today's FX rate converts to roughly ₹1,660 in India and ₺760 in Turkey. Against Indian individual median income, ₹1,660 lands at 6 to 11% of monthly income. Against Turkey's TÜİK February 2026 median net income of around ₺23,000, ₺760 is about 3%. For a US user on roughly $5,000 per month, the same $19.99 is 0.4%. Same line item in App Store Connect. Three very different purchase decisions.

It ignores local price thresholds. Users in each market have a mental model of what "a normal app subscription" costs, anchored on round numbers and familiar endings. Auto-conversion produces numbers like ₹1,659.17 or ₺764.43. The decimals are correct. They just never appear in any normal purchase flow, and they look foreign to the user reading them.

It can't be maintained without you looking at it. Currencies move. The Turkish lira drifted meaningfully against the dollar multiple times over the last 12 months. When your base price is $19.99 and auto-conversion is on, your Turkish price changes without you touching anything. Sometimes up, sometimes down. The lira case is sharp, but Brazilian real, Argentine peso, and several emerging-market currencies behave similarly.

If you want a narrative version of hitting these walls firsthand, I wrote about the year I gave up on one global price and switched approaches.

The PPP baseline: country-specific starting prices

PPP-based pricing gives you a defensible starting number per country. The math is straightforward even if you've never touched an economics dataset.

You need two inputs. One: a PPP conversion factor per country, usually expressed as "local currency per US dollar of equivalent purchasing power." Two: your base price in your base country, which is usually the US.

The calculation, at its simplest: Country baseline price = (PPP_country / PPP_base) × base_price. For the US as the base, PPP_base is 1. The OECD publishes PPP data regularly through its Purchasing Power Parities dataset page. The World Bank's International Comparison Program is the other authoritative source. Both are updated on rolling cycles and differ slightly in methodology; either works as a starting point.

A worked example. You charge $19.99 in the US. India's PPP conversion factor for GDP against USD has typically sat around 22 to 25 in recent World Bank data (local rupees per dollar of equivalent purchasing power), varying by year and dataset. Running that through the formula puts your PPP-based India baseline somewhere between ₹440 and ₹500. Compare that to the auto-converted ₹1,660. The gap between those two numbers is the gap that PPP-based pricing fills.

PPP gives you a baseline, not a final price. The baseline is a rough economic anchor. Turning it into a number you can actually ship on the App Store involves rounding, price-ladder constraints, and a per-market sense of what looks normal. The next section handles that. For a deeper walk-through of the PPP math with more country examples, see Real Localized Pricing: PPP Baselines + Prices That Feel Local.

Rounding rules per market

A PPP baseline of ₹460 is economically defensible. It's also not a price anyone in India would recognize as a normal subscription price. The number lives somewhere between "too specific to be a real offer" and "rounded weirdly." The fix is per-market rounding rules.

Rounding isn't one global pattern. Every market has conventions that users parse faster because they're used to them.

In the US, prices ending in .99 still dominate. $9.99, $19.99, $49.99. The psychology is well-documented and the habit is deep.

In India, prices commonly end in 99 on larger denominations. ₹999, ₹1,499, ₹1,999 feel native. ₹460 reads as odd. ₹499 reads as a subscription. Your PPP baseline of ₹460 rounds up to ₹499, not because you're gouging, but because ₹499 is a price a user actually recognizes.

In Japan, decimals are effectively never used on subscription prices. Round to whole hundreds or thousands. ¥500, ¥1,000, ¥1,500 are normal. ¥547 is not.

In Turkey, the lira's volatility has pushed rounding patterns toward round tens and round twenty-fives. ₺49.99 and ₺99 both appear, but ₺47.83 looks like a bug in your system.

In Brazil, R$9,99, R$19,99 mirror US conventions with a comma as the decimal separator. Matching that comma-format in the app listing matters for perceived professionalism.

Apple's price point ladder, roughly 900 predefined price points per currency as of March 2026, adds another constraint. You can't set ₹449 on Apple; you pick the nearest tier. Google Play lets you enter an arbitrary local-currency number, so it's more flexible but still benefits from matching local rounding habits. The combination of PPP baseline plus market-native rounding plus store-ladder constraints is what produces a final number that feels right.

App Store Connect vs Google Play Console: how to actually apply it

The two stores diverge meaningfully on the mechanics. If your mental model treats them as two versions of the same system, localized pricing gets harder than it needs to.

App Store Connect runs on a price point ladder. Apple offers roughly 900 price points per currency, and you pick one per territory. You cannot enter an arbitrary number. For each of your in-app purchases or subscriptions, you can set a base price (which Apple then auto-converts using its own tax-aware formulas) or you can override per territory. As of March 2026, Apple supports 175 storefronts, 50 localization languages, and around 44 currencies. The price point ladder is what makes Apple's setup both constrained and predictable.

Apple also has currency anomalies worth knowing. In certain smaller regions, Apple quotes USD rather than the local currency. Which regions shift occasionally; it's a per-territory setting in App Store Connect's Pricing and Availability. These USD-quoted regions tend to be ones where Apple's infrastructure doesn't fully support local currency billing.

Google Play Console takes the opposite approach. You enter any price in the target country's local currency, with no ladder. Google Play supports 77 languages for store listings, and the in-app product pricing surface sits under Monetize > Products > In-app products or Subscriptions, separately from the listing localization surface. Per-country pricing is set inside each product, not via a global override.

The divergence that catches developers off guard: the two stores disagree on currency for several smaller territories. The same country can be quoted in USD on Apple and in local currency on Google Play. If you're running a unified pricing strategy across both, you need a currency map that knows per-country which store uses which currency. If this operational complexity is starting to sound unmanageable by hand, PricePush exists to automate it: PPP baselines, per-market rounding rules, Apple ladder mapping, Google Play per-country pricing, and the currency disagreements, all in one push.

A maintenance cadence that doesn't break you

The biggest failure mode with localized pricing isn't the initial setup. It's the silent drift that happens 3, 6, 12 months later.

Currencies move. The Turkish lira, Argentine peso, and several other emerging-market currencies can shift 10 to 30% in a year. If your PPP-based local prices are entered as absolute numbers in App Store Connect (which they have to be; there's no "track FX" setting), your local prices stay frozen while the local economy doesn't. A price that felt right six months ago can now be mispriced by a material margin.

Tax rules change. Apple's January 2026 tax and pricing update adjusted prices in 9 countries, including a 4-point VAT increase in Kazakhstan, a new 15% VAT in Mauritius (from zero), and a levy removal in Ghana. If you were on auto-convert, Apple applied the adjustments automatically. If you had manual localized prices set, Apple did nothing, and your price now understates or overstates the post-tax number the user sees. Either way, you should know about it.

A workable cadence looks like this. Quarterly review of all localized prices, comparing current FX and PPP data to what's live. Monthly spot-checks on high-inflation markets (Turkey, Argentina, a handful of others depending on the year). Ad-hoc reviews any time you see an Apple Developer News or Google Play Console announcement about tax or price changes. Once a year, refresh the PPP dataset itself using the latest OECD or World Bank release.

The work scales badly by hand. For a single app across 175 Apple storefronts, a careful review is a half-day of grid-staring and ladder lookups. Automation turns it into a diff view. For the narrative side of how the maintenance habit becomes part of the workflow, Localized Pricing 101 for Subscription Apps covers the mindset piece.

For the full standalone walkthrough of why set-and-forget breaks, what a sustainable review cadence looks like across all three drift axes, and how to triage when something moves, see the long-form version of this maintenance argument.

Wrapping up

Localized pricing is four things stacked together: a PPP-based baseline per country, rounding rules that match local conventions, store-specific mechanics (Apple's ladder, Google's per-country currency, and their disagreements on smaller territories), and a maintenance rhythm that catches drift before users do.

None of those steps are conceptually complicated. All of them compound across 190 countries, 2 stores, and ongoing FX and tax shifts. That's why most developers ship one global USD price and call it done.

If you want the whole stack automated, PricePush handles PPP baselines, custom rounding per market, Apple price point mapping, Google Play currency mapping, and territory disagreements for 190+ countries. Free tier covers one app with 10 price pushes, no credit card. Paid plans on the pricing page.

Antonio Founder, PricePush