On 18 August 2026 Apple published updated business terms for the European Union, taking effect on 1 October. The Core Technology Fee, a per install charge that applied once a developer reached significant scale, is replaced by the Core Technology Commission: a flat 5 percent on digital transactions in apps distributed outside the App Store. The Initial Acquisition Fee and the Store Services Fee are removed, and apps may now offer alternative payment options alongside Apple In App Purchase.
The headline reads as simplification, and it is. The part worth your attention is that a fee charged per install and a commission charged per sale behave in opposite ways, and the switch quietly moves the burden from one kind of app to another. If you have a large free user base and modest revenue, this is good news. If you convert well, it is a cost you did not previously have.
The arithmetic reverses, and it reverses hard
A per install fee is a function of downloads. It does not care whether a user ever pays, which is why it was so painful for free apps with wide distribution: a viral week produced a bill and no revenue to set against it.
A commission on digital transactions is a function of sales. Downloads become free again, and the charge only arrives when money does. For anything with a long free tier, a generous trial, or a large dormant install base, that is a structural improvement rather than a marginal one.
The same change runs the other way for a paid app or a subscription product with strong conversion. Under the old terms a fee was capped by your install count. Under the new one it scales with your success, without a ceiling. Nobody has removed a cost from you; they have moved where it is measured.
The practical implication is that you cannot know which side of this you are on without running your own numbers. We have looked at client models where the switch is worth a meaningful annual saving, and others in the same category where it is a straightforward increase, and the difference between them was conversion rate rather than size.
Alternative payments become a product decision
The more interesting clause is that apps can offer alternative payment options alongside Apple In App Purchase rather than instead of it. That framing matters, because a choice presented to a user is a user experience question before it is a commercial one.
The commercial case is obvious. Your own payment rail costs less than the platform's, so every transaction routed through it improves margin. The case against is equally real and gets discussed far less.
Apple's purchase sheet is the most familiar payment interaction on the device. Users have completed it hundreds of times, their card is already stored, and the whole thing takes a thumbprint. Any alternative you present competes with that, and in every checkout test we have run across web and mobile, an unfamiliar payment step costs conversion. If your alternative rail saves you a few percent and loses you more than that at the point of sale, you have optimised the wrong number.
There is also an operational cost nobody budgets for. Two payment rails means two sets of receipts, two refund processes, two reconciliation jobs, and a support team that has to work out which one a given customer used before it can help them.
Child safety requirements come attached
The same update adds child safety protections for alternative payments on the App Store. This is not a footnote you can leave to the legal review, because it lands in the payment flow itself.
If you take payments outside Apple's system, the age assurance and parental consent that Apple was handling on your behalf becomes partly your responsibility. That is engineering work, not paperwork, and it needs to be in the estimate alongside the payment integration rather than discovered during review.
It also connects to a wider pattern. Apple applied age assurance requirements for new accounts in Texas from 4 June 2026 following a court ruling on state law SB 2420. The direction across both regulators and platforms is that whoever handles the transaction handles the age check, and taking the transaction means taking the obligation.
This is the European Union only
Worth stating plainly, because the coverage of this announcement has been loose about it. These are EU business terms, arising from the Digital Markets Act. They do not change what you pay in the United States, the United Kingdom, India or anywhere else.
For a developer with meaningful EU revenue, that means running two commercial models in one product, and possibly two payment experiences, gated by the user's storefront. That complexity is the actual cost of the change for multi market apps, and it is not on the announcement page.
For a developer with little EU revenue, the correct response this month is to read it, note it, and do nothing. Not every platform announcement is a project. We have watched teams spend a sprint on a regulatory change that applied to under 2 percent of their revenue, which is a real cost incurred to feel responsive.
What to do before 1 October
Three things, in order, and the first is not optional.
Accept the updated Apple Developer Program License Agreement, Attachment 14, in App Store Connect. Terms changes that require acceptance have a habit of sitting unread in an account nobody logs into until a release is blocked by them, and a blocked release during a launch week is an avoidable bad day.
Then model both structures against your last twelve months. What you actually paid under the old terms, what the same year would have cost under the new ones, and what next year looks like if conversion improves as you intend. That third case is the one that reveals whether the commission is a saving or a growing liability.
Then decide about alternative payments deliberately rather than by default. The honest answer for most apps is not yet: implement nothing, instrument your checkout, and revisit when you know your conversion baseline well enough to detect a two point drop.
Both stores are moving in the same direction
This is not an Apple story in isolation. Google restructured its own service fees this year, splitting billing from services and introducing a lower tier for qualifying developers, which we went through in what the Play fee restructure actually costs.
The pattern in both is the same. Flat platform charges are being unbundled into components tied to specific services, and developers are being given more choice about which components they buy. More choice is genuinely better and it transfers the analysis to you. The store used to tell you what it cost; now you have to work it out.
The practical consequence is that platform economics has become a recurring finance task rather than a one time setup decision. Whoever owns your app's P and L should have a calendar reminder for it, in the same way that the target API deadline we covered in the Android target API cutoff is now an annual engineering commitment rather than a surprise.
Our mobile app development work now includes modelling store economics before a monetisation design is signed off, because the pricing that works under one fee structure can be unprofitable under another, and that is much cheaper to discover on a spreadsheet.
Frequently Asked Questions
Does this change what I pay outside the EU?
No. These are European Union business terms under the Digital Markets Act, and terms in every other market are unchanged. If your EU revenue is small, the correct response is to note it and carry on rather than to start a project.
Is the 5 percent commission on top of the standard App Store commission?
The Core Technology Commission applies to digital transactions in apps distributed outside the App Store, which is the alternative distribution case. It replaces the Core Technology Fee rather than adding to the standard App Store commission for apps distributed through the store itself. Read Attachment 14 for your specific distribution route rather than relying on a summary.
Should we implement alternative payments now?
Only if you have measured your current checkout well enough to detect a small conversion drop. The margin gain is easy to calculate and the conversion loss is not, and an unfamiliar payment sheet reliably costs some percentage of completed purchases. Instrument first, decide second.
What happens if we do not accept the new terms?
Terms acceptance in App Store Connect gates releases. The realistic failure mode is not a penalty, it is discovering during a release that someone with the right account permissions needs to click accept and is on holiday. Do it now, while it costs nothing.
Does this help free apps?
Generally yes, and materially. A per install fee charged an app for downloads that produced no revenue, which was the structural complaint against it. A commission on transactions charges nothing until a user pays, so a large free tier stops being a liability.
Do we need to change our pricing?
Not reflexively. Work out the new cost per transaction first, then decide whether it changes your margin enough to matter. Pricing changes are expensive in customer trust and should follow the arithmetic rather than the announcement.
Who should own this internally?
Whoever owns the app's profit and loss, not the engineering lead. The engineering work here is small; the modelling and the alternative payments decision are commercial calls with an engineering consequence, and treating it as a technical task is how it ends up unowned.
Talk to our team if you sell in the EU and are not sure whether 1 October makes your app cheaper or more expensive to run.