How to reduce cancellations in an iOS app without hiding the cancel button

On iOS, the cancel button is not yours. Customers cancel an App Store subscription in their Apple Account settings, and Apple executes it. You cannot block that, delay it or put a maze in front of it. What you can do is help the customer who is about to leave find a better option, in your app before they reach Apple’s page, and, for some developers, on Apple’s own confirmation screen.

This guide covers the tools Apple documents for that, and a cancel flow that respects them. It is based on Apple’s documentation for showManageSubscriptions(in:), the Retention Messaging API, promotional offers, the notificationType reference and the App Review Guidelines (all accessed November 2026).

What Apple controls

• Where cancellation happens. Apple’s notification reference describes cancellation as the customer canceling “from the App Store Subscriptions settings page.” Your server then receives DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED.
• What canceling means. The subscription stops renewing. The customer keeps access until the end of the paid period, and you later receive EXPIRED with subtype VOLUNTARY.
• The sheet in your app. StoreKit’s showManageSubscriptions(in:) (or manageSubscriptionsSheet in SwiftUI) opens the same management screen customers see in their account settings, with the options to view, upgrade, downgrade or cancel. Apple recommends adding a manage subscriptions option to your app.

And the rules: App Review Guideline 5.6 (Developer Code of Conduct) says apps should never “trick” customers or “engage in any other manipulative practices within or outside of the app,” and repeated manipulative behavior can get you removed from the Developer Program. Guideline 3.1.2(a) adds that subscription apps that “attempt to trick users” or use bait-and-switch practices will be removed. A cancel flow that hides the exit is exactly what these rules target, beyond any consumer law in your markets.

Tool 1: your own “Manage subscription” screen

Before opening Apple’s sheet, your app can show its own screen. This is where most of the retention work happens, and you control it fully, as long as it does not get in the way.

A pattern that respects the rules:

1. One screen, one question. “What’s the main reason you want to cancel?” with four to six answers and a free text field.
2. One relevant answer to that reason. Too expensive: a cheaper plan or a discount. Not using it: a reminder of what they would lose, or a downgrade. Missing feature: a way to tell you, and an honest answer about plans.
3. A “Continue to cancel” button visible at every step, opening showManageSubscriptions(in:). Same size and weight as the offer button. No extra confirmation, no countdown.
4. Skippable question. The customer can go straight to Apple’s sheet without answering.

Apple does not send you a cancellation reason; the notification fields it documents for AUTO_RENEW_DISABLED do not include one. The answer to your own question is the only reason you will get, so store it with the customer.

Tool 2: offers Apple can actually execute

On iOS, any discount or plan change must go through StoreKit. Two options fit a cancel flow.

Promotional offers

Apple’s guide says promotional offers can be effective in “retaining current subscribers.” You create them in App Store Connect (up to 10 active per subscription), your server signs each offer, and the customer redeems it in your app. Apple even suggests using the DID_CHANGE_RENEWAL_STATUS notification to decide eligibility, so a customer who just turned off renewal can see an offer the next time they open the app.

Plan changes within the group

A downgrade is often a better answer than a discount. Within a subscription group, Apple’s notification reference says downgrades take effect at the next renewal date and do not affect the current plan, while upgrades take effect immediately with a prorated refund of the unused period. You receive DID_CHANGE_RENEWAL_PREF with subtype DOWNGRADE or UPGRADE. A cheaper tier, or a switch from monthly to a longer period, keeps the customer paying something.

If you want to offer a pause, check what Apple currently supports for your product type. The documentation used for this guide describes downgrades, promotional offers and retention messages, not a pause option.

Tool 3: retention messages on Apple’s own screen

Apple’s Retention Messaging API lets you choose a message shown after the customer taps Cancel Subscription on a subscription details page. Apple then shows a Confirm Cancellation page where the customer can still cancel, keep the subscription, or, depending on the message, redeem an offer or switch plan.

What Apple documents:

• It is a pre-release API. You have to request access.
• Four message types: text (with optional bullet points), text with an image, a switch-plan message suggesting another subscription, and a promotional-offer message.
• Default messages per product and locale, text-based only. Without a default message for a locale, nothing is shown there.
• Real-time messages. Apple’s server calls your endpoint when an active subscriber views a subscription details page with a Cancel button, and you pick a preconfigured message, including offer and switch-plan messages. Defaults act as the fallback if your server does not answer. Before going to production, your endpoint must pass Apple’s performance test.
• Devices: iOS and iPadOS 15.1 or later, visionOS 1 or later, macOS 14 or later.
• Apple asks you not to upload misleading or inaccurate content.

This is the closest thing on iOS to a retention step inside the cancel flow itself, and Apple keeps the Cancel Subscription button on that page.

After the customer turns off renewal

A turned-off renewal is not a lost customer yet. Between AUTO_RENEW_DISABLED and EXPIRED, the subscription is still active.

• Don’t cut access early. They paid for the period.
• Show a quiet banner in the app with the end date and a way to turn renewal back on (Apple’s sheet again). If they do, you receive DID_CHANGE_RENEWAL_STATUS with AUTO_RENEW_ENABLED.
• Use the time for one relevant message, based on the reason they gave. One, not a sequence.
• Plan for after expiry. Once the subscription has expired, Apple’s win-back offers take over.

Measuring what works

Track, per reason and per offer:

1. How many customers opened your manage screen.
2. How many accepted an offer or changed plan.
3. How many continued to Apple’s sheet.
4. How many turned off renewal (from AUTO_RENEW_DISABLED), and how many turned it back on.
5. Retention two or three renewals later for those who accepted an offer.

The last one matters most. A discount that delays a cancellation by one month is not the same as a customer who stays.

What to avoid

• Hiding the link to Apple’s subscription settings, or burying it under several screens.
• Making the offer button large and the cancel link small and grey.
• Telling customers they must contact support to cancel.
• Showing offers the customer cannot actually redeem, or promising terms StoreKit will not apply.
• Asking the same customer the same question every time they open the screen.

For the general principles behind fair cancel flows, see our cancel flow best practices and the overview of click-to-cancel rules.

Doing this with NoChurn

NoChurn’s cancel flow is available as a headless API, so your iOS app can show its own native screen: reasons, one offer (discount, plan change or pause where your billing supports it), and a cancel button that is always visible and opens Apple’s subscription settings. The cancel itself stays with Apple. NoChurn records the reason, reads the AUTO_RENEW_DISABLED and EXPIRED notifications to see what really happened, and uses both for the churn score and for win-back. Setup is on NoChurn + App Store.