What happens when you raise prices on current subscribers
Changing what new customers pay is one field in App Store Connect or Play Console. Changing what people who already subscribe pay is a different operation. It sets off notices and consent requests that Apple and Google send on your behalf, on their schedule, and if you get it wrong you lose subscribers who never decided to leave.
The default on both stores is to change nothing
Start with the reassuring part. When you raise a subscription price, neither store touches existing subscribers unless you tell it to.
On Apple, scheduling a price change ends with a choice. Option A keeps the current price for everyone who subscribed before the start date, and Apple adds a detail most people miss: a subscriber whose subscription expires can come back at that preserved price within 60 days. Option B applies the new price to existing subscribers, and App Store Connect shows, per country or region, whether those subscribers will simply be notified or asked to consent.
On Google Play, existing subscribers go into what Google calls a legacy price cohort. They keep renewing at their original base plan price until you choose to end that cohort, which you can do region by region, whenever you like, or never.
So the real decision isn't whether to raise the price. It's whether, and when, to move the people already paying. That's the step with consequences.
On Apple, it's either a notice or a consent request
When you move existing subscribers to a higher price, Apple sorts each one into one of two paths. On the gentle path, Apple notifies them by email, push and in-app message, and the subscription renews at the new price. On the strict path, the subscriber has to actively agree before their next renewal. If they don't, the subscription expires at the end of the last period they paid for at the old price.
Consent is required if any one of these applies:
- The subscriber is in a region whose law requires consent for any price change.
- The increase is more than 50% of the current price and the difference is more than roughly US$5 per period (US$50 per year for annual plans). Apple publishes per-storefront equivalents for other currencies.
- The subscriber already had a price increase on that subscription in the past 12 months.
Both halves of the second rule have to be true. Moving a monthly plan from $4.99 to $7.99 is a 60% increase, but only $3 more, so outside consent-required regions those subscribers get a notice. Moving an annual plan from $29.99 to $49.99 is 67% more, but $20 is under the annual threshold, so it's also a notice. Moving a monthly plan from $7.99 to $14.99 is 88% more and $7 more, so every one of those subscribers has to say yes.
The timing scales with the plan length. For monthly subscriptions the first message goes out 27 days before renewal, for weekly ones 7 days, and for plans of two months or longer, annual included, 60 days. If you schedule an increase inside that window, the subscriber renews once more at the old price and hears about it before the following renewal. Anyone currently on a free trial or an introductory offer also renews at least once at the price they signed up for, so their notice still arrives at least 30 days ahead.
Why consent requests cost more than they look
If consent is required, Apple keeps asking roughly once a week by email, push and in-app message until the subscription expires. The problem is the subscriber who would happily pay the new price but never opens the email, has push notifications for your app turned off, and doesn't launch the app during that month. They didn't choose to leave. Their subscription simply expired, and the end result is the same as a cancellation.
On the notice path, the same subscriber renews at the new price without lifting a finger. That asymmetry is the whole game. An increase that stays under the thresholds asks people to opt out. An increase that crosses them asks people to opt in, and the subscribers who use your app least are the ones least likely to see the request. If the new price is only slightly over a threshold, the extra revenue per subscriber may not be worth turning the quietest part of your base into a consent campaign.
Google is stricter by default
On Google Play, ending a legacy price cohort is an opt-in change by default. Every affected subscriber has to accept the higher price before they're charged it, or Google cancels the subscription on the renewal date where the new price would have applied. There is no notice-only path unless you qualify for one.
The opt-in timeline is fixed. The new price takes effect at the first renewal at least 37 days after you start the migration. For the first seven days Google sends nothing at all, and from 30 days before each subscriber's first charge at the new price it notifies them by email and push.
Google also offers opt-out increases, where subscribers are notified 30 or 60 days ahead depending on the country and are charged the new price unless they cancel or switch plans. These are only available in certain countries, with limits on how much and how often you can raise the price, and they come with developer requirements of their own, including an in-app notice. Play Console tells you whether a given cohort is eligible. Treat it as a bonus when it's offered, not something to plan around.
Tell people before the store does
The first message about a price rise shouldn't be a system email. The stores' notices are accurate and neutral, and they explain nothing about why. You have about a month to do better.
- Say it in your own voice first. A short in-app message or email a week before the store's notice goes out: what's changing, when, and what they've had for the money. If the price has been the same for two years, say so.
- Pick the moment for Apple's consent sheet. StoreKit lets your app hold the price consent sheet and show it later instead of over the first screen on launch. Show it after something has gone well, not in the middle of a task.
-
Listen for the result. Apple's server notifications include a
PRICE_INCREASEtype with a pending or accepted state, so you can see who has agreed and nudge the rest yourself instead of waiting for expirations to show up in your revenue. - Go region by region. Both stores let you move existing subscribers one country or region at a time. Start with one market you understand, wait a full billing cycle, and look at renewals before rolling it out wider.
Some of this can't be undone
Apple is blunt about it: once a price increase goes into effect, it can't be reversed. A decrease is just as final, and it applies to every existing subscriber automatically, with no option to keep anyone at the higher price. You can schedule only one future change per storefront at a time, and a new increase can overwrite one that a subscriber was notified about but hasn't renewed at yet, which pushes their renewal at the new price back by another billing period. Rescheduling in a nervous loop resets the clock on your own subscribers.
The calmer sequence is the one both stores are built for. Raise the price for new customers first and watch conversion for a month. If it holds, decide whether moving existing subscribers is worth it at all. Legacy pricing is a perfectly reasonable thing to leave in place, and plenty of loyal early users have earned it. If you do move them, stay under the consent thresholds where you can, tell them yourself before the store does, and do it once.
And before new visitors see the higher number, make sure the listing looks worth it. The screenshots are the first evidence they get of what they'd be paying for.