UK Mobile App Development 2026: What the CMA's Apple and Google Intervention Means for Your App

For fifteen years the economics of building a UK mobile app had one fixed constant: if you sold anything through the app, Apple or Google took up to 30 percent, and there was no lawful way around it.

That constant is being dismantled, and most UK product teams have not registered it.

On 22 October 2025 the Competition and Markets Authority designated Apple and Google as having strategic market status in their mobile platforms — the first such designations under Part 1 of the Digital Markets, Competition and Consumers Act 2024. Apple's covers iOS, iPadOS, the App Store and Safari. Google's covers Android, the Play Store and Chrome.

Since then: commitments from both firms took effect on 1 April 2026, and on 30 June 2026 the CMA proposed steering conduct requirements on each — rules that would let UK developers direct customers off the app stores to complete transactions. That consultation closed on 28 July, with a decision expected later this year. Separately, the CMA opened a call for evidence on opening the iPhone's NFC hardware to third parties.

The CMA has stated it expects any steering fee to be lower than current app store charges, with the saving passed to UK customers or reinvested by developers.

If your app takes payment, your unit economics are a live regulatory question. This guide covers what has changed, what is still pending, and — the part nobody is writing — what to build now so you can act when the position settles.

This is an engineering and commercial guide, not legal advice. Confirm all positions with qualified counsel before they drive build or commercial decisions.

The timeline

Two clarifications that matter legally.

SMS designation is not a finding of wrongdoing. It means the CMA found substantial, entrenched market power and a position of strategic significance. Only firms with UK turnover above £1 billion or global turnover above £25 billion can be designated.

The April 2026 commitments are not formal conduct requirements. They are voluntary commitments offered by Apple and Google, sitting outside the Act's express statutory commitment mechanisms at this stage. Conduct requirements under section 19 are the operative tool, and they must be proportionate to one of three statutory objectives: fair dealing, open choices, or trust and transparency. Failure to honour commitments could lead the CMA to impose formal requirements instead.

The 30 percent question

The CMA found that Apple and Google hold an effective duopoly, with 90 to 100 percent of UK mobile devices running one of the two platforms. Its investigation identified commissions on in-app purchases of as much as 30 percent, alongside unpredictable app reviews and inconsistent search rankings.

For a UK app business, that commission is frequently the difference between a viable unit economic and an unviable one. A subscription app at £9.99 per month loses up to £3 of it before any other cost. At scale that is the entire marketing budget.

What steering would change. The proposed conduct requirements would remove restrictions preventing UK developers from steering customers outside the app stores to complete transactions. Google has already announced global Play Store terms permitting steering subject to restrictions, with associated fee changes, effective in the UK from 30 June 2026.

What is still open. The price. The CMA expects any steering fee to be lower than current app store charges, but "lower than 30 percent" covers a wide range, and the specifics will determine whether steering is commercially worthwhile or merely permitted. The CMA has said it will assess the impact of Google's announced changes during the next phase of its work.

The honest position for planning: do not build a financial model that assumes fees drop to near-zero. Do build a system that can switch payment routes without a rewrite, because the probability of some change is now high and the cost of being unable to act on it is real.

Steering and your payment architecture

This is the engineering consequence, and it is more involved than adding a link.

A payment abstraction layer. Your app should not call StoreKit or Google Play Billing directly from feature code. It should call an internal payments interface that can route to in-app purchase, to an external web checkout, or to both depending on jurisdiction and configuration. Teams with billing calls scattered through the codebase cannot switch routes in a quarter.

Entitlement decoupled from purchase channel. What a user is entitled to must be a server-side fact, independent of where they paid. If entitlement is derived from an App Store receipt, a user who pays via web has no entitlement. This is the single most common blocker to steering readiness, and it is a data model problem rather than a payments problem.

Server-side receipt and subscription state. One source of truth reconciling App Store, Play, and direct payments into a single subscription record. Without it, a user who switches routes appears twice, or not at all.

Jurisdiction-aware configuration. Steering permissions are UK-specific. Your app will need to behave differently for UK users than for others, driven by configuration rather than by a separate build.

Compliance with the display rules. Any external checkout is a consumer-facing transaction subject to UK consumer law — including the DMCC drip pricing prohibition requiring total price displayed upfront. Moving payment off-platform moves the consumer protection obligation onto you. We cover what that means in practice in our UK eCommerce and DMCC guide.

This kind of restructuring is a normal part of how we approach mobile app development for UK clients — not because we anticipated this specific ruling, but because coupling entitlement to a single store's receipt has always been an architectural liability. The regulatory change has simply made the bill payable.

NFC access and what it opens up

On 30 June 2026 the CMA published a call for evidence on key issues relating to NFC access on iOS, seeking developer views on design elements including the technical method by which access should be provided.

Why this matters. NFC is the hardware that makes contactless payment work. On iOS it has been effectively reserved, which is why a UK bank's app cannot behave like a contactless card in the way Apple Pay does. Opening it would let fintechs, transit operators, retailers and access-control providers build directly against the hardware.

What to prepare if this affects you:

Do not build against an assumed API. The technical method is precisely what the CMA is consulting on. Anything you build now against a guessed interface is speculative work.

Do get your credential and key management right. Whatever the access method, provisioning and securing payment credentials on device is the hard part, and it is method-independent. That work is not wasted.

Do model the commercial case. If NFC opens, is a first-party contactless experience worth building, or is Apple Pay integration still the right answer? For most retailers the answer will remain Apple Pay. For banks and transit operators it may not.

For UK fintechs this connects directly to the wider regulatory picture — safeguarding, APP fraud and the payments perimeter — which we cover in our London fintech development guide.

Interoperability requests

Among the April 2026 commitments: Apple will allow developers to request interoperability access to features and functionality within iOS and iPadOS, and consider those requests fairly and objectively.

What this means practically. There is now a defined route to ask for access to platform functionality that was previously simply unavailable, with a commitment that requests will be assessed on stated criteria rather than disappearing.

How to use it. If your product has been compromised by an iOS limitation — a background execution constraint, a hardware access restriction, a system integration point — document the specific requirement and the user benefit and submit it. The process is new and the outcomes are unproven, but the cost of asking is low and a documented refusal is itself useful evidence for the CMA's ongoing work.

Realistic expectation: this is a request mechanism with a fairness commitment, not an entitlement. Plan your product on what exists today and treat any granted access as upside.

App review and ranking

The commitments also cover app review, app ranking and use of data — areas where the CMA found unpredictable reviews and inconsistent search rankings.

The engineering consequence is modest but real. More predictable review processes make release planning more reliable, which matters most for teams shipping frequently or operating under their own regulatory deadlines. If you have historically padded release schedules to absorb review uncertainty, that padding may shrink.

Do not over-adjust yet. These are commitments with monitoring, not guarantees, and they took effect only in April.

Build for optionality

The strategic point of this article.

The UK mobile regulatory position will not settle this year. The steering decision is pending, NFC is at call-for-evidence stage, and the browser and web app consultation is a separate strand. Building for a specific outcome is speculative. Building so that you can act on any outcome is not.

Four properties worth having:

None of these is exotic. All are good architecture independent of regulation. The regulatory change simply raises the cost of not having them from "mild inconvenience" to "cannot respond to a material change in your own unit economics."

Timeframe: for a mid-sized app, this restructuring is typically six to twelve weeks. Doing it now, deliberately, costs a fraction of doing it against a commercial deadline once the steering position is confirmed.

Native, cross-platform, or web

The CMA's interventions shift this calculation slightly.

Native remains right where you need deep hardware access, best-in-class performance, or platform-specific capability. If NFC access opens, native becomes more compelling for payments and access-control products specifically.

Cross-platform — React Native, Flutter — remains the right default for most UK businesses. The payment abstraction described above is arguably easier here, because you are already building an abstraction layer over two platforms.

Web is the interesting one. Open Web Advocacy and others have argued that if browsers and web apps can compete fairly on mobile operating systems, the web becomes a genuine alternative to app stores — open, interoperable, and free of platform fees. The CMA's roadmap indicated a consultation covering browsers, browser engines and web apps.

Practical advice: do not restructure around a web-first strategy on the strength of a consultation. But if you were already weighing a progressive web app for part of your product, the direction of travel is mildly favourable, and the fee exposure argument is stronger than it was a year ago.

Cost, timeline and team shape

Rates vary substantially by location — mobile sits close to the general developer median for cross-platform work and above it for senior native specialists, particularly iOS, where the UK pool is genuinely thin. Full detail in our UK developer day rate index.

The row teams underestimate is the backend engineer. Mobile products fail on server-side subscription and entitlement handling far more often than on client code, and the steering changes make that layer more important rather than less.

Regionally, Manchester offers strong mobile and commerce engineering at roughly 35 to 40 percent below London rates, with a deep pool from the region's consumer app and retail sector.

Six mistakes in UK mobile builds

1. Billing calls scattered through feature code. The thing that makes you unable to respond when the fee position changes.

2. Entitlement derived from store receipts. A user who pays anywhere else has no access. Server-side entitlement fixes this and should be the default regardless.

3. Building against an assumed NFC API. The technical method is under consultation. Speculative integration work.

4. Treating external checkout as purely a payments change. Off-platform payment brings UK consumer law obligations with it, including total price display.

5. Underinvesting in the backend. Subscription reconciliation across App Store, Play and direct payment is where mobile products actually break.

6. Restructuring around a consultation outcome. The steering decision is pending and the fee level is unknown. Build for optionality, not for a predicted result.

Frequently asked questions

What is strategic market status and why were Apple and Google designated? Strategic market status is a designation under Part 1 of the Digital Markets, Competition and Consumers Act 2024, applied where the CMA finds substantial, entrenched market power and a position of strategic significance. Apple and Google were designated in their mobile platforms on 22 October 2025, the first such designations under the Act. Apple's covers iOS, iPadOS, the App Store and Safari; Google's covers Android, the Play Store and Chrome. Designation is not a finding of wrongdoing.

Will UK app developers be able to avoid the 30% app store commission? Possibly, and the position is not settled. On 30 June 2026 the CMA proposed steering conduct requirements that would let developers direct customers off the app stores to complete transactions. The consultation closed on 28 July 2026 and a decision is expected later in the year. The CMA has said it expects any steering fee to be lower than current app store charges, but the level has not been set.

What did Apple and Google commit to in April 2026? Commitments taking effect from 1 April 2026 cover clearer app store rules and fairer treatment for UK developers, including in relation to app review, app ranking and use of data, and — for Apple — a route for developers to request interoperability access to iOS and iPadOS features, to be considered fairly and objectively. These are voluntary commitments rather than formal conduct requirements under the Act.

Is Apple opening NFC access on iPhone in the UK? It is under consideration. On 30 June 2026 the CMA published a call for evidence on key issues relating to NFC access on iOS, seeking developer views including on the technical method by which access should be provided. No access method has been confirmed, so building against an assumed API would be speculative.

How should I prepare my app for possible steering rules? Abstract payments behind an internal interface rather than calling store billing from feature code, make entitlement a server-side fact independent of payment channel, maintain unified subscription state across all payment routes, and make UK-specific behaviour configuration-driven. This restructuring typically takes six to twelve weeks for a mid-sized app.

Does moving payment outside the app store create other obligations? Yes. An external checkout is a consumer transaction subject to UK consumer law, including the DMCC Act's requirement to display total price upfront. Moving payment off-platform moves the consumer protection obligation onto you.

Should I build native or cross-platform for the UK market in 2026? Cross-platform remains the right default for most UK businesses. Native is justified where deep hardware access, best-in-class performance or platform-specific capability is required — and would become more compelling for payments and access-control products if NFC access opens.

How much does mobile app development cost in the UK? A cross-platform MVP with a single payment route typically runs £80k to £220k over three to five months. A full cross-platform product with subscriptions and integrations runs £180k to £450k. Native iOS and Android with complex hardware use runs £300k to £700k. A payment abstraction and entitlement restructure on an existing app runs £40k to £120k.

The short version

The UK is the first major jurisdiction where a regulator has moved this directly on mobile platform economics, and the position will keep moving through the rest of 2026.

Three things worth doing now.

Audit how coupled your app is to store billing. If entitlement comes from a receipt and billing calls sit in feature code, you cannot act when the fee position changes — and that is the whole point of the change.

Do the payment abstraction work deliberately, now. Six to twelve weeks on your schedule beats the same work against a commercial deadline.

Do not build against outcomes that have not landed. Steering is pending, NFC is at call-for-evidence stage, browsers are a separate strand. Build for optionality.

The underlying architecture — payments abstracted, entitlement server-side, subscription state unified — was correct before any of this. The regulation has just made the cost of skipping it visible.

About Akoode Technologies

Akoode Technologies is an AI and software development company headquartered in Gurugram, India, with a US office in Oklahoma, working with clients across the UK, USA and India. We build mobile applications, custom software, AI and machine learning systems and eCommerce platforms for startups, SMEs and enterprises across 15+ industries, with 180+ projects delivered globally and clients across the UK, including London and Manchester.

Verified ratings: 4.9 out of 5 on Google across 110 client reviews, and 5.0 out of 5 on GoodFirms.

If you want a read on how exposed your app is to the fee change — and how long the restructure would actually take — book a call.

This article is an engineering and commercial guide, not legal advice. Regulatory positions reflect published CMA materials and legal commentary as of August 2026. The steering conduct requirement decision and NFC access position remain pending and may change. Confirm all positions with qualified counsel before they drive build or commercial decisions. Cost bands are indicative planning figures, not quotations.