You can change an auto-renewable subscription's price whenever you want, and the decision that actually matters is what happens to the people already subscribed. Apple lets you either keep existing subscribers on the price they signed up at, called preserving or grandfathering, or move them to the new price, which for an increase triggers a notification and, above certain limits, an explicit consent flow. Choosing correctly is the difference between a clean price change and a wave of cancellations.
This guide covers the two ways a price change can apply, how grandfathering works, Apple's rules for raising the price on existing subscribers, how lowering a price differs, and how to schedule the whole thing through the App Store Connect API so it is consistent across every territory.
On this page
- Two ways a price change can apply
- Grandfathering existing subscribers
- Raising the price for existing subscribers
- Lowering a price
- Scheduling the change through the API
- Timing and territories
- A safe playbook
- FAQ
Two ways a price change can apply
Every subscription price change forks on one question: does it apply only to new subscribers, or to existing ones too?
When you change the price for new subscribers only, anyone who subscribes from now on pays the new price, and everyone already subscribed keeps paying exactly what they signed up for. Nothing changes for current customers, so there is no churn risk and no notification. This is the safe default, and it is almost always what you want for a price increase.
When you apply the change to existing subscribers, current customers move to the new price on their next renewal. For a decrease that is a pleasant surprise. For an increase it is a sensitive event that Apple wraps in notification and consent rules, because a surprise higher charge is exactly what makes people cancel.
Grandfathering existing subscribers
Grandfathering means raising the price for new subscribers while leaving everyone already subscribed on their original price. It is the lowest-risk way to raise prices, and it is why so many apps have long-time users still paying a price the app has not offered publicly in years.
The logic is simple. Your early subscribers are your most loyal customers and your lowest support cost, and the extra dollar or two you would earn by raising their price is rarely worth the cancellations it triggers. New subscribers have no old price to anchor to, so they simply pay the current one. You capture the higher revenue where it costs you nothing and protect the relationship where it matters.
In practice grandfathering is the default behavior when you set a new price for new subscribers and choose to preserve the existing price for current ones. Everyone keeps what they have; only the going rate changes.
Raising the price for existing subscribers
Sometimes you do need to raise the price on current subscribers, and Apple gates this deliberately so users are never charged more without knowing.
Apple treats increases in two tiers. A smaller increase, within Apple's published limits and no more than once a year, can be applied to existing subscribers with a notification: Apple emails and notifies them, and the new price takes effect on their next renewal without them having to do anything. A larger increase, above those limits, requires active consent: the subscriber has to explicitly agree to the new price, and if they do not, their subscription simply does not renew at the higher price rather than charging them by surprise.
The exact thresholds that separate the two tiers, and how often you can use the no-consent path, are set by Apple and worth checking against the current App Store guidelines before you plan an increase, since the policy has changed before. The mechanism, though, is stable: small, infrequent increases can auto-apply with notice, and big ones need the user to say yes. Plan any increase on existing subscribers around which tier it falls into.
Lowering a price
Lowering a price is the easy direction. There is no consent to collect and no churn to fear, so you can pass the lower price to existing subscribers freely, and many apps do it as a retention gesture. New subscribers get the lower price automatically.
The only thing to weigh is whether you lower it for existing subscribers at all. Passing a cut through to current customers is good will, but it is also revenue you were already collecting. A common middle path is to introduce the lower price for new subscribers and leave current ones where they are, the mirror image of grandfathering, then decide case by case whether a retention offer to specific segments is worth it.
Scheduling the change through the API
Doing a price change by hand in App Store Connect is fine for one product in one territory. Across a catalog and many markets it is the same tedium as initial pricing, so the App Store Connect API is the sane way to do it at scale.
A price change is a new price scheduled on the subscription, with a start date and a flag for whether existing subscribers are preserved:
curl -X POST https://api.appstoreconnect.apple.com/v1/subscriptionPrices \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"data": {
"type": "subscriptionPrices",
"attributes": {
"startDate": "2026-09-01",
"preserveCurrentPrice": true
},
"relationships": {
"subscription": {
"data": { "type": "subscriptions", "id": "SUBSCRIPTION_ID" }
},
"subscriptionPricePoint": {
"data": { "type": "subscriptionPricePoints", "id": "NEW_PRICE_POINT_ID" }
}
}
}
}'preserveCurrentPrice: true is the grandfathering switch: new subscribers get NEW_PRICE_POINT_ID, existing ones keep what they have. Set it to false only when you intend to move current subscribers, and only after you have accounted for Apple's consent rules above. For the full setup around this call, including auth and finding price points, see creating App Store subscriptions with the App Store Connect API.
Timing and territories
Two details keep a price change clean.
Schedule it, do not spring it. Set a startDate in the future so the change is announced and predictable rather than immediate. This gives Apple's notifications time to reach users and gives you a window to catch a mistake before it takes effect.
Remember it is per territory. Like the initial price, a change applies to one territory at a time through its own price point. If you raise your base price, you generally want to raise it across markets in a consistent way, which means re-running the change against each territory's ladder, and re-deriving the equalized prices from your new base. For how those per-territory prices are matched, see App Store price point equalization.
A safe playbook
For most price increases, this sequence avoids the churn spike entirely.
- Grandfather by default. Raise the price for new subscribers and preserve it for existing ones. This captures higher revenue with zero cancellation risk.
- Only touch existing subscribers with a reason. If you must raise their price, know which consent tier the increase falls into and plan for the notification or consent flow.
- Schedule, do not surprise. Use a future start date so notifications land and you have a rollback window.
- Change the base, then re-derive markets. Set your new base price and re-equalize across territories so the change is consistent worldwide, not just at home.
- Watch the numbers after. Keep an eye on cancellations and new-subscriber conversion in the weeks after a change, and be ready to adjust. A price is a hypothesis, not a commitment.
FAQ
Can I change an App Store subscription price after launch?
Yes, at any time. You can raise or lower the price, and you choose whether the change applies only to new subscribers or to existing ones as well. Existing subscribers are only moved to a new price if you explicitly apply it to them.
What does it mean to grandfather subscribers?
Grandfathering means raising the price for new subscribers while leaving everyone already subscribed on the price they signed up at. It is the lowest-risk way to raise prices, since loyal early customers never see a surprise increase.
Will raising the price cancel existing subscriptions?
Not if you grandfather them, which leaves current subscribers untouched. If you do raise the price on existing subscribers, a smaller increase can apply with notification, while a larger one requires the subscriber to actively consent or their subscription will not renew at the higher price.
How do I raise a subscription price for current subscribers?
Apply the increase to existing subscribers rather than preserving their price. Apple then handles notification and, for larger increases above its limits, an explicit consent flow. Check Apple's current thresholds first, since they determine whether consent is required.
Can I change subscription prices with the App Store Connect API?
Yes. You schedule a new price on the subscription with a start date and a preserveCurrentPrice flag that decides whether existing subscribers are grandfathered. Doing it through the API is the practical way to apply a change consistently across every territory.
Should I lower prices for existing subscribers?
You can, with no consent needed, and some apps do it as a retention gesture. But it is revenue you were already collecting, so a common approach is to offer the lower price to new subscribers and reserve any decrease for existing customers for targeted retention offers.
Spaceport sets up your subscriptions and their pricing across markets through the App Store Connect and RevenueCat APIs, and the same API flow handles price changes, so when you adjust a base price you can push a grandfathered change across every territory at once instead of clicking through App Store Connect market by market. From an indie iOS dev, for indie iOS devs.