Most indie devs think the App Store already localizes their prices. It doesn't.

If you have a paid app on the App Store or Google Play, there's a good chance you believe something that isn't true. I believed it for years.

The belief: "Apple and Google handle local pricing for me. I set USD, the stores convert it to something fair for users in India, Brazil, or Turkey."

They don't. What the stores actually do is FX conversion at the storefront's daily rate. That isn't regional pricing. It's math, applied uniformly, to a problem that isn't uniform. And it's quietly costing indie devs revenue in exactly the markets where they have the most installs.

Here's what's actually happening, why everyone gets it wrong, what it costs, and how to fix it on day 1.

The pattern I keep seeing in indie threads

Across dozens of threads on r/iOSProgramming, r/androiddev, and IndieHackers, I see the same misconception over and over. Usually phrased something like:

"I thought Apple converted prices to fair local rates automatically?"

"Doesn't the App Store handle that already? I set $9.99 and let Apple do its thing."

"I assumed setting USD just covered it everywhere."

I'm paraphrasing. These aren't quotes from one person, they're the shape of a question that comes up almost every time pricing gets discussed. I had the same assumption for the first few years I was shipping apps. The misconception isn't an oversight, it's wired into how these consoles present pricing. The default looks like a feature, so most devs ship and move on.

What Apple and Google actually do

Here's what really happens when you set a single base price.

You pick a price in your home storefront, say $19.99 USD. The store applies the daily FX rate for each country's storefront, sometimes nudges it to a tier on Apple's price-point ladder, and shows that number to users.

That's it. No purchasing-power adjustment. No median-income consideration. No "what would $19.99 actually feel like in São Paulo or Mumbai." Just FX conversion, the same operation your bank does when you swipe a card abroad.

A side-by-side, in plain English:

Those two outputs are not the same number, and often not even the same order of magnitude. FX rates measure how much one currency buys of another in financial markets. They don't measure what an app is worth to someone whose monthly disposable income is a tenth of a US user's.

Why almost every indie dev gets this wrong

A few reasons, all reinforcing each other.

First, the language. The pricing UI in App Store Connect tells you that Apple "manages prices in foreign currencies based on the prices you set" in your home territory. Read that quickly and it sounds like a feature. Read it slowly and "manages" here is just arithmetic. It isn't a promise about fairness.

Second, Google's history. Play Console used to have a "pricing templates" abstraction that hinted, loosely, you could express pricing intent across countries. Google removed those templates and the default is now even closer to "set USD and walk away." (I wrote about what changed and how to handle Google Play pricing now when it happened.) Even when templates existed they weren't true regional pricing, they were grouping. But they at least gestured at the idea that one price doesn't fit all.

Third, more honestly: indie devs are busy shipping. Pricing per country sounds like a thing for big publishers with finance teams. So we don't look closely. The store says it handled it. We trust the store.

I trusted the store. Then I looked at install distributions and conversion rates per country for my own apps. The gap was big enough to make me build a tool to fix it.

What the gap actually costs you

Let's get specific. Take a $19.99 base price, which is a common subscription anchor or premium IAP price.

Here's roughly what FX conversion produces in five large emerging markets, versus what a purchasing-power-adjusted price would look like:

The numbers move with FX markets, so treat the FX side as approximate. The PPP side is more stable.

The thing I want to underline is the gap. In India at $19.99, you aren't asking for a US-equivalent price plus a premium. You're asking for three to four times what the same proposition costs locally. To a user looking at your subscription, that price doesn't read as "expensive." It reads as "not for me." They don't object, they just don't convert.

Revenue swing per 1,000 installs depends on your mix. Back-of-envelope: if conversion in India at the FX price is 0.5% and PPP pricing doubles or triples that (the kind of lift the complete guide to localized pricing cites as realistic), you're looking at meaningful incremental revenue from the same install base. Not from new users. From users who already showed up and bounced.

What regional pricing won't fix

Regional pricing is a day-1 default, not an end-stage optimization. With the right tool, the actual setup is a couple of minutes. Done manually across App Store Connect and Play Console, it's closer to a week of work and breaks every time FX shifts. Either way, the old "wait until you have traffic" advice came from the manual era. Once the cost-to-localize collapses to minutes, the threshold for doing it collapses with it. Ship it on launch day if you can.

That said, it's worth being honest about what pricing can and can't do for you. Regional pricing fixes one specific thing: the gap between FX-converted prices and what users in a country can actually afford. It doesn't fix:

• A product nobody wants. If conversion is bad everywhere, including your home market, the fix isn't pricing.
• A broken onboarding. A user who never gets to the paywall doesn't care what's on it.
• Wrong audience targeting. If your installs are bot traffic or wrong-fit users from cheap ad inventory, no price fixes that.
• Subscription churn that isn't price-driven. People leave for product reasons too.

Think of regional pricing as removing a tax you didn't know you were paying. If your funnel is otherwise healthy and you have any meaningful install volume from non-Western markets, the lift shows up. If the funnel is broken upstream, fix that first, then come back.

The signals that regional pricing will move the needle most:

• You run a subscription model. Recurring revenue compounds the gap. A user in Brazil who churns at R$100 but stays at R$30 isn't a one-time sale, they're an annuity.
• You sell paid IAPs above $4.99, especially anything anchored at $9.99, $19.99, or $49.99.
• More than 10-15% of your installs come from emerging markets. Check in App Store Connect under "App Analytics > Sources" or Play Console under "Statistics > Country."
• Your paywall conversion is noticeably worse in non-Western markets than at home. That's almost always pricing, not interest.

If two or more of those are you, this is probably the highest-ROI hour of pricing work you'll do this year. And if none of them are you yet but you're shipping a paid app, do it anyway. You'll never have to come back to it later.

A minimum viable fix: 5 regions, 3 anchor prices

You don't have to localize 175 countries to capture most of the upside. The 80/20 lives in five regions. Here's a starting grid using common $9.99 / $19.99 / $49.99 USD anchors and the rough PricePush PPP indices for each market:

A note on the table. I rounded to local-currency endings the way an indie dev actually would (₹499 reads more native than ₹479). The indices are approximations from my own data and public PPP datasets. Turkey in particular drifts with inflation, so pull the latest numbers in real implementations.

Shipping just these five regions captures most of the upside for most indie apps. You can stop here and be 80% done. For a full per-country breakdown, see the App Store pricing by country guide.

How to actually do this without making it a second job

Two paths.

The manual path. Open each in-app purchase or subscription in App Store Connect, click into pricing, set custom prices per country one at a time. Same in Play Console. The Apple side is harder because Apple uses a price-point ladder: you pick from a mapped set of tiers per country, not arbitrary prices. Your "₹499 in India" has to map to whatever ladder rung is closest, and not every rung exists in every country. This is the part that breaks under maintenance. Every meaningful FX shift, every base-price change, you redo it.

Doable for one app and 5 countries. A part-time job around 3 apps and 10 countries.

The automated path. Connect your App Store Connect and Play Console accounts to a tool that handles PPP calculation, currency overrides, rounding rules, and the Apple ladder mapping. Push once, re-push when your base price changes. There are a few tools in this space now. PricePush is the one I built, specifically because I had this exact problem across my own apps. The broader category is worth knowing about regardless of which tool you pick.

The point isn't which tool. It's that the manual path does not scale, and once you accept the App Store doesn't actually localize your prices, the question stops being "should I do this" and starts being "what's the lowest-friction way."

The takeaway

The App Store and Google Play do FX conversion. They do not do regional pricing. Those two things sound similar in the UI but produce wildly different prices for users in India, Brazil, Indonesia, Mexico, and Turkey. For most indie apps with non-trivial install volume in those markets, that gap is silent revenue loss. You can't see it in your dashboard, the conversions that don't happen don't get logged.

If this post put a small itch in the back of your head, the next reads I'd point at are the complete guide to localized pricing for mobile apps for the depth view, or the 10-minute pricing localization fix if you want to skip the theory and see what your prices should be.

P.S. If you want to use PricePush specifically, the founding lifetime offer is still available while the spots last.