Apple’s old model may have had strict rules, but at least it had clarity. In 2026, the days of predictable 15% or 30% are over: after EU regulators enforced the Digital Markets Act (DMA), Apple replaced its flat commission with a layered fee system where the final cost is shaped by the payment path, user type (new vs. existing), and level of App Store services used. These factors can stack and push Apple’s take well beyond what most developers expect.
Apple also now formally allows external payments, but only under narrow frameworks. Depending on whether you link out, refer, or stay in-app, you’ll face different combinations of costs, rules, and reporting burdens.
So in the EU, there’s no single Apple fee anymore — since January 1, 2026, Apple has consolidated its EU terms into a single business model, but one with multiple fee components and trade-offs depending on how you distribute and how users pay. In this article, we break down how the new fee structure works, why alternative payment methods are not always cheaper in practice, and what materially changed for developers as the new system fully took effect in 2026.
How Apple App Store fees work in 2026: The old model vs the new reality
With the new modular fees system, the total cost for a developer can include different components depending on the chosen setup:
- access to App Store services (distribution, trust, tooling)
- the App Store’s role in user acquisition
- use of Apple’s core platform and technologies
On paper, there’s more flexibility than ever — in-app purchases, external payments, outbound links, different service tiers. In practice, each option adds another layer to the cost structure and changes the final outcome.
What used to be a straightforward pricing model is now a configuration puzzle where the final cost depends on your monetization setup, and the price of the wrong move has never been higher.
| Before (pre-DMA) | After (post-DMA, EU) |
|---|---|
| Single commission (15–30%) | Multiple components: Store Services, Core Tech, UA, Reporting |
| Predictable, fixed structure | Conditional and variable, based on business model |
| Same rules globally | Region-specific logic (EU ≠ US ≠ ROW) |
| Simple developer obligations | Complex reporting and compliance requirements |
| % fee easy to model and forecast | Effective cost hard to predict upfront |
How App Store fees changed in 2026
What triggered all this? In short: regulation.
The shift began in Europe, where the Digital Markets Act forced Apple to open up its ecosystem, allowing alternative payments, external links, and more flexible service tiers. But instead of replacing the old model with something simpler, Apple introduced a menu of tightly scoped options, each with its own pricing and constraints.
As a result, developers no longer choose whether to pay Apple — they choose what to pay for, and in which combination.
How that plays out in practice depends heavily on where your users are. The EU, US, and Japan now each operate under a different regulatory framework with different rules, fee structures, and trade-offs.
External payments don’t mean that App Store fees are gone
The introduction of external payments is often seen as a major win for EU developers. But can they flip the switch and return to clean, predictable economics? Not quite.
External payments aren’t an exit from Apple’s system, but an entry into a more complex configuration of it. What you gain in flexibility, you pay for in complexity:
- engineering overhead — separate payment flows, maintenance, fraud prevention, ongoing updates
- legal and compliance burden — local regulations, reporting, and liability for payments
- UX friction — leaving the native App Store flow, lower conversion rates, and trust concerns
So while the structure may look more open, the reality is that most choices come with hidden downsided that cancel out the savings.
Let’s look at how Apple EU App Store fees are structured now:
| Fee type | Rate | Applies to |
|---|---|---|
| Initial Acquisition Fee | 2% | First 6 months of payments from new users |
| Store Services Fee, Tier 1 | 5% | Basic distribution: no discovery, analytics, or auto-updates |
| Store Services Fee, Tier 2 | 13% | Full suite: discovery, analytics, updates, editorial |
| Core Technology Commission | 5% | On digital goods and services revenue, across all EU distribution paths |
In the most comprehensive setup, these components can stack, bringing Apple’s total take on external payments up to roughly 20%, compared to the standard 30% commission under in-app purchases. That said, most EU developers don’t hit the full rate: Small Business Program members pay a reduced 10% Store Services Fee (Tier 2) instead of 13%, bringing the stacked total closer to 17%.
To put this in context: per Apple’s own data, 88% of EU developers pay no commission at all, and 75% are on the Small Business Program with reduced rates. The “20% vs 30%” debate only matters for the minority operating on standard terms.
But even for that minority, the added engineering, compliance, and UX costs often erase or exceed that difference, so the savings exist mostly in theory. Apple’s November 2025 analysis found that more than 90% of developers who switched to alternative terms did not pass commission savings to consumers: prices stayed the same or increased.
Apple offers two technical paths for external payments in the EU:
- Alternative Terms Addendum allows apps to reference external offers without enabling direct payment actions. You can inform users about subscriptions or promotions available elsewhere, but cannot include clickable purchase links inside the app.
- StoreKit External Purchase Link Entitlement enables direct, clickable links to external payment destinations. This path offers more flexibility in directing users outside the App Store, but it also triggers the full fee stack and additional reporting obligations tied to external transactions.
Both options technically open the door to external payments, but neither offers true independence from the Apple ecosystem. As of January 1, 2026, both frameworks fall under Apple’s consolidated single business model for the EU. The old €0.50 per-install Core Technology Fee is gone, replaced by a 5% Core Technology Commission on digital goods and services revenue, which now applies across all EU distribution paths: App Store, Web Distribution, and alternative marketplaces.
The systemic consequence: Monetization is now fragmented by region
Even if you stick to in-app purchases, the landscape has changed: monetization rules now vary by region, and the same app no longer runs on a single economic model.
In the EU, developers face a completely new fee structure — layered, conditional, and tightly regulated under the DMA. More flexibility on paper, but each option adds complexity and cost that often cancel out the savings.
In the US, the situation is in legal flux. Since April 2025, developers can include external payment links without Apple charging any commission — a result of the Epic v. Apple court battle. A federal court later ruled Apple should be allowed to charge a “reasonable” fee, but didn’t define what that means. The case is now back in a lower court, and Apple is also taking it to the Supreme Court. Until the courts settle this, US developers can use external payment links commission-free, but how long that window stays open is unclear.
Japan is now a third regulated market: the Mobile Software Competition Act (MSCA) took effect on December 18, 2025, opening alternative marketplaces, third-party payments, and external link-outs. The mechanics differ from the EU — developers must show Apple’s IAP alongside any alternative payment option, and apps can only be distributed through approved marketplaces, not directly from the web. Alternative marketplaces are already live: Epic Games Store and AltStore launched in Japan in January 2026.
The UK is moving in the same direction but hasn’t arrived yet. Apple was designated with Strategic Market Status in October 2025, and the first CMA commitments — fairer app review, ranking transparency — took effect April 1, 2026. Commission fees are not addressed: UK developers still pay 15–30% as of today, with steering measures expected in H1 2026.
As a result, a single product is forced to maintain multiple parallel monetization stacks. Payment flows, fees, legal terms, and even UX decisions are now made region by region, rather than globally, and this changes how the business operates:
- Analytics — metrics aren’t directly comparable
- Processes — more exceptions, manual decisions, and coordination overhead
- Decision speed — every experiment requires regional context
How the new App Store fees and rules impact subscription apps
LTV becomes harder to predict
For subscription businesses, predictability has always been a strength, but in 2026, two users of the same product can bring in different revenue depending on region or payment flow.
Commissions, App Store fees, and operating costs now differ across regions and setups. As a result:
- subscription LTV is no longer stable or comparable across regions
- financial models need regional context
- forecasting errors grow with scale
Put simply, new Apple EU App Store fees and payment rules add more variables to how revenue plays out over time, making financial planning less certain and forcing more scenario-based thinking, even when the product remains the same.
Margin pressure on paid acquisition
Paid acquisition already ran on thin margins, and in 2026, they’re even thinner. CAC keeps rising, while Apple’s new fee structure adds complexity and delays clarity.
This creates a risky combination: higher user acquisition costs, delayed visibility into real net revenue, and monetization choices that reveal their real effect too late.
For subscription apps, these dynamics can gradually squeeze profitability and weaken the economics of key acquisition channels.
Slower experimentation inside in-app
As payment and compliance setups become more complex, the room to experiment shrinks. In practice, this leads to tighter constraints on pricing tests, less flexibility in combining offers, and longer cycles from idea to production.
Experimentation is still possible, but slower, harder to execute, and more expensive.
Operational overhead becomes permanent
What used to be a one-time setup has turned into an ongoing cost of doing business: legal reviews, compliance and local requirements, monthly payment reporting, and region-specific monetization configurations.
This change creates a lasting drag on speed and execution, which is especially painful for subscription teams that depend on fast iteration and operational efficiency.
Exposure to sudden rule changes
What’s allowed today might be blocked tomorrow. For apps operating across multiple regions, this volatility creates risks that can’t be mitigated by product work alone. It forces structural decisions about where monetization happens, how revenue flows are built, and how quickly the team can adapt when the rules shift.
How leading teams handle Apple’s new monetization rules: 3 strategies
Once the emotional response to Apple’s new fees fades, teams face a single question: how to adapt without hurting the business. The market is settling on a few strategic paths — none perfect, but each solving a different part of the equation.
1. Absorb fees
One way to handle Apple’s new fee structure is to accept it and rebalance your margins elsewhere. This usually means one of two things: raising prices to protect profitability which can hurt conversion rates, or absorbing the costs. To make up for it, teams have to improve retention, increase prices, add upsells, or cut acquisition costs just to keep the same level of revenue.
This is a strategy for survival, not for growth.
2. Localize monetization
You can go further and localize monetization by region: different paywalls, different payment paths, and different pricing and product decisions.
From an economic perspective, this can be effective. Operationally, it adds weight:
- more complexity in code and UX
- internal processes require special rules for different markets
- higher costs of support and mistakes
The approach is viable, but only for teams ready to handle the added complexity at scale.
3. Add web-based monetization
Teams are increasingly turning to the web monetization to take control of how offers are structured, how users pay, and how revenue is captured. This approach provides:
- direct payment methods outside the App Store,
- full control over pricing and paywall logic,
- faster testing and iteration,
- and long-term independence from platform constraints.
| Strategy | Description | Pros | Tradeoffs / Risks |
|---|---|---|---|
| Absorb fees | Keep in-app monetization, accept new Apple fees | Simple setup, stable UX | Lower margins, less flexibility, scaling limits |
| Localize monetization | Adapt pricing and flows by region | Higher relevance, can improve margins | High operational cost, harder to maintain |
| Add web layer | Shift pricing, billing, and experiments to the web | Faster iteration, more control, higher LTV | Requires infrastructure and clear data model |
Monetization strategies in 2026 side by side
What web2app brings to your monetization stack in 2026
1. Additional monetization layer to reduce dependency on a single channel
Instead of relying on in-app flows, you can shift acquisition, onboarding, billing, retention mechanics to the web, where you have more control and fewer constraints.
Case: Glam AI — more control + fewer store fees
A good example is Glam AI, a subscription-based AI app with relatively low ARPU. For products like this, a 30% store fee is a direct margin pressure. The team moved part of their monetization and experimentation to the web with FunnelFox.
The result: higher margins through reduced fees, faster onboarding tests, and more control without engineering work.
2. Faster pricing, offer, and billing experiments
One of the key advantages of web2app is speed. Web funnels make it possible to test pricing, onboarding, and offers without app review constraints, in-app mechanics, or long release cycles.
In the Glam AI example:
- the first web2app flow was launched in a single day
- new creative and onboarding hypotheses were tested in parallel
- new team members reached productivity within 1–2 weeks
In 2026, where fees are complex as never before and rules vary by region, this kind of operational agility becomes a core growth lever.
3. More control over offers and lifecycle moments
Web2app doesn’t stop at payments. It also lets you design key lifecycle moments as product decisions rather than accept them as system constraints.
For example, you can:
- build personalized paywalls with custom logic for regions, cohorts, or entry points
- set up automated payment retries and manage chargebacks with full control
- design custom cancellation flows to reduce churn
4. A hedge against platform and policy risk
Finally, web2app acts as a strategic hedge. When your entire monetization strategy depends on one store, one platform, and one set of shifting rules, you’re building on unstable ground.
Web2app gives you:
- an independent payment and pricing infrastructure you fully control
- a way to adapt faster to regional rule changes without rewriting your app
- long-term resilience by decoupling business logic from platform constraints
Here’s how web2app compares to other monetization setups in 2026:
| Capability / constraint | In-app | External payments | Web2app |
|---|---|---|---|
| Fees | Fixed 15–30% App Store commission | ≈10–20%, fragmented, still partially owned by Apple | 2-5%, depending on the payment provider |
| Speed of experimentation | Low — tied to app review cycles | Medium — needs legal/ops alignment | High — launch in hours, quick iterations |
| Setup complexity | Low | High — requires infra, legal, monthly reporting | Low — pre-built blocks, no code needed |
| Offer & billing flexibility | Limited by SDK & native flow | Depends on custom build | Full — pricing, paywalls, checkout, retries, cancellation logic |
| Control over user journey | Minimal — store-owned UX | Fragmented | Full control — acquisition to churn |
| Risk exposure (policy, fees) | High — fully coupled with App Store | High — subject to audits & rule shifts | Low — independent stack with fallback options |
Where FunnelFox fits in
FunnelFox helps mobile teams take control of their acquisition and monetization and brings together two key components: a web2app funnel builder for fast launches and experimentation, and a modern billing infrastructure for full control over subscriptions, payments, and revenue recovery.
With FunnelFox, you can reduce reliance on App Store flows and get more revenue without adding engineering overhead. Whether it’s launching region-specific offers, adapting pricing without release cycles, or managing churn with alternatives to cancellation, FunnelFox gives you the tools to act quickly and build a more profitable, controllable monetization stack.
In 2026, the winners are not those chasing the lowest percentage, but those who diversify payment flows instead of defaulting to in-app and preserve control points for pricing, billing, and experiments. And FunnelFox is how you get it.
Looking to diversify beyond in-app and protect your revenue? Book a demo.
Final takeaway: Structure beats percentage
The real question in 2026 isn’t how much Apple takes — it’s how your monetization is structured, and what that structure enables. Costs now show up not just in percentages, but also in slower launches, tighter margins, and fewer options to adapt.
That’s why strong teams don’t optimize for the lowest cut. They design for control, flexibility, and speed, and increasingly the web is where they build it.
