For ten years the rule was simple: if you wanted to charge a user money inside your iOS app, you used Apple's in-app purchase. No links to your website. No "pay on the web for cheaper." No mentioning, even obliquely, that an alternative existed. Break the rule, get rejected. Push it, get pulled.
That era is over — at least in the US. After the May 2025 court order in the Epic case, Apple's failed appeal, and most recently Apple's denied bid for a Supreme Court stay, the App Store Review Guidelines have been quietly updated. Apps in the US storefront can now include buttons, external links, and other calls to action that direct customers to purchasing mechanisms outside in-app purchase. Spotify shipped an updated app within hours. Smaller developers have been more cautious — the right kind of cautious, because the new rules are real but they are not free.
This guide walks through what changed, what Apple still charges, how to implement external links cleanly, what App Review looks for, and the question a lot of indies are quietly asking: is this worth doing at all?
What changed in the rules#
The relevant edit happened in section 3.1.1 of the App Store Review Guidelines, plus updates to several related sections covering anti-steering. The previous language read, roughly: apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase. After the court ruling, the US-storefront version of those sections no longer carries that prohibition. Apps in the US can now:
- Place a button inside the app that opens an external web URL
- Link to a third-party payment processor (Stripe, Paddle, your own checkout)
- Display pricing for the external option alongside the IAP option
- Tell users, in-app, that buying on the web is cheaper
The change applies only to apps on the US storefront. The same external-link UI submitted in an app that distributes globally is still a 3.1.1 violation in Japan, Canada, Australia, the UK, and most other regions. (The EU has its own, more permissive DMA rules, but those are a different code path.) App Review evaluates per-region, and most indie apps publish to all regions by default. The first thing to get right is the regional gating, not the UI itself.
The commission catch#
Apple did not exit the commission business when the court ordered it to allow external links. It split the commission off from the payment rail. The result is a fee structure most developers find surprising the first time they read it:
- In-app purchase: 15% (Small Business Program or second year of a subscription) or 30% commission
- External link, US storefront: 12% (Small Business) or 27% commission on purchases that originate from a tap on an external link in your app, within an attribution window after that tap
That last line is the catch. Apple does not give up the commission just because the user paid you directly. Apple asserts a "Link Entitlement" commission of up to 27% on revenue that flows through the external link, with mandatory reporting and a seven-day attribution window from the link tap. You have to report transactions to Apple within fifteen days. Apple invoices you for the commission. If your reporting is late or incomplete, your entitlement can be revoked and the app can be pulled.
So the actual question for an indie isn't "do I want to keep more of my revenue." It's "do I want to save three percentage points in exchange for the work of building, hosting, and reconciling an external checkout, plus the reporting overhead, plus the legal risk if Apple disputes my attribution numbers?"
For most apps under $1M ARR sitting in the Small Business Program, the answer is no. The math gets more interesting above that threshold, where you're trading 30% inside the app for 27% on a link tap. A three-point spread on $5M ARR is $150,000 — which buys real engineering time, but doesn't buy you out of all the operational work that comes with it.
How to actually implement it#
If you've decided the spread is worth it — or you have a strategic reason to move payment off-app, like running a single subscription that spans iOS, Android, and web — here is the cleanest implementation path.
1. Apply for the StoreKit External Purchase Link entitlement#
In App Store Connect, formally request the StoreKit External Purchase Link entitlement. This is separate from regular IAP capability. The entitlement is granted per-app and requires you to sign a separate addendum to your developer program agreement. The addendum is the document that defines the 27%/12% commission and the reporting obligations.
2. Add the entitlement to your build#
Once granted, add the com.apple.developer.storekit.external-purchase-link capability to your app's entitlements file in Xcode. Your provisioning profile needs to include it, which means regenerating profiles after the entitlement is approved.
3. Build the disclosure sheet using Apple's system component#
Apple requires a disclosure sheet — a system-presented sheet, not a custom one — before the user is sent out to the web. The sheet tells the user they're leaving the app, that Apple is not responsible for the external transaction, and that purchases made externally are not covered by Apple's support policies. The copy is templated by Apple and accessed through StoreKit's ExternalPurchaseLink API. Don't try to customise it; it will fail review.
4. Open the link in Safari, not in a web view#
The external URL has to open in Safari (or whatever the user's default browser is, on iOS 18+). It cannot open in SFSafariViewController and it cannot open in a WKWebView. This is non-negotiable in review. Apps that try to keep the user inside an embedded browser fail every time.
5. Implement the attribution and reporting pipeline#
This is the part most teams underestimate. Apple's terms require you to report all transactions that flow through the external link, with timestamps, amounts, attribution metadata, and the user identifier you used. Apple uses these reports to calculate the commission. You build a server-side job that posts transactions to Apple's reporting endpoint within fifteen days. The job needs to be reliable; missed reports are the most common reason entitlements get revoked.
6. Handle the receipt round-trip#
Inside the app, you need a path to confirm to the user that their external purchase has unlocked their entitlement. The pattern that has emerged: the user finishes checkout on the web, the web page issues a universal link back into the app, and the app calls your server to refresh the user's entitlement state. This is mechanically identical to a "log in via web" flow — if you already have that, the external-link flow is mostly plumbing on top of it.
Should you use external links? A decision framework#
Most indie devs reading this should not bother. Here is the framework I'd apply.
Reasons not to do it:
You're below $500K ARR. Small Business Program already gives you 15%. You're chasing a three-point spread (15% to 12%) on a base that's too small to justify the engineering and ops cost. Two engineering weeks of work plus ongoing reporting overhead to save $15K a year is a bad trade.
You only ship on iOS. The structural reason to do external links is to unify billing across platforms. If you don't have an Android, web, or desktop product, there is no unification to do — you're just adding a Safari hop to your checkout.
Your users hate friction. External links add a real checkout step (system disclosure, Safari, payment form, return-to-app deep link). For impulse purchases or low-ticket subscriptions, conversion drops materially. Spotify can eat that because their LTV is years; a $4.99 photo app cannot.
Reasons to do it:
You're a subscription business above $1M ARR with users on multiple platforms. You already have a working web checkout; using it on iOS just removes the IAP markup and unifies billing across the company.
Your customer LTV is high enough that the three-point spread compounds meaningfully — B2B SaaS, prosumer tools, anything with multi-year retention.
You need to own the customer relationship. Apple's IAP gives you almost no customer data. External checkout gives you an email and a lifecycle marketing path. For some businesses, that's worth more than the commission delta.
What App Review is actually looking for#
App Review has not loved this change, and you can feel it in the queue. Early external-link apps are reporting longer review times and more rejection rounds than usual. The recurring failure modes:
Custom disclosure sheets. Apple wants the templated copy verbatim, presented via their system component. Don't restyle it, don't translate it yourself, don't add a logo.
Non-Safari links. Opening the URL in any embedded browser is an instant rejection. The intent here is clearly: Apple wants the user to leave the app environment entirely.
Misleading pricing. If you advertise "save 20% on the web" but the actual web price is 15% cheaper after taxes, that's a 5.1.1 violation and will hold up the build.
Missing the disclosure on look-alike buttons. If the button looks like an in-app purchase button (size, position, language), the full disclosure flow still applies. App Review pattern-matches on the visual.
Submitting global builds with external-link UI. This is only allowed on the US storefront. Apps without a region check fail review for non-US regions and sometimes have the entitlement revoked entirely.
The pattern is the same as every new Apple guideline: the first version of the rule is enforced strictly and unevenly, and the boundaries clarify only after a few cycles of public rejections. If you're submitting an external-link app in the first half of 2026, budget for two rejection rounds before you ship.
Putting it together#
External purchase links are not a free win. They're a tool useful for a specific kind of app — cross-platform subscription business, high LTV, the engineering capacity to run an attribution pipeline — and a trap for everyone else. The most common indie mistake of 2026 will be reading the headlines, assuming 30% is going away, and shipping a link without doing the math on what Apple still charges.
If you do decide to ship one, the work splits into two halves: the on-device flow (entitlement, disclosure sheet, Safari handoff, return deep-link) and the off-device flow (web checkout, attribution reporting, receipt round-trip). The on-device half is the visible work. The off-device half is where teams fall behind, and where Apple revokes entitlements.
When you ship the update, you'll also need to refresh your App Store listing — new screenshots showing the updated paywall, metadata that reflects the external option, possibly new marketing assets. That's the unglamorous tail of every monetisation change, and it's the part Stora was built to take off your plate. The screenshot generator, listing copy, and compliance checks stay in sync with whatever your latest build supports — including the regional variants that need to look different in the US than elsewhere.
One last note. This rule changed because a court forced it to. The text will keep moving — Apple is still litigating, Epic is still litigating, Congress occasionally threatens to legislate. Treat your external-link implementation as something you will update at least once in the next twelve months, not a one-time build.