As of today, October 1, 2026, a developer in Berlin or Madrid can ship an iOS app without the App Store, charge for it with their own payment processor, and pay Apple a flat 5%. Under Apple’s revised EU Developer Program terms, introduced to comply with the Digital Markets Act, the Apple 5% commission, officially the Core Technology Commission, replaces the old per-install Core Technology Fee. iClarified, BetaNews and Subscription Insider all report that the initial acquisition fee and the store services fees are gone too. On paper, that’s a big gap compared with the roughly 20% reported for using alternative payments while staying inside the App Store.
A 15-point gap gets founders’ attention. We build Flutter apps with native Swift and Kotlin layers for a living, so our first question is about the other side of the ledger: what does it cost in engineering to collect that 15%? The answer is more than most pitch decks assume. For some apps it’s still clearly worth it.
What the Apple 5% commission actually changes
The old Core Technology Fee was the main reason almost nobody left the App Store. It charged per install, above a threshold, whether or not the user ever paid you. A free app that went viral could owe Apple money it never earned. A flat commission on revenue fixes that. Your cost to Apple now grows with what you earn, not with how many people download the app.
What hasn’t changed is that Apple still sits between you and the device. Apps distributed outside the App Store in the EU still go through notarization. That’s Apple’s automated and human review for security and basic integrity, just without the full App Review content rules. You’re still in the Developer Program, still signing with Apple-issued certificates and still subject to Apple’s terms. Leaving the App Store doesn’t mean leaving Apple. It means taking on the work the App Store used to do for you.
The engineering bill nobody puts in the spreadsheet
Here’s the work that shows up once a team commits to distributing outside the App Store, whether through an alternative marketplace or directly from their own website.
Payments become your problem, end to end
StoreKit handles tax, refunds, subscription renewals, grace periods, family sharing and fraud for you. Replace it with Stripe, Adyen or Paddle and you have to build all of that yourself. You need an entitlement service that decides who has access to what. You need webhook handling for failed renewals, a VAT approach that works across 27 member states, and a refund and chargeback process a support person can actually run. Doing this properly is real backend development: an API, a database schema for subscriptions and entitlements, an admin dashboard for support, and audit logs. It isn’t a single SDK call.
Two builds, not one
In a Flutter app the Dart business logic mostly doesn’t care. The native layer does. You’ll have an App Store build that still uses StoreKit for non-EU users and an EU-distributed build with a different payment path, different entitlements and possibly different update behaviour. That means build flavors, storefront-aware feature flags, and Swift code that has to be tested both ways. Most importantly, you need a second release lane in your CI/CD pipeline, with its own signing, notarization submission and rollout controls.
Updates and distribution
The App Store gives you automatic updates, staged rollouts and crash reporting that users never think about. If you distribute through an alternative marketplace, you depend on that marketplace’s update mechanism. If you distribute from your own website, eligibility requirements apply and you run the download experience yourself. Either way, a bad release is harder to recall. And if 40% of your EU users are two versions behind, your API has to support all of those versions.
Discovery and trust
This one isn’t engineering, but it lands on engineering. You have to replace App Store search traffic with your own marketing. And the extra install screens iOS shows for apps from outside the App Store cost you users at exactly the step where you can least afford to lose them.
Which apps should actually switch
Our honest read: the 5% commission turns leaving the App Store from an expensive gamble into a reasonable choice, but only for a fairly narrow set of apps.
- Strong candidates: subscription SaaS or content apps with a large EU paying base, an existing web billing system (many already sell on the web), and a brand people search for by name. For these teams most of the backend already exists, and the savings grow with every renewal.
- Worth modelling: mid-sized apps with meaningful EU revenue and a team that already runs a solid release pipeline. Do the maths on a year of savings against the engineering time and ongoing maintenance of a second lane. Remember that maintenance cost never goes away.
- Stay put: early-stage products, MVPs, apps that depend on App Store discovery, and apps where most revenue comes from outside the EU. Rebuilding the payment stack will cost more than you save, and it pulls engineers away from the product at the stage where the product matters most.
There’s also a middle path people overlook. Stay in the App Store, but design your software architecture so payments sit behind a clean interface, with entitlements on your server instead of spread through the client. Then switching later is a configuration change plus some new work, not a rewrite. We think that’s the right default for most teams right now, because EU rules have changed more than once already and may change again.
The real question is architectural
The companies that benefit from today’s change won’t be the ones that rush to leave the App Store. They’ll be the ones whose apps were already built so that the payment provider, the release channel and the distribution method are replaceable parts. If you have to rip StoreKit calls out of a dozen screens, the migration will cost you more than the commission you’re trying to avoid.
At orithLabs we’ve shipped Flutter apps like Crumb Count and Kompete with native Swift and Kotlin layers, and this is the kind of decision we like working through with the founders who have to live with it. If you’re weighing EU distribution, or just want to know whether your current codebase could handle a second payment path without a rewrite, we’re happy to look at it with you and give you a straight answer, including if the answer is “not yet.”