Apple's globally equivalent pricing: what it means and when to disable it

Apple's globally equivalent pricing auto-converts your base-country price to all 175 storefronts using exchange rates — a convenient default that can silently misfire in volatile-currency or high-PPP-gap markets. Here's how the system works and when to override it.

When Apple overhauled its App Store pricing infrastructure in late 2022 and into 2023, the headline number was impressive: more than 900 discrete price points across 175 storefronts, up from roughly 100 tiers in the old system. What received far less attention was the quiet default that ships with every new price you set — globally equivalent pricing, Apple's built-in mechanism for automatically converting your base-country price to every other territory using the platform's own foreign-exchange reference rates.

For a solo developer shipping their first global app, this sounds ideal. Set one price, let Apple handle the rest. The reality is more nuanced. Exchange-rate volatility, the structural gap between nominal FX rates and real purchasing power, and consumer psychology in specific markets all mean that "globally equivalent" and "commercially optimal" are rarely the same thing. This post explains exactly how the mechanism works, when you can safely trust it, and the three situations where overriding it is essential before it quietly costs you conversions.

How globally equivalent pricing works

Apple's pricing framework centres on a base country or region that you designate in App Store Connect. When you set a price for your app or in-app purchase in that base country, the system automatically calculates prices for all other storefronts. The calculation uses Apple's internal foreign-exchange reference rates, which are updated periodically — not in real time, but frequently enough that significant currency moves (historically around 15–20% or more) will eventually trigger a recalculation across affected storefronts.

The auto-generated prices are not a raw currency conversion. Apple snaps the arithmetic result to the nearest available tier within its 900+ price-point grid. So a $9.99 base price will not produce a precisely equivalent local amount — it will produce the closest available tier in each currency, which can differ meaningfully from the direct conversion. The effect is most visible in currencies that use large nominal numbers (Japanese yen, Indonesian rupiah, Korean won), where tier-snapping can produce a result 5–10% away from the raw conversion in either direction.

Setting the United States as your base country — the most common default — anchors everything to USD. If the dollar strengthens against the Turkish lira or the Brazilian real, your auto-generated local prices fall in real-dollar terms. If Apple subsequently triggers a recalculation because the divergence has grown large enough, local prices can jump upward abruptly, even though you never deliberately touched anything.

The gap between FX-equivalent and PPP-adjusted prices

To make this concrete, consider a subscription app priced at $4.99 per month in the United States. The table below compares what globally equivalent pricing produces in four representative markets against a typical PPP-adjusted manual override. The specific figures will differ based on Apple's current tier grid and the live exchange rate when you read this — the point is the direction and scale of the divergence.

These figures are directional estimates based on World Bank PPP data and approximate App Store tier grids, not live exchange rates. The pattern they illustrate is consistent with findings from RevenueCat's published benchmark reports: in high-income, FX-stable markets like the UK, Germany, and Australia, auto-generated prices land within a range consumers accept. In emerging markets with large PPP gaps — India, Brazil, Indonesia, Turkey — the auto-generated price frequently exceeds what the market will bear at high conversion rates.

RevenueCat's data has consistently shown that subscription conversion rates in lower-PPP markets respond strongly to local price adjustments. Developers who have moved from FX-equivalent to PPP-aligned prices in markets like India and Brazil have reported conversion-rate improvements substantial enough to offset the lower per-unit price, producing higher net revenue from those territories. Phiture has reported similar directional findings in its App Store Optimization research. For a deeper look at the underlying economics, see our post on why iOS subscription churn is higher in low-PPP markets.

When the defaults are good enough

Globally equivalent pricing is genuinely useful in two categories of situation, and recognising them prevents unnecessary operational complexity.

High-income, currency-stable markets. If your storefront mix is primarily the US, UK, Germany, Australia, Canada, Japan, and South Korea, the FX-based auto-generated prices tend to sit within a reasonable range of local purchasing power. These economies have relatively small PPP gaps with the US, and their currencies are liquid enough that Apple's reference rates stay reasonably current. Unless you have a specific competitive or promotional reason to deviate, the defaults save you the overhead of managing individual territory prices for markets that are already converting well.

Early-stage apps with limited international traffic. If you are seeing only a small number of downloads per month outside your home market, the revenue impact of suboptimal pricing is modest. Researching PPP-adjusted prices for thirty territories is a poor use of time when you have a few dozen international subscribers. Set reasonable defaults, watch your territory-level analytics as volume grows, and revisit when a specific market starts mattering to your revenue line.

Three scenarios that demand manual overrides

Outside those two categories, there are specific situations where relying on globally equivalent pricing can quietly erode your position.

1. High-volume emerging markets. India, Brazil, Indonesia, Mexico, and Turkey collectively represent a large and fast-growing share of App Store installs. In all five, the gap between nominal exchange rates and real purchasing power is material. Research from Phiture and data published by RevenueCat both point in the same direction: developers who localise pricing in these markets see meaningfully better subscription conversion. The logic is not complicated — a lower price that converts at several times the rate generates more revenue than a higher price that barely converts at all. For any market where you are seeing healthy organic install volume but poor subscription attach rates, the price is the first variable to examine.

2. Post-devaluation currency environments. When a currency depreciates sharply — as the Turkish lira, Argentine peso, and Nigerian naira have each done at various points — Apple's periodic auto-recalculation can push local prices upward in ways that feel abrupt and arbitrary to existing subscribers. This is one of the most overlooked risks of relying on the defaults. A subscriber in Turkey who has been paying a stable local amount for two years may see their renewal price jump significantly after a recalculation, even though you never deliberately changed anything. Proactively setting a stable manual price in high-volatility currency markets, rather than waiting for Apple's FX update to trigger churn, is the more defensible posture. See also our post on Apple's grandfathering rules for subscription price changes — existing subscribers are protected under specific and narrow circumstances, but the rules do not cover every scenario.

3. Markets where competitors have established a price anchor. In some territories, particularly those with a dominant local competitor or a strong cultural norm around what a subscription category costs, an FX-equivalent price can land in a psychologically uncomfortable position. If every comparable productivity app in South Korea is priced at ₩4,900 per month and your auto-generated price comes out at ₩6,900, you may be losing conversions not because ₩6,900 is unaffordable in absolute terms but because it feels misaligned with the established market expectation. Manual overrides let you match or undercut those anchors deliberately rather than hoping the FX arithmetic lands where you need it to.

Setting manual territory overrides in App Store Connect

The mechanics are straightforward, though the interface rewards patience for anyone managing a large product catalogue.

1. In App Store Connect, navigate to your app and open the Subscriptions or In-App Purchases section depending on your product type.
2. Select the specific product and open its Pricing section.
3. Choose Set Prices by Territory. You will see all active storefronts with their current auto-generated prices displayed.
4. Click any individual territory to set a manual price. Once you enter a manual price for a storefront, that territory is decoupled from the auto-generated recalculation — future FX updates will not override your manual selection.
5. To re-link a territory back to globally equivalent pricing, you can reset it to the automatic calculation at any time.

If you are managing many products across many territories, the manual UI becomes a bottleneck quickly. Our post on building a price-update workflow with the App Store Connect API covers how to automate territory-specific overrides programmatically using the appPriceSchedules endpoint. For teams running quarterly pricing reviews across a catalogue of more than a handful of products, automating the override layer is worth the upfront investment.

One practical rule of thumb: set your manual territory overrides before publishing a base-price change, not after. If you rely on globally equivalent pricing to propagate first and then try to correct specific territories, there is a window where subscribers in those territories see the uncorrected price. For apps with meaningful volume in sensitive markets, pre-setting manual prices before any base-price change is the cleaner and safer approach. The AppsOps pricing tool can surface your current territory coverage and help identify where auto-generated prices may be diverging from local market norms.

Sources and further reading

• Apple Developer — Manage app pricing (App Store Connect Help)
• Apple Developer — App pricing overview
• RevenueCat blog — App monetisation data and insights
• World Bank International Comparison Program — PPP data
• Phiture Mobile Growth Stack — App Store Optimization resources
• AppFollow blog — App Store intelligence and market analysis