Apple Drops Two EU App Fees: Re-Model Your Economics

Apple changed its EU business terms again on 18 August 2026, and the change that matters most is not the one in most of the headlines. If you have a per-install line in your cost model, it is now modelling a fee that does not exist.

Get the date right before you get the numbers right

There is a lot of secondhand summary circulating that dates this announcement to 13 August 2026. It is wrong. Apple’s own developer support page states that the Apple Developer Program License Agreement was updated on August 18, 2026, and trade press dates the statement to Tuesday, 18 August 2026.

That matters more than pedantry usually does. If a brief you were handed has the wrong date on the announcement, it was written from a summary of a summary, and everything downstream of it — including the fee table someone pasted into a slide — deserves the same suspicion.

When you are about to tell a stakeholder what your margin is, the primary sources are Apple’s Newsroom post, the developer support pages, and the DPLA itself. Everything else is commentary, including this post.

Three changes, in Apple’s own order

Apple’s announcement leads with three things, and most coverage reordered them.

First, unification: Apple is moving every developer that distributes apps in the EU to a single set of business terms. Second, the Core Technology Fee is replaced by a Core Technology Commission. Third — and only third — the initial acquisition fee and the store services fee are eliminated.

The two deleted fees got the headlines because deletions are easy to write about. The CTF-to-CTC swap is the structural change, and the unification quietly removes a decision you may still have on a roadmap somewhere.

The per-install fee is gone, and that is the whole story

The distinction between the old fee and the new commission is not cosmetic. The CTC charges only when a digital transaction occurs. The CTF charged regardless of whether any revenue was generated from the install.

If you built a model in 2024 or 2025, you almost certainly have a term in it that multiplies installs by a per-unit cost — the thing that made free apps with large EU user bases genuinely frightening to model, because a viral week could produce a bill with no revenue attached to it.

Delete that term. Not adjust it — delete it. Every install-driven scenario you built, every “what if we get featured” stress test, every argument about whether to geo-restrict an EU launch, was solving a problem that the 18 August terms removed. Cost is now a function of transactions, which means your cost model has the same shape as your revenue model for the first time since 2024.

The practical consequence: free-to-download apps that monetise thinly, or not at all, are structurally cheaper to distribute in the EU than they were on 17 August.

The opt-in decision is being deleted; a different decision replaces it

If “revisit the alternative business terms opt-in” is a line item in your planning doc, cross it out. It is not a decision to re-make. Apple is moving every EU developer to one set of terms, so there is no opt-in to weigh.

The genuine re-decision is one most summaries skip: in-app purchase and alternative payment methods can now coexist. That invalidates the premise behind a large share of decisions made in the June 2025 era, when the choice was framed as either/or and teams reasoned about it as a fork in the road.

If you concluded a year ago that external purchase links weren’t worth the conversion loss of pushing users out of the app, that conclusion was correct under a rule that no longer applies. The question now is a mix question — which cohorts, which price points, which regions get which payment path — and mix questions have different answers than fork questions.

So is it cheaper? For subscription businesses, often not

This is the question you will be asked, and the honest answer for a renewal-heavy subscription business is largely no.

The year-two rate did not move. As John Gruber noted, Apple conceded no reduction at all to the 15 percent for subscriptions after the first year. If most of your EU revenue is renewals from cohorts acquired in prior years, the headline changes touch a small fraction of your P&L.

That sets a specific trap. A blended average rate computed across your whole EU book will move in the direction of the new terms and make the change look larger than it is. Model by cohort: first-year subscriptions, renewals, one-off purchases, and consumables each behave differently under the new structure, and a business whose growth has flattened is weighted toward the part that did not change.

Run both — the new terms against last quarter’s actual cohort mix, and against your forecast mix. If those two numbers disagree sharply, the disagreement is the finding, not a rounding problem.

Model it in code, with the unknowns as parameters

Spreadsheets rot because assumptions get typed into cells and lose their provenance. A small calculator, checked into the repo next to a link to the source page, survives the next rewrite — and there will be a next rewrite; this is the third set of EU terms in roughly two years.

Use Decimal, not Double. Money arithmetic in binary floating point produces cent-level drift that shows up exactly when a finance colleague is reading over your shoulder. And note there is no installs parameter anywhere in this model — that absence is the point.

import Foundation

struct EUTerms {
    var commission: Decimal              // rate for this cohort
    var coreTechnologyCommission: Decimal
    var paymentProcessing: Decimal       // zero if you collect payment yourself

    // Unverified as of 24 Aug 2026 — a switch, not an assumption.
    var chargedOnTaxExclusiveBase: Bool
}

func proceeds(grossPrice: Decimal,
              vatRate: Decimal,
              terms: EUTerms) -> Decimal {
    let exVAT = grossPrice / (1 + vatRate)
    let feeBase = terms.chargedOnTaxExclusiveBase ? exVAT : grossPrice
    let fees = feeBase * (terms.commission
                          + terms.coreTechnologyCommission
                          + terms.paymentProcessing)
    return exVAT - fees
}

No rates are hardcoded. You fill them in from the developer support page on the day you run it, and when the terms change again you change inputs rather than rewriting logic. This is deliberately pure Foundation with no StoreKit surface — a contractual change does not need an API-shaped answer, and API-shaped answers go stale.

What is still open, and why you should say so out loud

Three questions are load-bearing for any EU margin number and were not verified for these notes. Treat them as open until you have read the current source yourself.

Is commission charged on the tax-exclusive base? This single question moves the result of every worked example by roughly the size of the local VAT rate. That is why it is a parameter in the code above rather than a baked-in assumption.

Is there a distinct commission tier for alternative payments? At least one aggregator describes one; Apple’s release does not mention it. A contested detail should be reported as contested, not resolved by whichever source you read last.

Does the CTC carry a small-developer exemption? The CTF had thresholds. Whether the commission inherits equivalent relief determines whether this change is neutral or meaningful for a small studio.

A checklist before you quote a margin to anyone: confirm the announcement date against the DPLA update stamp; confirm each rate against Apple’s developer support page rather than a news article; identify which cohort each rate applies to; state the VAT base you assumed; and list the questions you could not answer. A margin figure delivered with three flagged unknowns is more useful than a confident one built on a summary with the wrong date on it.