For fifteen years the rule was simple: if you sell something digital inside an iPhone app, it goes through Apple's In-App Purchase and Apple takes a commission. That sentence is no longer true everywhere, and where it stops being true depends on the storefront of the user's country.

The United States and the European Union now run on different rules. The rest of the world works as it always did. And part of it sits with the US Supreme Court, so what's true today may not be in a few months.

This guide separates what's written in Apple's own rules — which can be quoted — from what's in a judge's hands.

What hasn't changed: when In-App Purchase is mandatory

The base rule is still in the App Review Guidelines, and it's worth reading in full before designing anything:

"If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc."

That list of banned mechanisms is specific on purpose: they're the workarounds developers have been trying for years. A QR code that unlocks the paid version isn't a grey area — it's named.

What never went through In-App Purchase

The other extreme, which surprises people arriving from commerce:

"If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry."

So a retail, food delivery or booking app cannot use In-App Purchase for its cart. It isn't optional: it's an obligation in the other direction.

The line, then, isn't "digital versus physical" by eye. It's where it's consumed: inside the app, In-App Purchase; outside the app, your own payment methods.

The United States: the exception that changed everything

Here's the big shift, and it's written into Apple's own guidelines with unusual clarity. On the entitlements that used to be required to link out:

"These entitlements are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps."

And the general rule, with its exception embedded:

"In all other storefronts, except for the United States storefront, where this prohibition does not apply, apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase."

Read it twice, because plenty of people haven't absorbed it: in the US storefront you can put a button that takes users to your website to buy, without asking anyone's permission. It isn't a special entitlement you apply for. It isn't, because in that storefront the prohibition doesn't exist.

Where it comes from: the April 2025 court order in Epic v. Apple, when the judge found Apple had breached the earlier anti-steering injunction and required it to allow external purchase links in apps installed from the App Store.

The rest of the world is unchanged

Outside the US and the EU the prohibition stands: no buttons, links or calls to action pointing at purchase mechanisms other than In-App Purchase. Not in the app and not in its metadata.

With two long-standing nuances:

  • Reader apps — magazines, newspapers, books, audio, music and video — may let users access previously purchased content, offer account creation on free tiers and provide account management for existing customers.
  • Informational links under specific entitlements, telling users where and how to purchase and that prices may be comparatively lower.

And the litigation isn't over

This is the part where it's worth being honest about what isn't known, because it affects any twelve-month plan.

Per coverage of the case: in December 2025 the Ninth Circuit upheld the contempt finding against Apple but narrowed the scope of the remedy, leaving open that Apple may charge some commission on external purchases provided it isn't the previous 27%. Rehearing was denied in March 2026, and on 30 June 2026 the Supreme Court agreed to review the matter, with argument in the term beginning in October.

Meanwhile, the exact percentage Apple will be able to charge on a purchase that starts in its App Store and ends on your website remains unset: the district court is determining it with the parties.

What that means in practice:

  • What the guidelines permit in the US today is permitted today, and can be implemented.
  • Don't build a business model that depends on the external commission being zero. It may stop being zero.
  • Design so you can change payment mechanism without rewriting the product. More on that below.

The European Union is a different regime entirely

Here it isn't a court ruling but the Digital Markets Act, and Apple has rebuilt its terms around it. What Apple publishes:

Three distribution routes, all requiring notarization: the App Store, Web Distribution from your own site, and alternative app marketplaces.

Reduced commissions on the App Store: 10% for the vast majority of developers and for subscriptions after the first year, and 17% for other transactions during the first year.

Payment processing separately: +3% if you use the App Store's, and 0% if you use an alternative payment service provider in-app or link to your website.

Core Technology Fee (CTF): €0.50 per first annual install above one million, for developers on alternative terms. Per Apple, fewer than 1% of developers pay it, and there's a three-year on-ramp for small developers.

Core Technology Commission (CTC): 5% on sales of digital goods and services that the developer communicates and promotes in-app with actionable links. In effect since 26 June 2025.

And a structural rule that decides architectures: you can't mix In-App Purchase with external payment promotion on the same storefront. It's one or the other, per territory.

⚠️ This is the most volatile of the three regimes. Apple announced a move to a single technology-commission model, and that timeline has shifted. Before setting a price or a model, check Apple's terms page that same day. Any figure in any article — including this one — is a snapshot.

What it means for your product: four scenarios

You sell physical goods or real-world services. Almost none of the above affects you. You can't use In-App Purchase, and you never could. Your cart runs on Apple Pay or card.

You sell digital content and your market is the US. You can link to your site and collect payment yourself. With the caveat that the commission on those purchases is judicially up in the air.

You sell digital content and your market is the EU. You have three distribution routes and a fee table that has changed several times in two years. Run the numbers with your real volume before deciding, because the cheap route at one revenue band isn't the cheap one at another.

You sell digital content in the rest of the world. In-App Purchase, no further conversation.

And the most common case of all: you sell in several of those at once. Then the product has to support different payment mechanisms depending on the user's storefront, and that's an architecture decision, not a config toggle.

The architecture mistake that costs

The pattern we've seen break products: coupling user entitlement logic to the payment mechanism.

That is, having the app ask "did they buy this through In-App Purchase?" to decide whether to unlock something. It works until the day there are two mechanisms, and then you have conditionals everywhere and impossible states — a user who bought externally but the app doesn't recognise.

The right shape is your own entitlements layer:

  1. The user has or doesn't have access to something. That lives in your backend, with your identity.
  2. How they got it — In-App Purchase, your website, a corporate code, a promotion — is a field on the purchase record, not a condition on the screen.
  3. The app asks about the entitlement, never about the receipt.

With that, adding or removing a payment mechanism is backend work and one screen, not a rewrite. And it's what lets you respond to a rules change — more are coming — without rebuilding the product.

Two more consequences worth resolving up front:

  • Server-side receipt validation, never on the device.
  • Your own user identifier that survives device and payment-method changes. If entitlement is tied to the store account, a user switching platforms loses what they paid for.

What to do today

  1. Work out which scenario you're in, per market, not in general.
  2. Check the date on any figure you're using to decide, including the ones here. This ground moves.
  3. Separate entitlements from payment in your architecture, even if you only have one mechanism today.
  4. Don't build the model on a commission that's sitting in a courtroom.

Primary sources, consulted on 14 August 2026: App Review Guidelines, section 3.1, and Update on apps distributed in the European Union, Apple Developer. The procedural status of Epic v. Apple comes from public coverage of the litigation and not from an Apple source: it's the part of this article to verify before making a business decision.