How to Raise Your App's Subscription Price Without Losing Subscribers

Raising a subscription price is not one decision, it is two, because Apple lets you nudge existing subscribers up almost silently while Google makes them actively agree or lose them. Same price bump, two completely different outcomes for your base. If you run on both stores and treat "raise the price" as a single action, one of the two will surprise you.

The fear behind the question is always the same. You want to charge more, but you do not want to wake up to a wave of cancellations from the subscribers you already have. The good news is that both stores give you a way to protect them. The catch is that the mechanics, the timing, and the churn risk are different on each one, and most guides only cover the store the author ships on.

I have shipped and raised prices on subscription apps since 2012. This is the practical version: how to raise your app's subscription price on the App Store and on Google Play, how to grandfather your existing subscribers on each, where the two diverge, and the one thing a price increase is secretly a good moment to fix. If you sell an auto-renewable subscription on both stores, the divergence section is the one to read twice.

Grandfathering: keep existing subscribers on the old price

The safest way to raise a price is to not raise it for the people already paying. That is grandfathering: new subscribers pay the higher price, and everyone who was already subscribed stays on the price they signed up for. It sidesteps the whole cancellation risk, because nobody who is currently paying you sees a change.

Both stores support it, and for most first price increases it is the move I would default to. You capture more revenue from every new subscriber immediately, you carry zero churn risk on your existing base, and you can always decide to raise the grandfathered cohort later once you have data on how the new price converts. The tradeoff is that your existing subscribers keep paying less, sometimes for years, so grandfathering is a revenue-now-versus-revenue-later choice, not a free lunch.

Where it gets interesting is what happens when you do want to raise existing subscribers, not just new ones. That is where Apple and Google stop looking alike.

Raising the price on the App Store

On the App Store, you raise a subscription price in App Store Connect by planning a price change for the subscription, per country or region. When you do, Apple asks what to do about the people already paying the current price, and you pick one of two paths.

The first is to keep the current price for existing subscribers. Anyone who subscribed before the change's start date is unaffected and keeps their old price, and only new subscribers pay more. A subscriber whose subscription lapses can even resubscribe at the preserved price within 60 days of expiration. This is grandfathering, done with a single choice. Note that scheduled changes cannot be reversed, so plan the start date deliberately.

The second path is to apply the increase to existing subscribers too, and this is where Apple is unusually gentle. If the increase is small enough, Apple simply notifies subscribers of the new price by email and push, 27 or 7 days before their next renewal, and the subscription renews at the new price with no action required from them. Consent is only required if the increase is steep or repeated: more than 50 percent of the current price and more than about 5 dollars per period (or 50 dollars per year for annual plans), or if the subscriber already had an increase for that subscription in the past 12 months, or if they are in a region whose law requires consent for any change. When consent is required and the subscriber does not agree before their next renewal, the subscription does not renew. Those thresholds are not permanent, Apple updates them over time, so check Apple's current price-increase rules before scheduling a large jump. The step-by-step for making the change itself is in how to change a price in App Store Connect.

Raising the price on Google Play

Google Play starts from the opposite default. When you raise the price for existing subscribers, it is opt-in: each subscriber has to actively accept the higher price before their next charge, and if they do not, Google Play cancels the subscription. There is no quiet renew-at-the-new-price path the way there is on Apple. Grandfathering on Google is simply choosing not to apply the increase to existing subscribers, so they stay on the old price.

The timing has a detail worth knowing. An opt-in increase runs on a 37-day advance-notice window, and Google starts emailing and push-notifying your existing subscribers 30 days before the new charge. For the first 7 days after you trigger the change, though, Google notifies no one, which gives you a head start to message your own subscribers in your own voice first, or to cancel the increase entirely by reverting the price before Google's notifications begin. Google documents this in its subscription price change guide.

There is also an opt-out increase, where the subscriber is charged the new price on their next renewal after a notice period and does not have to do anything, which behaves more like Apple's quiet path. But it is only available in certain countries and regions, and only to developers in good standing, with a notice period of at least 30 or 60 days depending on the region. So you cannot rely on it as your default the way you can on Apple.

The divergence, and why it bites cross-store apps

Put the two side by side and the gap is stark. On Apple, a modest increase to your existing subscribers is a notice: it renews at the new price and most people never lift a finger, so your churn risk is low. On Google, that same increase is a decision you are forcing on every existing subscriber, accept or lose them, and every subscriber who ignores the email is a cancellation.

That means "raise my subscription price" is not one operation across your app, it is two flows with two different churn profiles. A plan that is safe on Apple, quietly bumping existing subscribers 20 percent, can quietly bleed subscribers on Google, where that same 20 percent has to be actively re-accepted. If you run both stores and reason about only one, you will either leave Apple revenue on the table by grandfathering too conservatively, or take a churn hit on Google by raising existing subscribers without planning for the accept-or-cancel step.

The workable pattern for most apps: grandfather existing subscribers on both stores for the first increase, raise only new subscribers, and if you later decide to raise the existing base, treat Apple and Google as separate campaigns with separate messaging, and lean on your own win-back and promotional offers to catch the subscribers who waver.

A price increase is also a localization moment

Here is the part almost nobody connects. When you sit down to raise your price, you open the pricing for your app anyway, and that is the best moment to notice that your prices in every country other than your home market were probably never localized in the first place.

Most apps set one price, let the stores convert it to the other 174-plus storefronts at the exchange rate, and never touch it again. A converted price is not a localized one, so those markets are often sitting two to three times too high relative to local purchasing power, quietly drifting further off as rates move. Bumping your US number from 9.99 to 12.99 while India and Brazil keep paying a raw conversion of the old dollar figure just compounds a mistake in 190 markets at once. If you are going to touch the price, raise it where the market supports it and localize it where it does not, in the same pass. The full method is in the app pricing localization guide, and the subscription-specific version is localized pricing 101 for subscription apps.

A price-increase checklist

To pull it together, here is the order I work in:

1. Decide new subscribers versus existing. For a first increase, grandfather existing subscribers on both stores and raise only new ones.
2. If you do raise the existing base, plan Apple and Google separately: on Apple, know whether your increase stays under the consent thresholds; on Google, plan for accept-or-cancel and use the 7-day head start to message subscribers yourself.
3. Do not just bump your home price. Localize the base price per country in the same pass, so you are not raising one market while 190 others sit mispriced.
4. Keep a record. Treat the change as a versioned update with history and a rollback path so you can undo a bad move.
5. Push it to both stores, and revisit as exchange rates move.

That last mile, applying a coherent price change per country across two stores and keeping a history of it, is the tedious part, and it is the job PricePush does. It calculates purchasing-power-aligned prices for 190+ countries and pushes them to both the App Store and Google Play in one step, so a price increase becomes one decision instead of hundreds of manual edits, and your other markets get localized instead of left on a stale conversion. 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. For the wider view of pricing your app in the first place, start with how to price an app.