Raising the price of an auto-renewing subscription is one of the operations where the App Store does a lot of the work for you, and it's worth understanding what that work is before you schedule a change. At Olnesta Ltd we've gone through this on our own apps, and the mental model that helped us most was to stop thinking of a price change as a thing we announce to subscribers and start thinking of it as a thing we schedule, after which Apple's subscription system takes over the customer-facing part.
The short version: when you raise the price of an existing subscription in App Store Connect, existing subscribers are handled by Apple, not by you. Depending on how large the increase is and how often you've raised the price recently, it will either go out on a notice-only basis or require the subscriber to actively agree before the new price applies to them. New subscribers, of course, just see the new price and are unaffected by any of this.
Notice-only versus consent-required
Apple's system distinguishes between smaller increases within a rolling period, which apply automatically after the subscriber is notified, and larger increases, which require the subscriber to opt in. The precise thresholds and the length of the rolling window are set by Apple and can be adjusted over time, so rather than repeat a specific number here we'd point you at the current App Store Connect help and Apple's developer documentation on managing subscription prices before you plan a change. The categories themselves have been stable in our experience; it's the exact figures we'd double-check each time.
What matters at the planning stage is that a notice-only increase is essentially frictionless from the subscriber's side, they get told, and unless they cancel, the next renewal is at the new price. A consent-required increase is a different animal. Apple prompts the subscriber, in the ways they've come to expect (email, a system notification, and an in-app sheet the next time StoreKit surfaces it), and asks them to agree. Until they do, they keep renewing at the old price.
What happens if a subscriber ignores the prompt
This is the part we've seen misunderstood most often, so it's worth stating plainly. If an increase requires consent and the subscriber doesn't give it, they are not silently moved to the new price and they are not immediately cancelled. They continue on their existing subscription at their existing price. If they later agree, the new price takes effect from then. If they let the subscription lapse (cancel, or fail to renew for some other reason) and later resubscribe, they resubscribe at the current price like anyone else.
So a consent-required increase produces, for a while, a mixed base: some subscribers on the new price, some still on the old one, and, over time, the old-price cohort shrinks as people either consent or churn out. That's the behavior to plan around. If your forecast assumes everyone flips to the new price on day one, you'll be disappointed; if you assume a gradual migration, the numbers tend to line up more sensibly.
What the developer actually does
Almost nothing, and that's the point. You schedule the new price in App Store Connect, choose the effective date, and confirm. Apple handles notifying existing subscribers, presenting any consent prompt, tracking who has and hasn't agreed, and applying the new price at the correct renewal for each subscriber. You do not build the notice, you do not send the email, and in general you do not need to add a custom in-app screen to explain the increase, though nothing stops you from communicating with your own users through your own channels if you want to give them extra context.
A few things are still worth doing on your side. Make sure your support inbox and any in-app help are ready for questions from confused subscribers, because some of them will contact you rather than Apple. If your app displays prices anywhere other than through StoreKit's own product info, confirm those surfaces read from the current product data so you don't end up showing a stale figure. And if you rely on server-to-server notifications for subscription state, treat a price change as a good excuse to reread Apple's current notification payload docs and confirm your handler still does the right thing, particularly around renewals at the previous price for subscribers who haven't consented yet.
The underlying idea is that Apple owns the subscriber relationship for the parts that need to be consistent across every app on the store, and price-change consent is one of those parts. Once we internalised that, planning increases got a lot calmer: pick the price, pick the date, write a short note for support, and let the system do its job.