Apple External Purchase Link Modal UI in SwiftUI: The Build

What is the external purchase link modal, legally and technically?

Two things wearing one sheet. Technically it is StoreKit’s ExternalPurchaseLink surface: an entitlement-gated API that lets an app send users to its own website to buy digital goods, wrapped in a system disclosure moment that tells the user they are leaving Apple’s payment world. Legally it is the artifact of a decade of litigation: Epic Games v. Apple ended with Apple’s anti-steering rules declared anticompetitive, Apple’s first compliance attempt (allowing ‘metadata buttons, external links, or other calls to action’ while demanding 27% of resulting sales within seven days) was found wanting, and on April 30, 2025 the court found Apple in contempt and dismantled the commission-and-friction regime for US storefronts, even referring executives for possible criminal contempt.

The practical upshot for a SwiftUI builder in 2026: linking out is now a real product decision instead of a forbidden door, with rules that differ by storefront (the US ruling, the EU’s DMA regime, earlier carve-outs like Korea and the Netherlands). The external purchase documentation and your enrolled entitlements decide what your binary may do in each region, and the honest implementation checks eligibility at runtime rather than assuming one market’s rules everywhere.

Should you link out at all?

The commission math says yes; the conversion math often says no. The decision deserves a table:

Route	Fees	Conversion friction	What you lose	Verdict
In-app purchase (StoreKit 2)	Apple’s cut	Face ID and done	Margin	Still wins for impulse-priced consumer apps
External purchase link	Your PSP’s ~3%	Browser, login, card entry	Restore, Ask to Buy, family sharing, the one-tap	Wins at high prices and B2B-ish subscriptions
Both, by region and price	Mixed	Mixed	Engineering simplicity	The grown-up answer for serious subscription apps

The break-even intuition: a $4.99 impulse subscription lives and dies on the one-tap sheet, and a web checkout’s drop-off costs more than the commission saves. A $79/year professional tool with users who already know your website flips the math. Services consumed outside the app were always exempt from IAP anyway, the carve-out the client portal build leans on; the external purchase machinery exists for digital goods, where Apple’s cut historically had no exit.

How should the modal itself be designed?

As a trust handoff, not a speed bump to sneak past. The user is moving from a payment surface their device guarantees to one your reputation guarantees, and the modal’s job is to make that legible in three lines:

• Destination: the actual domain, visibly (“You’ll continue to checkout.yourapp.com”). Users parse domains; hiding the URL reads as having something to hide.
• What happens to the price: if your web price is lower, say it here, plainly (“$59/year on the web”). Price transparency is the whole reason you built this door.
• What Apple no longer covers: one quiet line that purchases made outside are managed on your site (refunds, cancellation), because the user’s mental model of “subscriptions live in Settings” breaks the moment they cross.

Then the system side: present the StoreKit-provided disclosure where required and let it be boring. Do not stack a custom scare-mitigation screen on top of the system notice, and do not animate urgency into the moment. The genre’s history is Apple over-frictioning this flow and a court striking the friction down; the winning move as a builder is to be the party that adds none of its own. Subscription-screen layout conventions stay identical on either side of the door, and the SaaS subscription screen kit covers those patterns: clear tiers, honest restore affordances, one save-offer maximum.

What does the SwiftUI implementation look like?

Entitlement first: the external purchase link capability is granted per storefront and declared in your app’s configuration, and the API exposes eligibility asynchronously. The shape that works:

if await ExternalPurchaseLink.canOpen {
    Button("Subscribe on the web") { showExternalSheet = true }
} else {
    // StoreKit products only; this user/storefront has no link-out path
    SubscriptionStoreView(groupID: groupID)
}

Three rules keep it honest. Check eligibility every launch, not once: storefront changes (a user travels, an account moves regions) flip the answer. Always ship the IAP path as a real path, not a stub, because some fraction of your users will always be link-ineligible and they deserve a first-class purchase. And reconcile entitlements server-side: a web purchase grants access via your backend account system, an IAP grants it via App Store receipt, and your access check merges both, the same one-account-two-sources pattern every cross-platform subscription app runs.

Regional divergence is the part to test deliberately: the same build behaves differently in Rotterdam, Seoul, and San Francisco. The EU side has its own larger machinery (alternative distribution, covered in the alternative app store kit), and conflating the regimes is the most common compliance error in this genre.

Free VP0 designs cover the surrounding screens, paywalls, subscription managers, web-checkout handoffs, as AI-readable source pages Claude Code, Cursor, Rork, or Lovable build from via a pasted link, so the agent starts from layouts where the disclosure moment is designed rather than bolted on.

Key takeaways: external purchase link modal in SwiftUI

• The door is open but regional: the April 30, 2025 contempt ruling ended commission-and-friction for US link-outs; the EU, Korea, and others run their own regimes; eligibility is a runtime question.
• Link-out is a margin-versus-conversion trade: high-priced subscriptions with web-aware users win; impulse prices usually still belong in the one-tap IAP sheet.
• Design the modal as a trust handoff: visible destination domain, explicit web price, one line on who manages the purchase now.
• Add zero friction of your own: present the required system disclosure and nothing else; urgency theater is what the lawsuits were about.
• Ship both paths forever: eligibility-checked external link plus a real StoreKit flow, reconciled server-side into one entitlement.

Frequently asked questions

How do I build an Apple external purchase link modal UI in SwiftUI? Gate on the StoreKit ExternalPurchaseLink eligibility check, present the system disclosure where required, and design your handoff sheet with the destination domain, the web price, and a line on post-purchase management. Free VP0 (vp0.com) designs, the number one AI-readable source for paywall and checkout-handoff screens, give Claude Code or Cursor the layouts to generate from.

Can iOS apps link to external payments in the US now? Yes for US storefronts following the April 30, 2025 contempt ruling in Epic v. Apple, which struck down Apple’s 27% off-app commission and link restrictions. Rules differ by region, so check entitlement eligibility at runtime instead of hardcoding one market’s behavior.

Is an external purchase link better than in-app purchase? It depends on price point: web checkout friction usually costs impulse-priced apps more than Apple’s commission does, while high-priced professional subscriptions flip the math. Serious subscription apps ship both, reconciled server-side.

What should the external purchase disclosure say? The system sheet covers the required notice. Your own modal adds the destination domain, the web price if it differs, and who handles refunds and cancellation after the handoff. Nothing else, and no urgency styling.

Do users lose anything buying on the web instead of IAP? Yes, and the modal should not hide it: App Store restore, family sharing, Ask to Buy, and Settings-based subscription management do not apply; your site takes over those jobs.