PPP rebalance: the new prices are the easy part

Recomputing your purchasing-power prices takes an afternoon. Shipping that rebalance across the App Store and Google Play, without overcharging the subscribers you already have, is the part that takes a system.

That gap is why "PPP rebalance" is becoming its own phrase. A year ago you localized your prices with purchasing power parity, felt good about it, and moved on. Since then the Turkish lira, the Argentine peso, and a dozen other currencies kept moving, and the prices you set are quietly wrong again. A PPP rebalance is the act of fixing that, on a schedule, rather than once.

The new wave of PPP calculators, scripts, and even MCP commands will hand you a fresh column of numbers in seconds. That part is genuinely solved. But the numbers are maybe 10% of the job. This post is about the other 90%: knowing when a rebalance is actually needed, not breaking the price for your existing subscribers, and getting the change live across two stores with different rules. If you ship to both the App Store and Google Play, that is where the real work lives.

Rebalancing is one stage of a larger discipline. For the full picture it sits inside, see the pillar on app pricing localization.

What a PPP rebalance actually is

A PPP rebalance is the periodic act of recomputing your localized prices and pushing the changes live, because the inputs that produced your last set of prices have drifted.

It is worth separating from the first time you localize. Initial localization is a one-time decision: you take your base price, apply purchasing-power data, and set per-country prices that feel fair in each market. A rebalance is the recurring version of that same decision, run against inputs that never stop moving: foreign exchange rates, local income levels, and the store price ladders themselves.

Apple alone exposes roughly 900 fixed price points per currency across 175 storefronts, and it periodically updates that ladder. Google Play lets you set a specific local price per country. So your "set" of localized prices is really a few hundred individual numbers per SKU, each tied to a currency and an income level that shift independently. A rebalance is how you keep that set honest over time. The term is new, but the maintenance problem is not, and I wrote about why set-and-forget pricing does not work before the phrase existed.

The easy part: producing the new numbers

Let me give the calculators their due. Computing a rebalanced price is not hard.

The math is well understood: take a PPP index for each country, apply it to your base price, snap to the nearest valid price point, round to something that looks deliberate. A free tool, a spreadsheet, a short script, or an MCP command can all do this. If someone tells you the calculation is the hard part, they are selling the easy 10%. I covered the actual baseline math in real localized pricing: PPP baselines and prices that feel local, and none of it requires a platform.

So if the numbers are easy, why does a rebalance still eat a developer's week? Because producing a column of target prices is not the same as safely changing the prices customers are paying, in two stores, without collateral damage. Everything past the calculation is the part the calculators leave to you.

When to rebalance: FX drift is the trigger nobody automates

The first hard question is not "what are the new numbers." It is "do I even need to change anything right now."

This is the prerequisite the tools skip. A rebalance is only worth running when the gap between your intended prices and reality has grown past a threshold. In stable currencies that can take a year. In volatile ones it takes a quarter. The Turkish lira has lost more than half its value against the dollar over the past few years, and currencies like it and the Argentine peso can swing sharply within a single quarter, which means a price you set twelve months ago is not slightly off, it is a materially different price in purchasing-power terms.

You cannot eyeball that across 175 storefronts. Detecting it means comparing your intended prices against what is actually live in each store, and against current FX and PPP data, then flagging only the markets that have drifted enough to matter. That is price drift detection, and it is the difference between a rebalance you run on purpose and a rebalance you run in a panic because revenue dipped. It is also the same lesson as App Store discovery: the algorithm moves on Apple's schedule, but your price is the input you control, so it is worth keeping it right. Inside PricePush, drift detection is what tells me which countries to even look at before a rebalance.

The hard part: your existing subscribers

Here is the trap a column of numbers walks you straight into.

Most of a PPP rebalance is price decreases. Purchasing power says charge less in lower-income markets, and decreases apply cleanly: existing subscribers either keep their current price or get the lower one, and nobody is upset. The danger is the other direction. When a currency moves against you, or you were underpriced to begin with, the rebalanced number is higher, and a price increase on an auto-renewable subscription is not a simple field edit.

Both stores wrap increases in consent and notification machinery, and the rules differ. Apple lets you preserve the current price for existing subscribers, or apply the new one to everyone. Push it to everyone and an increase above Apple's thresholds, more than 50% and about $5 per period (or $50 a year for annual plans), or a second increase within twelve months, triggers a consent flow: Apple notifies the subscriber and will not apply the new price until they agree. Google Play defaults to the opposite, placing existing subscribers in a legacy price cohort that keeps their old price, and treating increases as opt-in, so subscribers must accept the new price or the subscription cancels. The exact thresholds shift, so check each store's current docs before you push, but the principle holds: a rebalance that blindly applies a higher number can fail to take effect, churn loyal subscribers, or trip a consent flow you did not plan for.

This is why I treat every rebalance as a versioned change with a way back. I wrote about that pattern in updating app prices safely with versioning, history, and rollback. A calculator does not know who your existing subscribers are. The store does, and so should your rebalance.

The other hard part: two stores, different rules

Even setting subscribers aside, getting the new prices live is its own project, and it doubles because you ship to two stores.

On the App Store, you cannot set an arbitrary number. Every price has to land on a rung of Apple's price-point ladder, so your clean PPP figure gets snapped to the nearest valid point, which can undo your rounding if you are not careful. You also want per-market rounding that looks native rather than mechanical, and Apple's API enforces rate limits, so pushing hundreds of price points across 175 storefronts has to be paced and batched or it stalls. Google Play runs on a different model: local currency by default, its own tax handling, and a separate console and API.

Doing that by hand, across two stores and every SKU, is the work that turns a five-second calculation into a lost week. It is also exactly what an iOS-only script or MCP command does not touch, because it stops at the numbers. PricePush is built for this half: it maps prices onto Apple's ladder, applies your custom rounding per market, paces the push around Apple's rate limits, and updates both the App Store and Google Play from one step, so the rebalance you calculated is the rebalance that actually ships.

Make a rebalance repeatable, not heroic

The goal is to stop treating a rebalance as an annual fire drill.

A repeatable rebalance has three parts: a trigger (drift past a threshold, or a fixed quarterly check), a safe push (grandfather-aware, snapped to valid price points, rate-limit paced), and a record you can roll back. When those exist, a rebalance is a ten-minute review instead of a week of console work, and you run it often enough that your prices never drift far in the first place.

That cadence compounds where it counts. A price that stays aligned with local purchasing power keeps converting in price-sensitive markets, and conversion rate is a signal both stores reward. Skip rebalancing and the opposite happens quietly: your emerging-market prices creep out of range, conversion slips, and you only notice when the revenue chart does. For the full picture of where pricing sits in a localization strategy, the pillar on App Store localization beyond language translation puts it in context.

The takeaway

A PPP rebalance is easy to calculate and hard to ship. The numbers are an afternoon and a free tool. The system around them, knowing when to rebalance, protecting your existing subscribers, and getting the change live across two stores with different rules, is the part that actually decides whether your prices stay fair.

That system is what PricePush is. It detects which markets have drifted, computes the rebalanced prices with purchasing-power data, handles grandfathering and per-market rounding, and pushes to both the App Store and Google Play in one paced, versioned step you can roll back. You can try it free on one app and see your own drift before you rebalance, and plans plus the founding lifetime offer are on the pricing page.