Apple Retention Messages and Offers: You Can't Change the Price Later

On 4 November 2026 Apple opened retention messages to every developer in App Store Connect. When someone goes to cancel an auto-renewable subscription, you can now show them a message, an image or a discount, and you don't need a server for it.

My X timeline went a bit crazy, for good reason. The next morning Viktor Seraleev posted about a part I hadn't seen anyone mention. He had written his message and localized it into 31 languages with no problem. Then he got stuck setting the offer's price country by country: "I've already spent two hours on this."

Click to enlarge

Viktor Seraleev's post on X, 5 November 2026.

So I tested the new API on a test subscription of one of my apps, and I found something worse: after you create a retention offer, you can't change its prices. Not in App Store Connect and not through the API.

Below is what Apple shipped, how to set it up, what the early numbers say, and how to price these offers without losing your afternoon.

What Apple shipped on 4 November

A retention message appears on Apple's Confirm Cancellation screen, after the subscriber taps Cancel Subscription. The buttons to cancel and to keep the subscription stay on that screen. The same page says subscribers need iOS 15.1, iPadOS 15.1, visionOS 1 or macOS 14 or later to see it.

Subscribers see one of three versions: text only, text with an image, or text with an offer. An eligible subscriber sees the offer instead of your image. An app can have 10 messages, and a subscription can have one message at a time.

Click to enlarge

Apple's announcement image, as shared by Axel Le Pennec on X.

A lot of posts I read this week call this "the API", and that's where most of the confusion comes from. There are two different things, and only one of them opened to everyone:

The WWDC session spells out those differences. So if you were looking for the switch plan option in App Store Connect, you're not doing anything wrong. It's only in the API today. If you run both, your real-time answer wins, and App Store Connect is the fallback when your server doesn't answer properly. Apple recommends setting up App Store Connect in that case too.

This also isn't a win-back offer. Retention Messaging reaches people during the cancel flow, while win-back offers are for people who have already left.

How to set up a retention message in App Store Connect

Open your app, go to Monetization, then Subscriptions, and scroll to the Retention Messaging section. From there:

1. Name the message. Only you see that name.
2. Write the header and the body, then add every language where you sell. Through the API the limits are 66 characters for the header and 144 for the body.
3. Optionally add an image. Apple supports 3840 × 2160 or 5244 × 2950 pixels.
4. Choose the subscriptions, then add offers if you want them.
5. Check the preview and click Add for Review.

Click to enlarge

A text and image message for his app, shared by Mustafa Yusuf on X.

Every message goes through App Review, and the content rules are the part to read twice. Your text can't mention offers, discounts or specific prices, because subscribers who aren't eligible for the offer read the same text. Apple's own examples of what gets rejected are "$9.99", "50% off" and "one month free". You can say what someone loses if it's factual. Apple also tells you to avoid scaring people or using a statistic you can't support.

Offers have their own rules:

• The subscriber needs at least 1 paid month. You can set 1 to 24, 36, 48 or 60. Viktor pointed out what this means in practice: someone cancelling a free trial won't see your offer.
• You can make people wait 2 to 24 months before redeeming the same offer again. Apple's help page says that wait applies per offer, so someone can still get a different one.
• You can have 10 active offers per billing plan type, and one message can hold all 10. The App Store picks the best one for each eligible subscriber.
• Offers can be pay as you go, pay up front or free.

If you edit an approved message, the old version stays live until App Review approves the new one, and you can't roll back to an older version. Sandbox testers always see your latest draft, so test there first.

Do retention messages reduce cancellations?

Maybe. The numbers are less exciting than the posts on my timeline, and I think they're more useful that way.

Apple said at WWDC that subscriptions using Retention Messaging saw an average save rate increase of 1.4 points, and promotional offer messages reached +5.5 points. Apple also said results vary across developers.

RevenueCat looked at 309 apps with early access. The median save rate was about 17%, subscribers accepted only about 1.1% of promotional offers, and most saves came from people who simply didn't cancel in the next 24 hours. In a smaller comparison of 64 apps, they found no measurable effect on cancellation rates either way, and they say so openly. I liked that a lot, because they sell a retention messaging feature.

Superwall looked at 30 apps and about 73,000 sends. With 11 apps per message type, plain text had a median save rate of 20.7%, against 17.7% for a promotional offer. The best text named what the person would lose, like their scans, their library or their data. Superwall adds its own caveat: the biggest gaps came from apps with only 100 to 150 text sends.

Don't put Apple's numbers next to the other two. Apple says +1.4 points is an 82% increase, which implies a starting point of about 1.7%, while RevenueCat and Superwall count anyone who doesn't cancel within 24 hours. I infer they aren't measuring the same thing, and Apple doesn't publish its baseline.

RevenueCat and Superwall measured API users. Apple doesn't say which version its numbers cover, but only the API existed then, so I infer the same. I haven't seen public numbers for the App Store Connect version yet, and I can't add my own: I've only tested messages on test subscriptions, none live and approved yet.

So in my opinion the order is simple. Start with a message that names what the person would lose. It's free, and it can't teach anyone that cancelling gets them a discount, which is a fear I saw in two replies this week. Then test an offer and watch renewals along with the save rate. Apple says you can track an offer by its identifier in Sales and Trends and in StoreKit transactions, and a redeemed retention offer has an offerType of 5.

Retention offer prices are locked after you create them

This is what I measured on 5 November against Apple's real API, on test subscriptions:

• POST /v1/retentionOffers creates an offer with all its prices at once. With 175 countries it took about 11 seconds, and the prices read back with no differences.
• A PATCH that includes prices is refused with a 409. It made no difference whether the offer was on a message, how big the change was, or how many countries I changed. PATCH only changes the eligibility rules, and Apple's docs say the same.
• An identifier can never come back. After a real delete, Apple answered: "Offer IDs cannot be reused, even after deletion." Identifiers allow only letters, numbers, underscores and periods.
• An 11th offer on the same billing plan type is refused.

I expected these to behave like promotional offers, since they use the same pricing screen and the same price points. They don't: a promotional offer's prices can be updated, and a retention offer's can't. Apple's website shows the prices read-only too.

So a price change means a new offer with a new identifier and every country set again. Then you move your message to it, and you delete the old one if you're near the limit of 10. A typo in one country means the same thing, and so does trying a second discount.

Apple tracks sales by identifier, so I infer that offer_v2 will show as a separate row from offer in Sales and Trends. I haven't seen a real report yet.

Why the default offer price can be wrong in your country

When you create an offer in App Store Connect, you choose a price for your default country and Apple calculates the other countries from recent exchange rates. You can then change each country by hand.

If your subscription has one global price, that default keeps the discount roughly right. If you've localized your subscription, it can break it.

For example, say you sell a $19.99 subscription and you localized it for India at about ₹680. You want 50% off, so you type $9.99. An exchange rate conversion makes that about ₹950, which is about 40% more than the subscription itself. Your half-price offer now costs more than not taking it. This is my inference from Apple's description and our calculator's numbers, so check your own offer's price list before you save it. Viktor's screenshot above seems to show the same thing: I read the Morocco row as a $13.99 subscription with a $22.99 offer and a warning icon next to it. The column headers are cropped, so that's my reading of it.

Apple's API accepted an offer priced above its plan in my test. I don't know what happens on the cancel screen in that case, and Apple's docs for retention offers don't say. Either way it isn't a real discount.

This is the same exchange rate problem that base prices have, except here you can't fix it later. By hand you're choosing about 175 prices, each one below the subscription's price in that country, each one on Apple's list of price points. That's Viktor's two hours, and you do it again for every new price.

Many people replied to him "use the API", and they're right. The POST takes every price in one call, as I measured above. If you like scripts or AI agents, it's the way to go. You'll still need a price for every country, the right price point for each, a rule for countries with no cheaper point, and a plan for identifiers and the limit of 10.

What PricePush does with retention offers

I built PricePush to stop setting prices by hand, so as soon as I saw this I added it. Version 2.1.1 does the following, and I tested each one on test subscriptions and read the result back from Apple:

• It lists retention offers under their subscription.
• It localizes one in all countries in one push. Because Apple locks prices, the push creates a new offer with the next identifier (_v2, _v3) and the new prices.
• If the old offer was on your message, it moves the message to the new offer and leaves the text unchanged. Deleting the old offer is optional. You can also delete offers inside PricePush when you hit the limit of 10.
• It creates brand new offers from a short form, for yearly (upfront) and monthly commitment plans, pay as you go and pay up front.
• It holds each price below the subscription in each country wherever a lower App Store price exists. Where none exists, it tells you before you push.
• Localize all can include retention offers on your message if you tick the box.
• History rollback creates a new offer with the old prices. That one is on the Pro plan.

Click to enlarge

Click to enlarge

Click to enlarge

Click to enlarge

It doesn't write your message for you, and it doesn't touch the real-time API, so if you need a different message per subscriber, that part stays with your server or another tool. It's an App Store feature only, because this is an Apple feature. I haven't run it on a live, approved message yet, so if you're one of the first to try that, I'd really like to hear how it goes.

Retention offers sit next to your introductory and promotional offers in the same step of the Localize page, and you can see the plans here.

What I would do this week

Write one message about what people lose, translate it and send it to App Review. Add one offer at a time, and check its price in your biggest countries before you save it, since you can't fix it afterwards. Keep an eye on the limit of 10, and pick identifiers with a version in mind, since each one works only once.

If you have a subscription on the App Store, you can try it for free on one app with the Starter plan: 7 days, 2 pushes, no credit card. That's enough to see your retention offer's price in every country before anything changes.

Antonio

Frequently asked questions