Apple EU DMA 2026: What Indie iOS Developers Must Do Before the Deadlines

If you ship iOS apps to the EU in 2026, there are two specific dates you need on your calendar and one decision that changes your unit economics more than any pricing experiment you have ever run. Apple's EU rules shifted twice in the last 12 months, the fee structure rebranded from Core Technology Fee to Core Technology Commission on January 1, 2026, and the agreement deadline for EU terms is March 17, 2026. This is the practical guide I wish my lawyer had sent me.

Short version: most indie developers making less than roughly 100,000 EUR a year in EU app revenue should stay on the standard terms. Most developers making more than about 500,000 EUR a year in EU subscriptions should opt into the EU terms and adopt external purchase links through a provider like RevenueCat or Adapty. The middle band is case-by-case. Details, math, and the exact code path below.

The two dates to put on your calendar right now

Two deadlines matter for 2026 planning. Miss either and your EU business gets noisier than it needs to be.

Notice the second row carefully. If you do nothing, you stay on the terms you are on. For most indies, doing nothing is the correct answer. The deadline only matters if you have decided to change, or if you are still on the old EU Addendum from 2024 and want to move to the new 2026 version.

CTF versus CTC in plain English

Core Technology Fee was a per-install annual fee that applied to apps on EU alternative terms and exceeded 1 million annual installs. It was the most contentious piece of the original 2024 Digital Markets Act compliance package because a viral free app could owe Apple real money with no revenue to back it.

Core Technology Commission, effective January 1, 2026, replaced the per-install model with a percentage commission on external sales made through your app, plus reduced store commission. The headline numbers, roughly:

• Apple store commission, EU terms. Dropped from 17% (standard 30%) to 10%. 13% for subscribers into their second year, down from 10%.
• Core Technology Commission. Apple's share on external purchases that are promoted inside the app. Typically quoted around 5% of the external transaction.
• Per-install CTF. Still exists for the 2024 Addendum users, being phased out through 2026 on the 2026 Addendum.

Net effect: the cost of going to EU terms is now a commission you pay on revenue you actually collected, rather than a fee you paid per install whether or not you monetized. For high-ARPU subscription apps, this is a meaningful win. For low-ARPU apps with high install counts, CTC is far more forgiving than CTF was.

The three paths you can actually pick

When you distribute to the EU in 2026 you have three real options.

• Path 1: Standard App Store terms. Ship in-app purchase as normal. Apple takes 15% (Small Business Program) or 30% (standard) of each transaction. No external payment links, no sideloading, no fee you do not already know.
• Path 2: EU terms with App Store only. Accept the 2026 EU Addendum. You keep distributing through the App Store but can also offer external purchase links. Apple takes 10% of transactions on the App Store (13% in the second year of a subscription) and a roughly 5% Core Technology Commission on external sales promoted in the app.
• Path 3: EU terms with alternative distribution. Accept the 2026 EU Addendum and distribute via a marketplace (AltStore, Setapp Mobile) or the Web Distribution program. This is the full sideloading story. Adds notarization, marketplace relationships, and operational overhead most indie developers do not need.

Most of this article focuses on Path 1 versus Path 2. Path 3 is real and growing but is a bigger commitment than a single blog post can do justice.

The decision: when opting into EU terms pays off

The question is simple, the math is not. Here is the rule I use when an indie developer asks me whether to opt in. Assume EU is roughly 20% of your total revenue (adjust from your analytics) and run this table.

The numbers are approximate and assume you still use the Apple Small Business Program on the standard-terms row (15% rate). If you are above 1M USD annual revenue and paying the 30% standard rate, the EU terms become attractive at lower volumes because the delta is larger.

Three qualitative factors also matter and do not show up in the math:

• Payment processing fees. Stripe and Paddle charge 2.9% to 4% plus fixed fees on external purchases. Subtract that from your EU-terms revenue gain before comparing.
• Chargebacks and refunds. Apple handles these. When you take payment externally, you handle them. Indies underestimate this until their first big chargeback week.
• VAT compliance. Apple collects and remits VAT in the EU. If you sell externally in the EU, you are responsible for registering and remitting VAT in every member state where you have customers (or via the One-Stop Shop scheme).

Small Business Program interactions

This is where I see the most confusion. The Apple Small Business Program drops your App Store commission to 15% if your worldwide proceeds stay under 1 million USD per year. It applies on standard terms only.

• If you are on standard terms, Small Business Program is automatic once you qualify. You pay 15% on subscriptions in year one and beyond.
• If you switch to EU terms, you lose Small Business Program automatically. The EU addendum is a different commercial agreement. You pay the EU-terms commission (10%, or 13% in the second year of a subscription).
• The delta between 15% standard and 10% EU terms on the same EU transaction is 5 percentage points. Before you switch, confirm that the mix of transactions affected is enough to justify losing Small Business Program on your non-EU revenue in the same worldwide year (if you have any dependency on that math).

External purchase link entitlement: how it actually works

The piece of the EU terms that matters most operationally is the StoreKit External Purchase Link entitlement. Once granted, you can place an in-app button that links out to your web paywall. Stripe Checkout, Paddle, or your own Stripe integration then collect the payment. Apple is notified of the external transaction and takes the Core Technology Commission.

The steps in order:

1. Accept the 2026 EU Addendum in App Store Connect.
2. Request the External Purchase Link entitlement for your app from Apple Developer support. Approval is typically a few business days if the app is already on the store and in good standing.
3. Add the com.apple.developer.storekit.external-purchase-link entitlement to your target and list your destination URLs in the configuration plist.
4. Add the UI: a button that uses ExternalPurchaseLink (StoreKit) to open the web flow. Apple requires a specific disclosure sheet to appear the first time and a conservative visual treatment thereafter.
5. On the server side, implement a reporting endpoint. Apple's external payment reporting requires you to report each external transaction so the Core Technology Commission can be billed. Most indies route this through a service like RevenueCat, which handles the reporting automatically.

The last bullet is the hidden cost. You owe Apple visibility into every external sale. If you miss reports, you still owe the commission. A billing-aware subscription platform is not optional at this point, it is a prerequisite.

RevenueCat and Adapty position in 2026

Both major subscription platforms shipped EU-terms support through 2025 and stabilized it in Q1 2026. The current state:

• RevenueCat Web Billing. You sell subscriptions through Stripe on web, RevenueCat syncs entitlement state across iOS, Android, and web. For EU external purchase links, RevenueCat now handles the Apple external payment reporting automatically. Your Flutter or SwiftUI app only sees entitlements.
• Adapty. Similar playbook: web paywalls, Stripe integration, external purchase link reporting. Their paywall builder is more mature on the web side.
• Roll your own. Possible with StoreKit 2 plus a Stripe integration plus a small Apple reporting service. Two to three weeks of work, plus ongoing maintenance. Hard to justify for most indies.

My default recommendation: if you already use RevenueCat, enable Web Billing and flip on external purchase link reporting. It is the cheapest path to EU-terms compliance. If you are starting fresh, RevenueCat or Adapty both work. The Swift Kit ships with RevenueCat and a toggle for external purchase link mode, which is what this whole article is pointing toward operationally.

What the SwiftUI code looks like

The actual app-side work is smaller than the legal work. Here is the minimal shape of an external purchase link in SwiftUI, simplified for clarity.

import SwiftUI
import StoreKit

struct PaywallView: View {
    @State private var showDisclosure = false

    var body: some View {
        VStack(spacing: 16) {
            Button("Subscribe on our website") {
                Task { await openExternalPaywall() }
            }
            .buttonStyle(.borderedProminent)
        }
    }

    func openExternalPaywall() async {
        // Shows Apple's required disclosure sheet the first time,
        // then opens the URL listed in your entitlement plist.
        try? await ExternalPurchaseLink.open()
    }
}

The code is three lines of real logic. The work is in the entitlement file, the reporting service, and the App Review disclosure. On iOS 18 and newer the required disclosure sheet is drawn by StoreKit itself, so you do not build that UI yourself.

Dual-mode architecture: IAP and external link behind one interface

If you sell in multiple regions, you want one paywall that switches between in-app purchase and external link based on the user's region and your feature flags. Do not hard-code the path. Put the purchase call behind a protocol.

protocol PurchaseService {
    func availableProducts() async throws -> [Product]
    func purchase(_ product: Product) async throws -> Entitlement
}

struct StoreKitPurchaseService: PurchaseService { /* standard IAP */ }
struct ExternalLinkPurchaseService: PurchaseService {
    func purchase(_ product: Product) async throws -> Entitlement {
        try await ExternalPurchaseLink.open()
        // RevenueCat webhook eventually updates entitlement
        return try await RevenueCat.shared.awaitEntitlement(product.id)
    }
}

final class RegionalPurchaseRouter: PurchaseService {
    func purchase(_ product: Product) async throws -> Entitlement {
        if FeatureFlags.euExternalPurchaseEnabled && user.region.isEU {
            return try await externalLink.purchase(product)
        }
        return try await storeKit.purchase(product)
    }
}

Your paywall SwiftUI view consumes PurchaseService. The router decides per-call. Toggling EU external purchase on or off is a feature-flag change, not a code rewrite. This is the dual-mode pattern The Swift Kit ships by default.

Practical checklist for indie iOS developers

A minimum viable EU compliance posture in 2026 for a solo indie:

• Confirm current terms. Open App Store Connect, Agreements, Tax, and Banking. Note whether your app is on Standard or EU terms, and whether you qualify for the Small Business Program.
• Calculate your EU revenue share. Pull App Store Connect revenue by country for the last 12 months. Group EU storefronts. Know the percentage.
• Run the math. Use the table above. If EU terms gain you less than $2,000 per year after PSP fees, stay standard. Operational overhead is not worth the delta.
• If you opt in: accept the 2026 EU Addendum before March 17, 2026. Expect to lose Small Business Program worldwide.
• If external purchase link: request the entitlement, add it to your target, connect RevenueCat Web Billing or Adapty equivalent, implement the reporting webhook.
• Legal hygiene. Update your privacy policy and terms to reflect external purchases. Register for EU VAT via the One-Stop Shop scheme if you expect meaningful external-link volume.
• Update App Review notes. Call out the external link in your submission notes so reviewers know where to find it.
• Monitor. Watch refund rates, chargebacks, and support tickets for the first 30 days after enabling external purchases. Expect a spike.

What The Swift Kit gives you

The Swift Kit ships a PurchaseService protocol with two implementations: StoreKit 2 and External Purchase Link. A RegionalPurchaseRouter picks the right one per-user based on region and feature flags. RevenueCat is wired by default, including the external payment reporting webhook. The paywall UI is identical in both modes, which is the whole point.

If EU compliance math is something you intend to switch on and off over the next year, starting with that dual-mode architecture saves you a rewrite. $99 one-time, unlimited commercial projects. See every integration on the features page or jump to pricing.

Final recommendation

For most indie iOS developers in April 2026, the right action is to stay on standard terms, keep using the Apple Small Business Program, and revisit the decision once EU revenue is a consistent six-figure line on your own income. When you do switch, switch with the dual-mode architecture already in your code, not bolted on after.

The worst outcome is accepting the EU addendum in a panic before March 17 without a RevenueCat Web Billing flow and reporting webhook in place. You end up owing Apple the external-sales commission on revenue you cannot cleanly reconcile. Do the math first. Ship the infrastructure first. Then switch.