TL;DR: The UK's Competition and Markets Authority (CMA) has stated that developers need access to key iOS and iPadOS features to build innovative products and services, so UK consumers do not miss out. But Apple’s proposed interoperability commitments are far too weak to deliver that outcome. The CMA has the power to impose effective and enforceable interoperability obligations on mobile operating system gatekeepers under the UK's Digital Markets, Competition and Consumers Act 2024 (DMCCA), it just doesn’t appear to be using them.
How you can help!
We welcome views on Apple’s proposed commitments in relation to interoperable access requests. [...]
We welcome feedback from stakeholders on the approach as set out in this document, and on the respective proposed commitments provided by both Apple and Google individually, as well as on both approaches in the round. In particular, we welcome views on the metrics proposed to support in monitoring the delivery and effectiveness of the commitments. If you wish to provide such views, please get in touch at mobilesms@cma.gov.uk by 5pm on 3 March 2026. Should any aspects of your views be confidential, we ask that you also provide a non-confidential version of your views alongside. CMA - Proposed Commitments - Call for Evidence
(emphasis added)
The CMA has invited stakeholders to submit views on Apple’s proposed commitments. Because API access is essential to a competitive and fair mobile ecosystem, we encourage non-profits, developers, businesses that operate in the UK, and UK consumers to share their perspectives.
In particular, we ask respondents to address:
Whether a general interoperability requirement should be imposed on Apple and/or Google in relation to their mobile operating systems?
Whether Apple’s proposed commitments are likely to deliver fair and effective API access for businesses operating in the UK, and whether they would end Apple’s self-preferencing of APIs?
Any personal experiences where APIs or equivalent platform functionality were denied or made unavailable to third-parties.
Whether an interoperability requirement of this kind would lead to greater growth and innovation in the UK?
What Happened?
Apple claims it's built a walled garden, but they won't let you leave. That's not a walled garden, it's a walled prison. Interoperability gives users the keys they need to come and go as they please. Cory Doctorow
In late 2025, OWA arranged a meeting between the CMA, sci-fi author and world-renowned expert on interoperability Cory Doctorow, Y Combinator head of policy Luther Lowe, global policy counsel at the Coalition for App Fairness Gene Burrus, and ourselves. The purpose was to explain why adding a broad interoperability requirement, similar to Article 6(7) of the EU’s Digital Markets Act (DMA), to Apple and Google’s code of conduct is essential for fair and effective competition on mobile operating systems. We were concerned this requirement appeared to be missing from the recent SMS (Strategic Market Status) investigation.
On February 10th 2026, the CMA announced that Apple and Google had proposed commitments on app certainty and interoperable access. We were especially pleased that the CMA adopted the goal of requiring Apple to share functionality in iOS and iPadOS.
Furthermore, it is important that developers have interoperable access to key functionality in Apple’s iOS and iPadOS. Without the ability to access these enabling functions, UK developers cannot create the full range of innovative products and services that they would do otherwise, and UK consumers miss out as a result. CMA - Proposed Commitments - Call for Evidence
(emphasis added)
We consider commitments could prove a swift, effective and proportionate way of addressing these specific concerns and we have worked with Apple and Google to interrogate and further develop their proposals. Our goal is to deliver meaningful outcomes to UK consumers and businesses, and we seek to deliver these outcomes in the most effective and efficient way for the specific circumstances, using the full range of tools available to us. CMA - Proposed Commitments - Call for Evidence
(emphasis added)
What has Apple committed to in the UK
Apple has committed to providing a feedback channel for developers to make interoperability requests. Apple has committed to publicly publishing some annual statistics on this process and a statement that it is abiding by these commitments. Apple has also committed bi-annually reporting more detailed data on the request system to the CMA.
This all sounds great, until you dig into the details, and at which point multiple problems that invalidate the whole proposal become apparent.
Today’s announcement is unfortunately a gift to Apple and Google. Allowing dominant gatekeepers to set the terms of their own restraint— after years of abusing market power and dodging enforcement, including a US contempt finding against Apple — will not deliver real competition. Coalition for App Fairness
(emphasis added)
Given the highly dubious track record of these tech giants, we would question whether these voluntary commitments are really worth the paper they are printed on. News Media Association
(emphasis added)
Four years on from the publication of the mobile ecosystems market study report, the CMA isn’t actually proposing any formal conduct requirements at all. They are proposing to accept non-binding commitments from Google and Apple that they will run a fairer app review process and be fairer in how they rank apps in the app stores. Oh, and Apple is promising to consider interoperability requests fairly and objectively 😉 🤞
[...]
This is disappointing. It’s an outcome so weak that the possibility is not even mentioned in the CMA’s 220-page guidance document published in December.
It’s also deeply misleading for the CMA to describe these promises as “commitments”, which is a word with actual legal meaning (and legal enforceability) in the pro-competitive interventions process and in competition enforcement cases under the Competition Act. Tom Smith Former Legal Director at the CMA
(emphasis added)
Five years after the CMA began investigating competition in the mobile ecosystem, this feels pretty weak to me. [...] Quite why the CMA does not aim to create a default interoperability requirement is beyond my small brain to fathom. But even within this very lightweight framing, Apple’s commitments are hugely underwhelming [...] Hang on: Apple can deny a competitor access to an existing iOS service, if it decides there won’t be enough user uptake? Then why did it implement it in the first place? If access to a feature, that Apple has already implemented and uses in its own products, doesn’t align “with Apple’s platform priorities”, why did they add that feature to their platform? Bruce Lawson
(emphasis added)
Apple Isn’t Committing to Sharing Anything
The first and biggest problem is that the proposal is layered with multiple ways of Apple not having to share any API it doesn’t want to, regardless of the circumstances. Nowhere in the proposed commitment does Apple commit to sharing the operating system features and functionalities used by its own apps, services and ancillary devices. It doesn’t even commit to this subject to security, privacy or other conditions.
Just in case there was any doubt, Apple states:
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or not it will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities. Apple Proposed Commitments
(emphasis added)
Apple’s “commitment” boils down to this: Apple will decide, case by case, what access it grants and to whom. It reserves the right to keep certain APIs or higher quality versions of APIs for its own apps, devices, and services. In effect, Apple is promising only that it will do what it wants.
Apple also concedes it may withhold API access where granting it could undermine its commercial strategy. Put plainly: if enabling an API would help someone compete with Apple, that alone can be a reason not to provide it.
UK Developer Program Only
Eligibility to make these interoperability requests is limited to “developers [...] whose account membership with the Developer Program is registered in the UK”. This does not cover a significant majority of the apps and devices that are available to UK users via Apple’s app store. Many apps and devices that UK users rely on are developed by entities whose developer program is registered outside the UK. Apple needs to expand this to all developers and vendors that provide apps, services, or connected devices that work with iOS devices used by UK users, regardless of where the developer account is registered.
Broad and Gameable Rejection Criteria
Apple's assessment criteria are broad, subjective, and allow denial of any request.
They include:
- “expected user and developer uptake”
- “alignment with Apple’s platform priorities”
- “potential implementation costs”
- “potential impact on user experience, performance/battery, security, safety, privacy, integrity, and accessibility”
- “potential impact on Apple’s intellectual property rights”
With these criteria, Apple can trivially deny any request and still be in full compliance with this policy.
Apple Allows For Billing for API Access
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or not it will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities. Apple Proposed Commitments
(emphasis added)
Apple has inserted a clause allowing it to charge for API access. This could be a powerful mechanism for Apple to block fair competition with its own apps. We argue here in extensive detail why API access should be free, something that the DMA already mandates.
Imagine if Microsoft charged developers for access to basic Windows APIs such as Bluetooth, so that an app had to pay Microsoft simply to use system functionality on devices that users already own. That would be an obvious barrier to competition and would clearly be ridiculous, but is the very thing that Apple is proposing here.
Weak Deadlines and Lack of Transparency
Apple will endeavour to provide developers with an update on the status of their requests within four weeks of receiving them. [...]
Apple will inform developers of the outcome of its review of their requests, and the associated reasoning for this outcome. [...]
Apple will inform developers generally about forthcoming changes to iOS and iPadOS, including those resulting from eligible requests, in its beta releases. Apple Proposed Commitments
Apple states that it will “endeavour” to provide developers with an update on the status of their requests within four weeks, inform them of the outcome and reasoning, and communicate forthcoming platform changes through beta releases.
These are weak, non-binding commitments. Apple is not required to meet the four-week timeframe, only to attempt to do so. Developers are given no certainty about whether a request has been approved, when any approved changes will be implemented, or even whether implementation will occur at all. The commitments also impose no obligation on Apple to publish in advance what changes it plans to make in response to a successful request, nor to provide a concrete delivery timeline.
Given that persistent delays were a primary reason the European Commission initiated specification proceedings against Apple, deadlines are an important requirement in any effective interoperability obligation.
How Apple can comply and still do nothing
Apple could fully comply with this proposal while effectively changing nothing.
The core problem is that Apple could simply deny every request for access to key APIs from companies that compete with Apple’s own apps, accessories, and services, and still claim it is following the rules. In practice, this turns the proposal into a blank cheque that lets Apple avoid sharing APIs indefinitely, with no real consequences. The CMA’s interventions are meant to drive real change but they risk failing in their aim of ensuring interoperable access to essential iOS and iPadOS functionality, leaving UK developers unable to build the full range of innovative products and services and UK consumers worse off through reduced choice and weaker competition.
Apple's poor compliance with the EU’s far more stringent Digital Markets Act does not bode well for such a process. The EU Commission has already had to run a specification proceeding against Apple to force upon them a more stringent process, with deadlines. A proceeding that is now the target of a lawsuit from Apple.
That makes it very hard to believe this entirely voluntary proposal with no hard requirements to share anything will deliver the outcomes the CMA says it wants.
By contrast, the EU approach has already led to tangible gains for UK consumers and UK businesses, including USB-C charging for iPhones, support for game emulators, NFC access for third-party payments, the new default apps page, and most recently cross-platform AirDrop support.
Given the powers available under the DMCCA and the SMS designations of Apple and Google, the CMA can do far better than this. Endorsing this proposal would effectively give regulatory cover to a process that offers no meaningful benefit for UK businesses or consumers. Worse, it could delay the introduction of measures that would actually be effective.
Why an Interoperability Requirement is Needed
Interoperability is the foundation of effective competition in digital markets. On mobile platforms, access to operating system features and application programming interfaces (APIs) determines what third-party developers can build, how well their products perform, and whether they can compete on equal terms with the platform owner’s own apps and services. Without meaningful interoperability, competition is constrained not by innovation or consumer preference, but by technical restrictions imposed by the gatekeeper.
Apple’s control over iOS gives it the power to decide which capabilities are available to others and under what conditions. As the Competition and Markets Authority has previously observed:
Apple’s control over iOS also allows it to determine the ‘rules of the game’ by determining which APIs are made available to third parties and on what terms. This is important as the functionality of native apps and browser engines on a mobile device is determined by which APIs they can access CMA - Mobile Ecosystems Market Study
(emphasis added)
Poor Interoperability Enables Lock-In
Interoperability also plays a crucial role in reducing user lock-in. When devices, apps, and services work only within a single ecosystem, consumers face significant costs when attempting to switch platforms. Data may not transfer easily, accessories may become unusable, and familiar services may lack equivalent functionality elsewhere.
This lock-in weakens competitive pressure on the dominant firm. If users cannot realistically leave, the firm has less incentive to improve products, lower prices, or respect consumer preferences. Developers likewise become dependent on the platform for distribution and functionality, making them vulnerable to unilateral changes in rules, fees, or access.
Interoperability via middleware would reduce lock-in for Apple’s devices. Lock-in is a clear reason for Apple to block interoperability, as can be seen in this email exchange where Apple executives dismiss the idea of bringing iMessage to Android.
The #1 most difficult [reason] to leave the Apple universe app is iMessage ... iMessage amounts to serious lock-in Unnamed Apple Employee
(emphasis added)
iMessage on Android would simply serve to remove [an] obstacle to iPhone families giving their kids Android phones ... moving iMessage to Android will hurt us more than help us, this email illustrates why. Craig Federighi - Apple's Senior Vice President of Software Engineering
(emphasis added)
Or this now infamous exchange between Tim Cook and Vox Media's LiQuan Hunt:
Not to make it personal, but I can't send my mom certain videos, or she can't send me certain videos Vox Media's LiQuan Hunt
Buy your mom an iPhone Tim Cook
The DOJ took a dim view of this conduct in its complaint against Apple:
Apple recognizes that its conduct harms users and makes it more difficult to switch smartphones. DOJ Complaint against Apple
Security
Apple will often claim when they reserve a feature for itself or limit interoperability that the primary purpose is not to increase lock-in or Apple’s own profits, but rather to protect its own users.
Tie all of our products together, so we further lock customers into our ecosystem
Steve Jobs
(emphasis added)
I think this is all pretty simple, [Apple's] iBooks is going to be the only bookstore on iOS devices. We need to hold our heads high. One can read books bought elsewhere, just not buy/rent/subscribe from iOS without paying us, which we acknowledge is prohibitive for many things. Steve Jobs
(emphasis added)
I just watched a new Amazon Kindle app ad on TV.
It starts with a woman using an iPhone and buying and reading books with the Kindle app. The woman then switches to an Android phone and still can read all her books. While the primary message is that there are Kindle apps on lots of mobile devices, the secondary message that can’t be missed is that it is easy to switch from iPhone to Android.
Not fun to watch. Phil Schiller
(emphasis added)
This is now being viewed increasingly sceptically by both regulators around the world and the general public.
That is not to say that there are no security issues related to sharing APIs, but rather that Apple should be restricted to only strictly necessary security measures which Apple can prove are justified and proportionate.
As the DOJ noted in their complaint against Apple:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests. DOJ Complaint against Apple
Lessons from History: The DOJ vs Microsoft
In many ways, history is repeating itself. In the late 1990s, Microsoft grew increasingly concerned that middleware could erode the Windows “applications barrier to entry”. If developers could target middleware APIs instead of Windows APIs, they could more easily port applications across operating systems, weakening the lock-in that made Windows so hard to displace.
Middleware technologies, as previously noted, have the potential to weaken the applications barrier to entry. Microsoft was apprehensive that the APIs exposed by middleware technologies would attract so much developer interest, and would become so numerous and varied, that there would arise a substantial and growing number of full-featured applications that relied largely, or even wholly, on middleware APIs. The applications relying largely on middleware APIs would potentially be relatively easy to port from one operating system to another. The applications relying exclusively on middleware APIs would run, as written, on any operating system hosting the requisite middleware. So the more popular middleware became and the more APIs it exposed, the more the positive feedback loop that sustains the applications barrier to entry would dissipate. Microsoft was concerned with middleware as a category of software; each type of middleware contributed to the threat posed by the entire category. At the same time, Microsoft focused its antipathy on two incarnations of middleware that, working together, had the potential to weaken the applications barrier severely without the assistance of any other middleware. These were Netscape's Web browser and Sun's implementation of the Java technologies. US vs Microsoft - Finding of Fact
(emphasis added)
One method of preventing third-party middleware from enabling this was simply to deny them access to the APIs they needed:
Microsoft's senior executives understood that if they could prevent this version of Navigator from presenting alternatives to the Internet-related APIs in Windows 95, the technologies branded as Navigator would cease to present an alternative platform to developers. US vs Microsoft - Finding of Fact
(emphasis added)
In 1998, the DOJ filed a suit against Microsoft alleging that the company had unlawfully maintained its monopoly by suppressing competition in web browsers on Windows. Central to the case were both contractual restrictions imposed on PC manufacturers and technical measures that made it difficult for users to remove Internet Explorer or use other programs such as Netscape and Java.
The final judgement imposed an affirmative interoperability obligation: Microsoft had to disclose the Windows interfaces that its own middleware relied on so that third-party developers could build competing middleware that interoperated with Windows on comparable terms.
Microsoft shall disclose [...] for the sole purpose of interoperating with a Windows Operating System Product [...] the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. [...] In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner. US vs Microsoft - Final Judgement
(emphasis added)
Microsoft also faced unusually high stakes during the litigation. In 2000, the district court ordered a breakup remedy, a decision that was later overturned on appeal, but it made the consequences of continued non-compliance genuinely alarming to Microsoft. It was under this backdrop that Microsoft sincerely complied with the requirements.
Gene Burrus who spent 15 years at Microsoft, managing antitrust compliance with American and European orders and decrees had this to say:
With oversight from the DOJ, the District Court Judge, and the European Commission, Microsoft did not and could not consider compliance with the interoperability requirements to be optional or something they might take under consideration if asked. They were mandatory and therefore something the broad ecosystem could rely upon. Gene Burrus
This helped usher in significant competition in music hardware and software from Apple, whose success was used to launch the iPhone:
For example, the iPod did not achieve widespread adoption until Apple developed a crossplatform version of the iPod and iTunes for Microsoft’s Windows operating system, at the time the dominant operating system for personal computers. In the absence of the consent decree in United States v. Microsoft, it would have been more difficult for Apple to achieve this success and ultimately launch the iPhone. DOJ Complaint against Apple
(emphasis added)
The iPod illustrates how yesterday’s antitrust enforced interoperability can translate into tomorrow’s innovation and growth. Apple’s breakthrough consumer product did not become a mass market phenomenon until iTunes and the iPod worked seamlessly on Windows. The iPod's success then laid the groundwork for the eventual triumph of the iPhone.
Interoperability obligations also made it far more feasible for third-party browsers such as Firefox and later Chrome to succeed on Windows, rather than leaving the field to an increasingly stagnant Internet Explorer. This shift was critical to allowing the web to compete on the desktop, where it now accounts for roughly 70% of user time.
The irony is that Apple, once a beneficiary of an ecosystem where the dominant platform was pushed to open up, is now large enough to fear the same sort of openness. Interoperability mandates are easy to celebrate when they pry open someone else’s gate, and much harder to embrace when your own platform becomes the one that must be easier to build on, easier to leave, and less able to treat integration as a moat.
Small businesses are the drivers of growth and innovation
Last year there were calls for the Competition and Markets Authority (CMA) to be “more pro-business”, which appeared to suggest that the UK should ease up on enforcing rules against some of the world’s most powerful companies. Former Chancellor Jeremy Hunt went so far as to publicly admonish the CMA, urging regulators to “understand their wider responsibilities for economic growth”.
The move follows a meeting between CMA Chief Executive Sarah Cardell and other regulators with British Finance Minister Rachel Reeves to deliver ideas on how to stimulate growth. Regulators were told to “tear down the barriers hindering business and refocus their efforts on promoting growth. Ryan Browne - CNBC
But this framing is backwards. Weakening enforcement of competition rules does not drive economic growth, quite the opposite. Economists widely agree that tolerating anti-competitive behaviour entrenches dominant firms, stifles innovation, and ultimately harms consumers and startups alike. It also risks conflating the continued expansion of already powerful corporations with genuine economic growth. The CMA’s role is not to enable dominant firms to use anti-competitive conduct to grow and further entrench their market position, but to maintain competitive conditions so that new entrants and challengers can succeed, driving innovation, productivity, and broader benefits across the economy.
It seems like the UK now welcomes monopolies provided they have an investment story. There’s something really topsy-turvy about this. Former CMA Regulator
This matters as competition is the primary driver of growth and innovation. Companies that, due to anti-competitive behaviour or some structural reason, do not face sufficient competition, are likely to raise prices and minimize expenditure beyond what is necessary to retain existing customers.
Consumers, competition, and the competitive process—not Apple alone—should decide what options consumers should have. And competition, not Apple’s self-interested business strategies, should be the catalyst for innovation essential to our daily lives, not only in the smartphone market but in closely related industries like personal entertainment, automotive infotainment, and even more innovations that have not yet been imagined. Competition is what will ensure that Apple’s conduct and business decisions do not thwart the next Apple. DOJ Complaint against Apple
(emphasis added)
The idea that easing pressure on gatekeepers will help startups is fundamentally flawed. In reality, failing to curb the control dominant firms exert over their platforms, especially through blocking competition, actively harms smaller players and undermines the interests of the UK public. Interoperability rules will help startups not hurt them:
The DMA's interoperability and fairness rules were designed to pry open closed platforms and give smaller companies a fighting chance. [...] Big Tech lobbyists portray the DMA as anti-American. In reality, the DMA's goals align with American ideals of fair competition. This isn't Europe versus America; it's open markets versus closed ones. Luther Lowe - Y Combinator - Head of Public Policy
(emphasis added)
Start-ups are a key part of the innovation economy, it is the gatekeepers who often lag in innovation. The CMA most recent report highlighted that Apple can and does profitably forego innovation without fear of losing customers to competitors with this quote:
Apple’s vice president of iPhone marketing who explained in February 2020: ‘In looking at it with hindsight, I think going forward we need to set a stake in the ground for what features we think are ‘good enough’ for the consumer. I would argue were [sic] already doing *more* than what would have been good enough.’ After identifying old features that ‘would have been good enough today if we hadn’t introduced [updated features] already’, she explained, ‘anything new and especially expensive needs to be rigorously challenged before it’s allowed into the consumer phone.’ CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision
(emphasis added)
What should the CMA do?
We do not expect that commitments will be appropriate to address concerns following a Strategic Market Status (SMS) designation in all circumstances. For example, we are unlikely to pursue commitments where there is significant divergence between us and a firm on what we are looking to achieve, where firms have little incentive to change their conduct, where compliance is difficult to determine, observe or monitor, where measures can be easily circumvented, or where an SMS firm’s historical conduct does not give us confidence it will work constructively with us. CMA - Proposed Commitments - Call for Evidence
(emphasis added)
The CMA has been clear that commitments will not be suitable in every SMS case, especially where remedies are easy to circumvent, hard to monitor, or where the firm’s past conduct suggests it will not engage constructively.
In Apple’s case, the measures they are proposing “can be easily circumvented”, Apple’s historical conduct both globally and with the DMA "does not give us confidence it will work constructively with [[the CMA]]” and Apple not only has “little incentive to change their conduct” but has vast incentives to preserve the status quo.
Our recommendation is therefore that the CMA impose a clear, enforceable requirement on Apple to provide, free of charge, access to all APIs and operating system features needed for third parties to interoperate with iOS. This obligation should be subject only to security measures that are strictly necessary and proportionate to protect the integrity of the operating system. The burden of proving that any restriction is necessary and proportionate should rest entirely with Apple. Eligible third parties should include all businesses and developers that provide apps, services, and ancillary devices to UK consumers.
We further recommend that the CMA closely examine the EU’s experience under the DMA with comparable interoperability obligations, including the extent of Apple’s compliance and the practical lessons on enforcement. In particular, the CMA should consider what additional safeguards are needed around deadlines, API stability, transparency, and monitoring so that the requirement is effective in practice.
Key requirements should include:
- A clear process with defined steps.
- Binding deadlines for Apple at each step.
- The ability for developers to make requests public, with public responses where the requesting developer wishes.
- Upfront publication of any security measures, with Apple required to justify them publicly as strictly necessary and proportionate.
- No presumption that Apple’s security is inherently more secure than third parties.
- APIs provided free of charge.
- An independent appeals process.
Finally, the CMA should build in a structured review and update mechanism from the outset, on the assumption that new circumvention strategies will emerge and will need to be addressed quickly.
Without these measures, it is, in our view, highly likely that the CMA’s stated objective to grant developers interoperable access to key functionality in Apple’s iOS and iPadOS to create innovative products will fail.