Price localization is the practice of setting a different price for the same app or subscription in each market, based on what that market will actually pay, instead of running one global price through a currency converter. Done properly, it factors in local income, competition, and price psychology, alongside the exchange rate rather than instead of everything else.
Most apps skip that work. They pick a $9.99 subscription, let the App Store or Google Play auto-convert it into every storefront, and call the result "international pricing." What they've actually shipped is a currency conversion dressed up as a pricing strategy, and it leaves money on the table in nearly every market outside the US, UK, and a handful of other high-income countries.
Why uniform, FX-converted pricing bleeds revenue
Here's the mechanism most operators miss: Apple and Google don't price your app for local affordability. They price it for currency equivalence. Your $9.99 subscription becomes ₹829 in India, ¥1,500 in Japan, or R$54 in Brazil because that's roughly what $9.99 is worth today, not because that's what a user in Mumbai, Tokyo, or São Paulo can comfortably spend.
That gap matters because income doesn't move with exchange rates. A $9.99 US subscription assumes US disposable income. Convert it at spot rate into India and you get a price that, relative to local income, sits closer to $40 or $50 in US terms. Most users see that price, wince, and close the app. You never find out they would have paid, and you never see the conversion you left behind.
A blanket discount everywhere won't fix that. The fix is a price per market that reflects what that market's users actually spend on comparable apps, set deliberately rather than inherited from an exchange-rate table.
How operators actually run price localization
This is the operator sequence, in order. Skip a step and the numbers you end up with are guesses dressed as data.
1. Audit what you're currently charging, market by market
Pull your live price list across every storefront and lay it against local income and local competitor pricing. Most teams have never actually looked at this list end to end. It's usually a mix of Apple's auto-conversion, a handful of manual overrides from two years ago, and whatever Google Play's default happened to be the day the app launched. That's your starting point, and it's rarely intentional anywhere outside your home market.
2. Find the willingness-to-pay gaps
For each market, compare your current price to what comparable apps in your category actually charge there, and to what users in that country are known to pay for similar subscriptions. Markets where you're priced far above local norms are conversion problems. Markets where you're priced far below are revenue you're giving away for free. Both are worth fixing, and they usually aren't the same set of countries.
3. Set per-market prices inside the platform's price tiers
This is where the mechanics of each store start to matter, and it's the step most guides skip. You can't just decide India should be $2.99 equivalent and type that number in. Apple and Google each run their own tier and increment systems, covered below, and your target price needs to land on an available point in that system.
4. Ship the changes deliberately, not all at once
Roll changes out market by market, or in small batches, so you can attribute what happens to which change. A blanket repricing across 175 storefronts on the same day makes it impossible to tell whether India moved because of the new price or because of something else entirely that week.
5. Measure, then repeat on a schedule
Conversion rate and revenue per market, before and after. Currencies drift, local income shifts, and competitors reprice. A price that was right six months ago quietly stops being right, and nobody notices until a quarterly review turns up a market that's been underperforming for a while.
A concrete version of this sequence: say your app runs a $19.99/month subscription, auto-converted into ₹1,899 in India. That's the FX-equivalent price and it's a poor fit for a market where users routinely pay far less for comparable subscription categories. An audit against real Indian app transaction data might show the price that actually converts sits closer to ₹659, roughly a third of the FX-converted figure. Set that number inside Apple's or Google's available price points, ship it to India specifically, and watch conversion and revenue in that market over the following weeks before touching anything else.
What "respecting the platform's price tiers" actually means
This step trips up more operators than any other, because the two stores don't work the same way. Apple runs a fixed tier system: you pick from a defined set of price points rather than typing in an arbitrary number, and each tier maps to a specific local-currency price per storefront that Apple itself sets and updates. If your target price for a market doesn't land exactly on an available tier, you round to the nearest one and accept the small gap, rather than trying to force an exact match that doesn't exist in the system.
Google Play historically allowed more granular control, letting developers set close to any value in local currency for each country. That flexibility still exists at the individual product level, but it now comes with more manual overhead per market since the bulk-editing shortcut described below went away. Either way, the target number from your willingness-to-pay analysis is a goal to round toward, not a price you can simply paste in and expect the platform to honor exactly.
Apple and Google localize prices differently, and both work against you by default
Apple's App Store runs your base price through a fixed conversion across 175 storefronts and 44 currencies. It equalizes on exchange rate, not on purchasing power. That's the entire mechanism: it takes your USD price, applies the current FX rate, rounds to local pricing conventions, and calls it done. There's no local income data in that calculation anywhere.
Google Play works on the same FX basis. For years, bulk per-country adjustments were easier there through pricing templates, letting you group markets and apply changes across them at once. Google removed pricing templates from Play Console on October 27, 2025. Bulk per-country pricing now runs through the API or through third-party tooling, not through a console screen you can click your way through. If your team was relying on that console workflow, it no longer exists, and manual per-market editing at any real scale isn't a serious option.
Neither store is going to localize your pricing for you. Both will happily convert it, which is not the same thing, and both require you to work inside their tier systems once you've decided what a market's real price should be.
The Mirava Index: real transactions, not a macro guess
Most of the tools people reach for here weren't built for this. The World Bank's PPP tables, the Big Mac Index, GDP-per-capita comparisons, even Netflix's own regional pricing, are all macro proxies. They estimate what a country can afford from national-level economic data, like average income or the price of a burger, and then apply that estimate to every app in every category.
The Mirava Index works differently because it's built from real app subscription transactions across more than 170 countries, not from government income statistics or fast food menus. It reflects what users in a given market are actually paying for comparable apps right now, which is a direct read on willingness to pay rather than an inference from GDP. A country can have modest average income and still support strong app subscription pricing in certain categories, and a macro proxy has no way to catch that. Real transaction data does.
That distinction matters for the price you end up setting. A PPP table might tell you India's purchasing power sits at some fraction of the US, and hand you a price derived from that ratio. The Mirava Index tells you what apps like yours are actually charging Indian subscribers today, and converting at what rate, which is the number that predicts conversion rather than the number that predicts affordability in the abstract.
On early Mirava users, teams that moved from FX-converted pricing to Index-based per-market pricing have typically seen revenue gains in the 15-40% range. That's an observed range on early adopters, not a promise, and results vary by category, market mix, and how far off the original pricing was to begin with.
None of this requires full automation to act on. What ships today is manual-approve and rules-based modes: you see the recommended price per market, you approve the change yourself, or you set caps that keep any adjustment inside bounds you define. The judgment call stays yours.
Wondering what your current pricing is actually leaving on the table?
The Mirava Index shows what comparable apps charge in every one of your markets, built from real subscription data instead of an FX table. See what comparable apps charge
Where this fits with the rest of your pricing strategy
Price localization isn't a standalone project. It sits on top of decisions you've probably already made about multi-currency subscription pricing and how currency swings affect your subscription metrics month to month. Once your per-market prices are set from real willingness-to-pay data rather than FX conversion, the next layer is presentation: how regional pricing boosts revenue once you've picked the right numbers, and charm pricing conventions by country so a technically correct price still reads as a normal, trustworthy number to a local buyer.
The platform mechanics differ enough between stores that they're worth understanding on their own terms. How localized pricing actually works in the App Store and the equivalent for Google Play both go deeper into the tier systems and update mechanics touched on above. If purchasing power is the concept you're trying to get right, setting up PPP-informed pricing is the practical next read, with the same caveat that applies throughout this piece: lead with real transaction data, the Mirava Index, and treat a PPP table as a rough starting point rather than the finished number.
The short version
A single global price, run through Apple's or Google's currency conversion, amounts to the absence of a pricing strategy. Price localization means auditing what you actually charge today, finding where that number diverges from what each market will really pay, and setting deliberate per-market prices that respect each platform's tier system. Apple equalizes by exchange rate across 175 storefronts. Google does the same and, since October 2025, no longer offers a console shortcut for doing it in bulk. Whichever store you're fixing first, the number to chase isn't a GDP ratio or a Big Mac price. It's what real subscribers in that market are already paying for apps like yours.
