Stripe's iOS BillingSDK: Why Mobile Subscription Apps Might Finally Escape Apple's Cancellation Black Box

If your product has a mobile app and sells subscriptions through Apple's In-App Purchase, you already know the deal: Apple owns the checkout, Apple owns the customer portal, and Apple owns the cancel button. You get a payout and a notification after the fact. You don't get a cancel reason, a chance to counter-offer, or any of the machinery a Stripe-based cancellation flow gives you on web. Stripe just shipped something aimed directly at that gap, and Apple's own commission structure for the alternative is being rewritten in a courtroom as we speak.

What Apple's In-App Purchase has always hidden from you

Under standard IAP, your cancel button doesn't exist. The subscriber taps Settings → their name → Subscriptions, finds your app in a list next to every other subscription they're paying for, and taps Cancel. Your product never renders a screen. There's no reason dropdown, no pause offer, no "before you go" moment — because the entire interaction happens inside Apple's UI, on Apple's terms, with your app as a passive bystander.

To be fair, you're not completely blind. App Store Server Notifications V2 send a DID_CHANGE_RENEWAL_STATUS event when auto-renew gets turned off, and when a subscription actually lapses, the payload includes an expirationIntent code: customer canceled, billing error, price disagreement, product unavailable, or unknown. That's a real signal — five fixed buckets, delivered server-to-server. What it isn't is an interception point. By the time you receive it, the subscription is already gone. There's no equivalent of the modal your web cancellation flow shows before Stripe ever processes anything.

What Stripe's BillingSDK actually does

The BillingSDK for iOS is a Swift Package, currently gated behind Stripe's private preview program, that puts subscription purchase and management directly inside your app instead of routing through Apple's commerce layer. Three pieces make it work:

• Buy buttons — prebuilt UI that fetches your Stripe prices and renders a native purchase flow, so a user can subscribe without leaving the app.
• Entitlements — a hasEntitlement(lookupKey:) check plus an onEntitlementsChanged callback, so you can gate premium features off the same subscription state Stripe already tracks for web.
• Customer portal — Stripe's hosted subscription management surface, presented natively via getCustomerPortal(), where a subscriber updates payment details or cancels.

It's not a payments SDK bolted onto IAP — it's a replacement for IAP's commerce layer, running on the same Customer Session infrastructure Stripe already uses for web billing. Your backend authenticates the user, creates a Customer Session with the components you want enabled (buy_button, active_entitlements, customer_portal), and the SDK does the rest, including local caching so entitlement checks work offline.

Apple IAP vs a Stripe-native flow, side by side

The commission row is the one worth sitting with, because it's the reason this only became viable recently. Even in a world where Stripe hands you back the cancel button, moving off IAP only makes sense if Apple's cut on the external path is meaningfully lower than IAP's 30% — and for most of the last few years, it wasn't.

The commission fight that made this math work

Apple's first attempt at pricing external-link purchases, after the 2021 Epic v. Apple injunction forced it to allow them, was a 27% commission. A federal court found in April 2025 that Apple had done this on purpose: 27% to Apple plus a payment processor's own fee comes out higher than Apple's own 30% IAP rate, which meant no rational developer would actually use the external link Apple was legally required to permit. The court held Apple in contempt over it.

In an August 13, 2026 filing, Apple proposed a replacement structure: a 15% standard commission on external-link revenue, 10% for developers in a partner-program tier, and 5% for its smallest developers — closely mirroring the tiers it already uses inside IAP itself. Separately, Apple's EU settlement locked in a flat 5% Core Technology Commission that applies uniformly across the App Store, web distribution, and alternative marketplaces. Neither of these is final law yet; both are still working through court and regulatory approval as of this writing.

That last bar is the whole story of why nobody used Apple's original external-link option: at 27% plus Stripe's own fee, you'd have paid more than IAP's standard rate for the privilege of building your own checkout. At a proposed 15%, the external path finally undercuts standard IAP by roughly a third — enough to justify the engineering lift of adopting a preview SDK, but still not obviously better than Apple's own Small Business Program rate if you already qualify for it.

Should you actually move mobile subscriptions off Apple IAP?

Not automatically, and not everywhere. A few things worth checking before you do:

• It's US-storefront only, for now. The external purchase link entitlement Apple grants is scoped to US App Store accounts. If most of your subscribers are outside the US, this doesn't apply to your traffic yet.
• The commission numbers aren't locked in. Apple's 15/10/5% proposal is a court filing, not a shipped policy — treat any cost model you build today as provisional until it's finalized.
• BillingSDK is a private preview. You need your Stripe account opted into preview APIs, iOS 15+, and a backend that can mint Customer Sessions. This isn't a drop-in swap for an existing IAP integration — budget real engineering time.
• Apple's review guidelines still apply to everything else. The external link is an exception carved out of a broader review process that hasn't otherwise changed. Get the entitlement wrong and you risk a rejected build, not just a fee dispute.

For a low-ACV consumer app with thin margins, the cost delta alone might not justify the switch, especially against Apple's 15% Small Business Program rate. Where this gets genuinely interesting is for subscription products where the cancellation moment itself has value — the same population our cancel-reason data shows responds to a pause or a targeted discount instead of just leaving. If a save rate of even 20-30% on mobile cancellations is plausible for your product, that recovered revenue can outweigh a few points of commission difference by itself.

What this means for your churn data

The deeper shift here isn't the commission math — it's that mobile subscription apps are getting the same tool web SaaS has had for years: a moment to intercept, ask, and offer before a cancellation is final. That's the exact mechanism this whole site is about, just arriving on a platform that's kept it locked away since the App Store launched. It also closes a blind spot from the other direction of the channel problem we've covered before — where bank-initiated cancellations route customers away from a cancel flow you already built, App Store IAP never let you build one in the first place.

If you're currently running a Stripe-based cancellation flow on web and shipping a separate, cancel-flow-less experience on iOS, that's a real gap in your churn reporting — cancellations on one platform get a reason, offer, and save attempt, and cancellations on the other vanish into an expirationIntent code. Run your current mobile cancellation volume through our churn calculator against what a comparable web save rate would recover, and you'll get a rough sense of what that gap is actually costing you before you decide whether the preview SDK, or just Apple's existing Small Business Program pricing, is worth pursuing first. Either way, the fact that this is now a live decision — rather than a platform restriction with no alternative — is the actual news here.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.