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

Changing one price in App Store Connect takes about a minute. Changing it so it actually fits all 175 storefronts, and keeping it that way, is the part Apple does not warn you about. And it is three separate jobs, because a paid app, an in-app purchase, and an auto-renewable subscription each change price in a different place, under different rules.

I have shipped App Store apps since 2012, and the price fields are the one corner of App Store Connect that looks simple and is not. Apple rebuilt pricing across 2022 and 2023 around price points and a base region, which made the first price easy and the hundredth price tedious. And the prices it generates for every other country are a straight currency conversion of your base price, which is not the same as a price built for that market.

This is the plain walkthrough: how to change your app's price in App Store Connect for each product type, where the fields actually live in 2026, the conversion-versus-localization trap that catches most developers, and the point where doing it manually stops making sense. If you sell in more than a handful of countries, the last two sections are the ones that matter.

If you are setting a price for a launch rather than a routine change, get it right before you open pre-orders, since app pre-launch marketing commits your prices the moment pre-orders go live.

How App Store Connect pricing works now

Since Apple's 2022 and 2023 pricing overhaul, you no longer type a dollar amount. You pick a price point from a fixed ladder, and every currency has up to 800 of them by default. You choose one country or region as your base, set the price there, and Apple generates the price for the other 174 storefronts automatically, using current foreign exchange rates and each country's tax rules.

That auto-generated grid is the thing to understand before you change anything. It is a straight currency conversion of your base price, rounded to the nearest local price point. It is not a localized price. A number that is right for a buyer in the United States becomes a number that is too high for a buyer in India or Brazil once it is just converted at spot rate. Apple gives you the option to override any territory by hand, one at a time, which is the only way to set a price that actually fits a market. That distinction, conversion versus localization, is the whole reason Apple does not localize your prices for you, and it is the backdrop for every price change below.

How to change the price of a paid app

For a paid app, the flow lives in App Store Connect under your app, on the Pricing and Availability page.

1. Go to My Apps, select the app, and open Pricing and Availability.
2. Under the current price, choose a new price point from the dropdown. The ladder of roughly 800 points is what constrains the exact numbers you can pick, so you will land on 4.99 or 5.99, not 5.49 unless a point exists for it.
3. Pick your base country or region. Apple fills in the other 174 storefronts from that anchor.
4. Review the auto-generated grid. If a converted price is wrong for a market, override that territory by hand.
5. Save, or schedule the change with a start and optional end date.

For a paid app, Apple will also keep adjusting these prices for you over time when exchange rates or taxes move, unless you have set manual per-territory prices. That automatic maintenance is a convenience for one app with one price. It is also why most developers never localize, they let the grid ride.

How to change an in-app purchase price

A one-time in-app purchase, a consumable or non-consumable, works the same way, just in a different tab. Open the app, go to In-App Purchases, select the product, and open its Price Schedule. You pick a price point and a base region exactly as you do for the app itself, and Apple generates the rest of the storefronts.

Two things worth knowing here. First, each in-app purchase has its own schedule, so a change to one product does not touch the others, and an app with a dozen IAPs is a dozen separate price changes. Second, like paid apps, non-subscription in-app purchases are inside Apple's automatic exchange-rate and tax updates, so Apple will nudge these prices over time on its own. If you want a record of what changed and the ability to walk it back, that is worth setting up before you start editing at scale, which is the point of treating price updates as versioned changes.

How to change an auto-renewable subscription price

Subscriptions are the one that behaves differently, and it is the change most likely to bite you.

Open the app, go to Subscriptions, select the subscription group, then the specific auto-renewable subscription. Under Subscription Prices, click Plan Subscription Price Change, then select the countries or regions you want to edit. You set the price point per territory, and Apple lets you schedule one future price change at a time, per country or region, per billing plan type. Scheduling a second change overwrites the first.

The catch is what happens when the new price is higher than the old one for existing subscribers. Depending on the size and frequency of the increase, Apple either sends those subscribers a notice or requires their active consent to keep the subscription going. Consent is required, rather than a silent notice, when the increase is steep, roughly more than 50 percent and more than 5 dollars per period, or when you already raised the price in the past year. A price increase you did not think through can pause billing for subscribers who never tap to agree. So a subscription price change is not just a number edit, it is a retention event, and it is worth reading Apple's subscription pricing help before you schedule one.

The trap in the auto-generated grid: conversion is not localization

Here is the part that is easy to miss and expensive to ignore. Every price in that auto-generated grid is a currency conversion of your base price, and a currency conversion is not a localized price.

Set your base at 9.99 in the United States and Apple fills in every other storefront by converting that number at the current exchange rate. The conversions are accurate and the prices are still wrong, because 9.99 of spending power in the United States is not 9.99 of spending power somewhere else. In India, where local purchasing power is a fraction of the United States, a price that fits the market is closer to a third of the US number, not a near-full conversion of it. The auto-generated price charges close to the full amount, so it often lands two or three times too high for the market, and your conversion rate there quietly reflects that.

A straight conversion also ignores everything moving underneath the exchange rate. Local incomes, inflation, and what a customer in that country can actually pay do not show up in an FX feed. A market can get materially cheaper or more expensive in real terms while the converted price barely moves, because the model only tracks the currency, never the economy.

This is the same for all three product types. Apple keeps a paid app or in-app purchase converted at the current rate, so the number stays a fresh conversion and still not a local price. For a subscription you set and maintain each storefront yourself. Either way, nobody in that pipeline is asking the question that matters, which is what this should cost in this country. That gap, currency conversion versus purchasing-power localization, is the difference between a price that is technically correct and a price that actually sells, and it is why the auto-generated grid is a starting point, not an answer.

When one price change becomes 350

Now multiply. To truly localize instead of convert, you override price per territory, which is up to 175 storefronts. You do it again for every in-app purchase and every subscription, because each product has its own schedule. You redo it whenever a market moves enough to matter. And then you do the entire thing a second time in Google Play Console, a completely separate tool with its own price model. If you would rather script the console than click through it, that is its own project with its own set of gaps.

One conceptual "change my price" turns into hundreds of individual edits, spread across two consoles, repeated forever. This is where developers go looking for a way to update all their prices at once, and where a free calculator that hands you a spreadsheet of 73 numbers stops being useful, because you still have to type every one of those numbers into two dashboards by hand. The math problem was never the hard part. The localized pricing operation is. For the full picture of setting prices that fit each market instead of just converting them, the app pricing localization guide is the map, and the complete guide to localized pricing for mobile apps is the step by step.

Do it once, across every country and both stores

Changing one price in App Store Connect is genuinely easy, and now you know where every field lives for apps, in-app purchases, and subscriptions. The problem was never the single edit. It is that each of the 175 storefronts holds a raw currency conversion instead of a price built for the local market, that every product carries its own schedule, and that the whole job waits for you a second time in Google Play.

That is the job PricePush does. It calculates purchasing-power-aligned prices for 190+ countries, not raw conversions of your home price, and pushes them to both the App Store and Google Play in one step. So a price change is one decision instead of hundreds of manual entries, and every country gets a number built for what people there can actually pay. You can try it free on one app and see your own per-country prices before you change anything, and the plans plus the founding lifetime offer are on the pricing page.