Opinion
App Store Fees in 2026: Apple's EU Stack and the Case for Web-to-App Billing
May 8, 2026
A £10 monthly subscription used to be a simple piece of arithmetic. Take £7 net, give £3 to Apple, plan the next year of headcount.
That maths no longer holds. As of January 2026, the same £10 sub generates a different margin in Berlin, Manchester, Tokyo, and Austin. The flat 30% commission is gone in Europe, partially gone in the US, weakening in the UK, and being replaced in Japan. In its place is a stack of modular fees, regional carve-outs, and "alternative" distribution paths that look optional until you realise your competitors have already moved off them.
Three questions keep coming up in the boardrooms we've sat in over the last six months: which fee tier are we actually on, do we move billing to the web, and how much real margin is on the table? Here's the practical answer.
On 1 January 2026, Apple replaced its EU commission structure with a modular fee model designed to comply with the Digital Markets Act. The flat rate is no longer a single number. It's a stack, and developers choose how much of it they want to pay based on which Apple services they actually use.
Stay on Apple's standard App Store and use external payment links to bypass StoreKit billing, and the stack lands at roughly 20% (5% CTC + 13% Tier 2 + 2% IAF on new users for the first six months). That's a meaningful drop from 30%, but the administrative overhead of calculating, reporting, and remitting modular fees is a new operational cost most finance teams haven't modelled.
Move to a third-party marketplace or Web Distribution and use external payment, and you pay 5% CTC plus your own payment processor (typically 2 to 5%). That's why, even with all the friction we'll get to, Web-to-App billing has become the dominant route for high-LTV publishers in Europe.
The UK isn't on the same timeline as the EU, but it's on the same trajectory.
In late 2025, the Competition and Markets Authority designated both Apple and Google with "Strategic Market Status" under the new Digital Markets Competition Regime. The CMA spent over six years on the underlying investigation and committed more than 100 dedicated staff to it, which gives a sense of the political weight behind the eventual rules. Steering measures, the formal mechanism for prohibiting anti-steering policies, are expected in the first half of 2026.
What this means in practice: a UK developer is still paying 15% to 30% on the standard global commission rate today. Within 12 months, that same developer will have a legal right to direct UK users to alternative payment outside the app, mirroring what's already live in the EU. The safe modelling assumption is a 15 to 25 percentage point cost reduction on UK revenue once the rules drop.
The question is whether your billing infrastructure is ready to use that on day one. In our experience, almost none are. Most UK app businesses we work with run a single subscription product through StoreKit or Google Play Billing, with no fallback web flow, no SCA-compliant card processor, and no test environment for non-IAP purchase events. Building that under regulatory pressure in three months is possible but expensive. Building it now, while the regulation is still pending, is cheaper.
The US picture is unsettled. Since the Epic v Apple ruling in April 2025, developers have been allowed to include external payment links in iOS apps without paying a commission on those transactions. In April 2026, the matter was remanded to the district courts to determine what counts as a "reasonable" fee. US developers can route to the web for free right now, but no one knows how long that lasts.
Japan implemented the Mobile Software Competition Act in late 2025, which forces Apple to allow third-party marketplaces. Both the Epic Games Store and AltStore are now live, but user uptake is the same problem it's been everywhere. Epic publicly targeted 100 million installs and reported 29 million achieved. Default platform inertia is much stronger than regulatory advocates expected.
The cross-jurisdiction takeaway: the legal right to bypass App Store billing is now normal. The user behaviour change to actually use those alternatives is much slower than the policy.
This is the part that hurts when you sit down to model 2026 unit economics.
Until recently, a finance team could quote a single "blended LTV" for a subscription product. CAC divided by LTV gave you the only number that mattered. That number now means almost nothing.
The same £10 monthly subscription, sold to four users in four countries on the same day, generates four different net margins. Apple's commission depends on the user's location, the distribution path, whether they're in the first six months of acquisition, and which Apple services the publisher buys. Google Play has its own structure. Payment processor costs vary by region. Local taxation differs.
Engineering teams now have to push regional context into nearly every part of the billing stack. A/B tests run per market, not globally. Pricing experiments account for fee variance, not just price elasticity. Analytics environments attribute revenue net of region-specific commission, or every cohort analysis is wrong. We've started calling this the "fragmented LTV problem" internally, and it's the single biggest reason finance teams ask for a Fractional CTO engagement at the moment. The maths is harder than it used to be, and few in-house teams have built for it yet.
Web-to-App billing isn't new. Spotify, Netflix, and Match Group have routed first-time subscriptions through web onboarding for years because the maths is obvious: a card transaction through Stripe or Adyen costs 2 to 5%, while in-app purchase costs 15 to 30%. What's changed in 2026 is that the user-experience cost has dropped sharply, and the publisher base willing to do it has expanded from streaming giants to almost every subscription-led app over £100k MRR.
The mechanics are straightforward. A user clicks an ad. They land on a web page. They sign up, choose a plan, enter card details. The web flow generates a one-time-use code or magic link. The user follows the link, opens or downloads the app, and authenticates against their newly-created account.
There are three reasons to do it:
Margin. A subscription product at £200k MRR on 30% commission gives up £60k a month. The same product on Web-to-App, paying 3% to Stripe and 5% CTC to Apple in the EU, gives up £16k. That's £528k a year that goes back into headcount, paid acquisition, or runway.
Pricing flexibility. App Store pricing is fixed in steps Apple defines. Web billing is whatever you want it to be. Run promotional pricing without waiting for App Store review, A/B test offer structures in real time, and price-discriminate by geography without rebuilding the SKU.
First-party data. App Store sign-ups give you what the user chose to share. Web sign-ups give you a verified email at the moment of intent. For most subscription businesses, that's worth more than the commission saving over time.
The cost is real, though. Web-to-App means owning your checkout, complying with regional tax (UK VAT, EU OSS, US sales tax across multiple states), handling SCA in Europe, dealing with chargebacks, and managing a separate fraud-prevention pipeline. None of these are trivial. In-house teams underestimate the work because StoreKit and Play Billing handle most of it invisibly.
A working Web-to-App flow has five components, in order
1. Acquisition routing. Paid ads and organic content land users on a web page, not the App Store. Biggest behavioural shift for marketing teams.
2. Checkout. Stripe Billing, Adyen, or RevenueCat's web SDK. RevenueCat gives you a unified abstraction across web, iOS, and Android billing; Stripe and Adyen are stronger for tax and dispute management.
3. Account and entitlement creation. When the web payment succeeds, create a user record, an entitlement record, and a one-time-use authentication artifact (magic link, JWT, six-digit code) that survives the context switch from browser to app.
4. App-side handshake. The app validates the artifact server-side and grants entitlement. This is also where you handle App Store review reality: Apple still requires you to offer in-app purchase as an option in many flows. The current pattern is to offer both, route 80%+ through web, and let the IAP option satisfy review without distorting the funnel.
5. Server-side entitlement sync. Users switch devices, reinstall, and cancel from either side. Entitlement state lives server-side, not in StoreKit or Play Billing receipts. Most teams that get burnt on Web-to-App get burnt here, because they tried to keep receipts as the source of truth and ended up with state divergence between web and native.
A small team can build this properly in eight to twelve weeks, including tax, SCA, and chargeback handling. We've shipped it on a Foresight App Gameplan discovery followed by a six-week implementation sprint, and the unit economics are usually clear by month four.
If you're running a subscription app, the decision tree is short.
Below £25k MRR: stay on App Store and Play Billing. The engineering investment doesn't recover in less than a year, and you're better off spending it on acquisition or product.
£25k to £100k MRR: model it. Break-even sits somewhere in this range and depends on churn rate, payment processor, and your share of EU users. We've seen products in this band where Web-to-App pays back in six months and others where the additional onboarding friction wipes out the saving.
Over £100k MRR: plan the migration if you haven't started. £100k MRR at 30% commission is £30k a month going to a platform you don't control. The same product at 8% blended cost is £8k. That's £264k a year of contribution margin, which buys an additional engineer or two and removes a structural risk from your business model.
If you're operating in the EU, this is no longer hypothetical. The DMA fee stack actively rewards publishers who route through alternative payment, and the user-experience friction is the lowest it's ever been because the App Store now contains explicit prompts directing users to external payment options.
The platform commission rate is now a function of where your users are, what services you buy from Apple or Google, and how willing you are to operate billing infrastructure yourself. There's no longer a single "App Store fee" you can plug into a spreadsheet.
For most subscription products with serious revenue, the answer in 2026 is hybrid: Web-to-App for new acquisitions in markets where regulation supports it, App Store IAP retained as a fallback for users who insist on it, and aggressive regional segmentation in the analytics and finance functions to keep LTV calculations honest.
Teams that figure this out first will compound a 15 to 25 percentage point margin advantage across the rest of the decade. Teams that wait will spend 2027 retrofitting billing infrastructure under regulatory pressure rather than commercial choice.
If you want a structured way to model this for your own product, the App Gameplan is built for this kind of strategic question: four weeks of discovery for a fixed £3,500 fee, with a board-ready answer at the end. Our analysis of the broader 2026 mobile app economy covers the wider monetisation context. For ongoing technical leadership rather than a one-off discovery, the Fractional CTO engagement covers the same territory at month-by-month cadence.
Written by Gareth Reese, Founder and CTO of Foresight Mobile. Gareth has overseen subscription monetisation work for app businesses across the UK and EU, including several Web-to-App migrations completed in early 2026.
