The EU DMA, External Purchase Links, and What Changes for Your Submission
The Digital Markets Act gave developers distributing in the EU options they don't have elsewhere: an app on the App Store can communicate and promote offers for digital goods or services outside In-App Purchase, and apps can be distributed through alternative marketplaces or from a developer's own website. None of it is automatic. Steering users to an external purchase requires a specific entitlement and API, a system disclosure sheet, mandatory transaction reporting back to Apple, and a choice you cannot un-make casually — Apple does not allow In-App Purchase and external offers in the same app on the same storefront. This page covers what the options actually are, what App Review checks when you use them, and which parts of the arrangement have been changing repeatedly since 2024.
By the AscAuto team — engineers who automate App Store submissions and rejection fixes daily. · Last updated: July 2026
What the DMA actually opened up
| Option | What it means |
|---|---|
| Keep In-App Purchase | Nothing changes. Most apps are here, and there is no obligation to move. |
| Communicate and promote offers | Your App Store app can steer users to a transaction outside In-App Purchase — the subject of this page. |
| Alternative app marketplaces | Distribute through a third-party marketplace app rather than the App Store. |
| Web Distribution | Distribute your app directly from a website you own and have registered, subject to Apple's authorisation criteria and Notarization. |
These apply only to apps distributed to users in the 27 EU member countries. Everything outside the EU continues under the standard rules, which is why this is a per-storefront decision rather than a global one.
The entitlement you actually need
To communicate and promote offers inside an App Store app, Apple requires the StoreKit External Purchase Link Entitlement together with the ExternalPurchaseCustomLink API and its usage guidelines. The API exists to present the system-provided disclosure sheet: the screen that tells the user they are about to transact with you and not with Apple. Users can opt out of seeing that sheet before subsequent purchases, but you cannot skip presenting it.
Two consequences for your build: the entitlement has to be in the app you submit, and the disclosure flow has to be reachable by a reviewer. An entitlement that appears in the binary without a working flow behind it is exactly the kind of mismatch App Review catches.
The rule that catches people: one model per storefront
Apple's wording is unambiguous — developers may not offer both In-App Purchase and communicate or promote offers for digital goods or services to users in their App Store app on the same storefront. So this is not an additive feature you switch on to see what converts better. On a given storefront you are either an In-App Purchase app or an external-offers app, and the decision affects refunds, subscription management, Family Sharing and Ask to Buy, none of which reflect external transactions.
What users see
- An informational banner on your App Store product page, added by Apple, identifying that the entitlement is enabled.
- A note on the download confirmation sheet telling users the app offers external purchases.
- The system disclosure sheet in-app before the user leaves to transact.
Worth planning for: users see this before they ever open the app, so the conversion story starts on the product page, not in your paywall.
Reporting is mandatory, not a formality
Developers who communicate and promote offers are required to use the External Purchase Server API to report transactions to Apple, because Apple calculates and collects the applicable commissions and fees from those reports. In practice this means a server-side integration and an ongoing operational obligation — the part teams forget when they model link-outs as "just a URL".
What it costs — and why no honest page gives you a number
Apple charges commissions and fees on external-link sales in the EU. The structure has consistently had three moving parts: a fee tied to acquiring the customer, a store services fee that varies by the tier of services you take, and a core technology component charged on digital goods and services. What has not been stable is the numbers, the tier definitions, and the timing of the shift from Apple's per-install core technology fee to a revenue-based core technology commission — announced, rescheduled, and still in play with the European Commission at the time of writing.
So the useful advice is procedural rather than numeric: model your economics from Apple's current terms document on the day you decide, re-check before you ship, and don't let a secondary source — this page included — be the input to a pricing decision.
Alternative distribution, in one paragraph
Marketplaces and Web Distribution are separate from the link-out entitlement and carry their own requirements: agreeing to Apple's alternative terms addendum, Notarization for every build, Apple authorisation with ongoing criteria for Web Distribution, registered domains, and marketplace-specific tokens. Several App Store features stop applying to purchases made this way — Family Purchase Sharing, Ask to Buy, universal purchase, and Apple-side refunds and purchase history — and support for those users becomes yours or the marketplace's problem. That trade is the whole decision; the technical setup is the easy part.
What this means at review time
- Your entitlement and your behaviour must match. Shipping the entitlement means the disclosure flow must work; shipping external links without the entitlement is a straightforward Guideline 3.1.1 rejection.
- Reviewers need to reach the flow. Put it in the review notes, with a demo account if the paywall sits behind a login — the same discipline that prevents most 2.1 rejections.
- Region-specific behaviour needs explaining. If the app behaves differently for EU users, say so in the notes rather than letting a reviewer outside the EU conclude the feature is broken.
- The US situation is different. Link-out rules in the United States came from separate litigation and have their own terms; don't assume an EU implementation is compliant elsewhere, or the reverse.
How AscAuto handles it
AscAuto doesn't make the business decision for you, and it can't: choosing between In-App Purchase and external offers is a pricing and product call with legal implications. What it does is keep the submission side honest — the readiness scan checks the version's declarations and reviewer-facing information before you submit, and if a rejection comes back citing 3.1.1 or a mismatch between entitlement and behaviour, it reads Apple's message, classifies it, and drafts the fix as either a metadata change, a reviewer reply, or a pull request, for your approval. Status tracking covers the waiting part.
FAQ
What is the StoreKit External Purchase Link Entitlement?
The entitlement an App Store app needs in the EU to communicate and promote offers for digital goods or services outside In-App Purchase. Apple requires it together with the ExternalPurchaseCustomLink API, which presents the system disclosure sheet telling users they'll transact with you, not Apple.
Can I offer both In-App Purchase and an external purchase link?
Not on the same storefront. Apple's rule is explicit, so it's one model per storefront — a product decision rather than an implementation detail.
Do I have to report external purchases to Apple?
Yes. You're required to use the External Purchase Server API to report transactions, because Apple calculates and collects the applicable commissions and fees from those reports.
Does linking out mean paying Apple nothing?
No. Apple charges commissions and fees on external-link sales in the EU — an acquisition-related fee, a store services fee that varies by tier, and a core technology component. The exact rates and the core technology fee/commission transition have changed repeatedly since 2024, so read the current numbers from Apple's terms, not from any blog post including this one.
What do users see when an app uses external purchase links?
An informational banner on the App Store product page, a note on the download confirmation sheet, and the system disclosure sheet in-app before they leave to transact — though users can opt out of seeing that sheet for later purchases.