How to Change Your App's Price in App Store Connect (Step by Step)

Once you've worked out what your app should actually charge per country, the last mile is applying it in App Store Connect. The workflow has stayed conceptually the same for years, even as Apple has reshuffled the exact screens around it, so here's the part that matters: what's actually happening, not just which button to click this month.

Where pricing lives

Inside App Store Connect, go to your app and open Pricing and Availability. This is the single screen that controls both your base price and every territory-specific price, current and scheduled.

Base price vs per-territory price

Set one base price, and Apple auto-generates a price for every other territory using its own exchange-rate table. That default is currency conversion, not purchasing-power localization, and the two produce very different numbers. If you want an actual localized grid, you override individual territories manually with the price tier you've calculated, rather than accepting Apple's auto-generated one.

Applying a localized price grid

Run your base price through the calculator to get a recommended tier for each of the 73 covered territories, then, for each territory you want to override:

1. Open Pricing and Availability for the app.
2. Add or edit a price point for that specific territory.
3. Pick the tier closest to your calculated recommendation. Apple's tiers are fixed per territory, which is exactly why the calculator rounds to a real tier instead of a raw number you couldn't actually select.
4. Repeat for each territory you're overriding, or export the CSV from the calculator and work through it as a checklist.

There's no bulk-import for this today, applying a full 73-country grid is genuinely manual, territory by territory. It's tedious once, not difficult, and it only needs redoing when your base price or the underlying purchasing-power data changes meaningfully.

Scheduling instead of changing immediately

Price changes in App Store Connect can be scheduled for a future effective date rather than applied instantly. That's the mechanism to use if you want to test a new price in a couple of territories before rolling it out everywhere: schedule the change for your test markets, watch conversion and refund rates for a couple of weeks, then decide whether to extend it.

The rule that catches people out: existing subscribers

Price increases on an active subscription are not silent. Apple requires existing subscribers to be notified of a price increase, and depending on the size of the increase and local consumer-protection rules, some subscribers may need to actively accept the new price to keep their subscription rather than have it renew automatically. Practically: a price increase can cost you some subscribers no matter how you roll it out, budget for that churn rather than being surprised by it. New-user pricing is unaffected either way, only renewals of people already subscribed at the old price are in scope.

Price decreases, including most purchasing-power localization work (since it usually lowers prices in specific territories rather than raising them everywhere), don't carry this requirement. That's one more reason localization is a lower-risk change to ship than an across-the-board price increase.

The practical order of operations

1. Decide your base (home-market) price.
2. Localize it for every territory you sell in, rather than accepting Apple's currency-converted default.
3. Apply the grid in Pricing and Availability, territory by territory.
4. If you're also raising your base price for existing users, expect the subscriber-notice flow and some churn as part of that, separately from the localization itself.

Google Play Console follows a similar shape (a base price, per-country overrides, scheduled changes), with its own console and its own mechanics for existing subscribers. That's worth its own walkthrough rather than a footnote here.