Price Localization for Apps: What It Means and How to Do It on Both Stores

Price localization for apps means setting a different price in each country, based on what people there can actually pay, instead of converting one US price with the exchange rate.

Take a $19.99 subscription. Converted at the exchange rate, it is about R$110 in Brazil and ₹1,881 in India. Localized to purchasing power, it is R$52.90 and ₹680. Same app, same value, a price people in those countries can say yes to.

I checked every number and store rule in this post on 8 November 2026.

A friend of mine, also an indie dev, once asked me three questions about this: why is it so hard, why not just script it, and does it actually move revenue? My long reply turned into the first version of this post. Here is the updated one, with the how-to for both stores.

Price localization vs app localization

A localized app usually means a translated app: the interface, the store listing and the screenshots in the user's language. Price localization is the other half, and it is not a translation problem. It is a market-fit problem expressed in numbers.

You can translate your app into Portuguese and still charge Brazil a price set for a US wallet. Most apps do exactly that, because the stores make it the default.

Why the stores don't do it for you

Both stores fill in your other countries from one price, using exchange rates. On the App Store you set a base storefront and Apple generates the other 174. On Google Play you set a default price and Play Console converts it for every country.

An exchange rate tells you what your dollars are worth. It says nothing about what people earn. That is why a converted price lands far too high in most of the world, as I explained in does the App Store localize prices.

Click to enlarge

Step 1: Pick the index that sets the price

Once you accept that each country needs its own price, the question is what to base it on. The usual candidates:

• Purchasing power parity (PPP) from the World Bank. Compares what the same basket of goods costs in each country.
• The Big Mac Index from The Economist. Same idea with one burger as the proxy.
• What Netflix and Spotify charge per country.
• GDP per capita.

The Big Mac Index is fun, but it reflects beef, labor and rent, not what people spend on apps. Netflix and Spotify prices reflect years of testing, but also content deals and brand pull most apps don't have. GDP per capita measures income, not how much of it goes to software.

For mobile apps, purchasing power parity is the closest fit, and that matches what pricing people who have run real A/B tests have told me. I don't use it raw, though. Public data is the starting point. Which tier each country sits in comes from more than three years of pricing experiments on my own apps, with real buyers. That tuned version is what PricePush ships with.

Google's Playtime 2019 talk on subscription price localization, with Headspace as the case study, is still the best public explanation I know.

Step 2: Set the prices on the App Store

In App Store Connect, prices live on each product: every in-app purchase and every subscription has its own price schedule.

1. Open the product and its price section, and set the price for your base storefront.
2. Apple fills in the other 174 storefronts from it.
3. Edit the storefronts you want to localize, one by one.

Two things trip people up. First, you can't type any amount: Apple offers a fixed set of price points per currency, up to 900 of them, so your localized price has to snap to one that exists. The details are in App Store price tiers and price points. Second, some storefronts are priced in US dollars, not the local currency, so "local" sometimes means a lower dollar price. The step-by-step for changing a price, subscriptions included, is in how to change app prices in App Store Connect.

Step 3: Set the prices on Google Play

In Play Console, each product also has its own prices. You set a default price, Google converts it for every country, and then you edit the countries you want to change.

Google is more flexible here: you can enter almost any amount in the local currency. The catch is that the currencies don't always match the App Store's. Algeria, for example, is priced in dollars on the App Store and in dinars on Google Play, so the same country needs two different numbers.

Google also took away its shortcut. Pricing templates, which let many products share one set of prices, stopped managing prices on October 27, 2025. Every product is now priced on its own, by hand or through the API.

The size of the job

Now count. One app, three products (monthly, yearly, lifetime), about 175 countries, two stores.

Click to enlarge

That is around 1,050 prices for one app, before introductory offers, promotional offers or a second app. For each one you look up the target price, find the country, type it, and save. One typo and a country gets a price that is accidentally free or accidentally absurd.

For my own apps, a full pricing refresh used to take me a week. And it was never the last one: exchange rates move, so localized prices drift and need redoing.

"Can't I just script it?"

Every technical founder asks this. The answer is yes, technically, and it is much harder than it looks.

• The APIs are strict. App Store Connect has rate limits that a naive script burns through before it does anything useful. Neither store keeps a history of your old prices or offers a rollback.
• Apple's price points have to be loaded and matched per currency before you can send a single price.
• You need more than a script: a queue so you don't hit rate limits, retries because the APIs fail, encrypted storage for your keys, and a record of every change so you can undo a bad push.

I built all of that, and it took months, not a weekend. I wrote up what DIY pricing scripts usually miss if you want to try anyway.

Does price localization move revenue?

The gap it targets is real. RevenueCat's State of Subscription Apps 2026 puts the median revenue per install 60 days after download at about $0.55 in North America and about $0.11 in India and Southeast Asia, a five-fold difference.

In my own apps, moving from one flat US price to localized prices lifted revenue by 20 to 50% in the international markets where the converted price was furthest above purchasing power. Markets close to the US price barely changed. The biggest lifts came where the converted price sat two to four times too high. Same users, same app, only the price changed.

The evidence from other apps is in does parity pricing grow app sales.

How PricePush does it

I built PricePush because I was tired of doing all of this by hand for my own apps.

It calculates a price for every country from your base price, using the PPP-based tiers tuned on my own apps. It snaps each one to a price the store accepts, with local endings, and handles the currency differences between the two stores. Then it pushes every country to the App Store and Google Play in one step, in the background, within the rate limits. You see every price before anything changes. On the Pro plan, every push is kept in your history and you can restore earlier prices with one button.

You can see your own numbers first with the free price localizer, no login. Or try it on one app: the Starter plan is a 7-day free trial, no credit card. For the full picture of localizing across every market, read the app pricing localization guide.

Quick answers

What is price localization? Setting your app's price per country from local purchasing power, instead of converting one price with the exchange rate.

Is a localized app the same as a localized price? No. A localized app is translated. A localized price is set for what people in that country can pay. You need both.

Do the App Store and Google Play localize prices for me? No. They convert your price with exchange rates, which keeps your dollar value, not your buyers.

How often should localized prices be updated? Whenever exchange rates have moved enough to matter, and at least once a year. Set-and-forget prices drift.