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. As outlined in our previous article, Apple’s proposed 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), but it does not appear to be using those powers.
Our Response
This submission sets out our response to the CMA’s consultation on Apple’s and Google’s proposed commitments, focusing specifically on Apple’s proposed interoperability commitments. Building on the concerns raised in our earlier analysis, we explain why Apple’s proposal offers no meaningful outcomes, and why non-binding commitments are unlikely to deliver the interoperable access that developers, businesses, and consumers need. We argue that the CMA should not use voluntary commitments and instead should impose clear, enforceable interoperability requirements on both Apple and Google that support competition, innovation, and genuine user choice.
Our primary concerns are:
Apple retains extremely broad discretion to reject interoperability requests while remaining in full compliance, meaning the gatekeeper still decides how much competition to allow.
This is especially harmful for browsers and web apps, where API access determines whether they can compete fairly with native apps and Apple’s own services.
Weak voluntary commitments risk delaying real change while giving the appearance of action.
Worse, accepting such a weak model could entrench a dangerously low standard for interoperability in the UK and beyond, and make it harder for the CMA to enforce an effective remedy in future.
This is likely to reduce growth and innovation in the UK, which works against the CMA’s 2025 government steer.
Most importantly, it would leave in place the kind of anticompetitive conduct that the DMCCA was specifically passed to address, to the detriment of both UK consumers and UK businesses.
Other Responses
Please consider reading these other responses:
Thank You for Writing In
A big thank you to everyone who wrote in. Public submissions really do matter, and they help the CMA understand how these issues affect people in practice. Even a short one-paragraph email explaining why this matters to you as a business or consumer can make a meaningful difference.
Response to Apple's Interoperability Commitments
1. Introduction
Summary: Open Web Advocacy’s primary recommendation is that the CMA reject Apple’s proposed commitments and instead pursue conduct requirements that ensure genuine interoperability.
We thank the CMA for inviting feedback in both written form and through meetings. We are grateful for the opportunity to contribute to this process and to support the development of fair competition in the UK’s digital economy.
The CMA has undertaken incredible and valuable work in the digital sector over the past five years, including through the Mobile Ecosystems Market Study, the Browsers and Cloud Gaming Market Investigation Reference, and the SMS investigations concerning Apple and Google. We are deeply appreciative of the considerable effort the CMA has invested in identifying anti-competitive conduct, as well as the openness with which it has engaged with external stakeholders, including non-profits such as ourselves.
In particular, the CMA’s decision in 2021 to investigate browser engine and web app competition issues has had a significant and lasting positive impact, influencing regulatory approaches in other jurisdictions, including the EU, Australia, and Japan.
This matters as a genuinely open and interoperable ecosystem of the Web offers the clearest route to challenging the Apple and Google app store duopoly because it creates a middleware layer through which developers can reach users across operating systems. Developers can write applications once for all platforms in a single programming language, lowering cost and raising quality. Crucially, they are not forced to depend on proprietary app stores or submit to the shifting, self-preferential commercial and technical demands of gatekeepers. This reduces reliance on the dominant app stores, lowers barriers to entry, and expands consumer choice. Yet the Web is currently being constrained on mobile, primarily by Apple’s anti-competitive conduct in relation to browser engines. Fair API access, and especially effective access to those APIs for browsers, is critical to unlocking this parallel ecosystem and delivering its competitive benefits to UK businesses and consumers.
More broadly, in the context of this consultation, we are pleased that the CMA has recognised interoperability as an important mechanism for supporting effective competition for the benefit of consumers:
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 are, however, concerned by both the substance of the measures now proposed and the method of enforcement adopted in this first wave of changes under the DMCCA.
In particular, the interoperability commitment places no obligation on Apple to share any API and provides Apple with many ways to reject any request while still remaining in full compliance. There are no clear criteria by which Apple can fail this commitment via the rejection of interoperability requests.
We are also concerned by the CMA’s decision to rely on voluntary commitments rather than imposing ex ante conduct requirements. Had the commitments themselves been robust, for example by including an obligation comparable to Article 6(7) of the Digital Markets Act (DMA), we would still have been concerned about the potential for delay inherent in a voluntary approach.
In this case it is particularly troubling because both the substance of the commitment and the mechanism chosen to enforce it are weak. It is also concerning that the measure is described as an "interoperability commitment", both in the commitment itself and in the CMA’s public communications. That risks setting a dangerous precedent by suggesting that this is the level of interoperability the CMA is prepared to accept, despite leaving Apple free to withhold any API access. It may also encourage other jurisdictions to adopt similarly weak standards, harming UK businesses’ global reach, and could make it more difficult for the CMA to impose a genuinely effective interoperability requirement in the future.
We are not alone in our concerns:
First, the commitment explicitly preserves Apple’s discretion to decline requests. [...] This reservation substantially limits the substantive impact of the interoperability commitment. [...] it should not be confused with a meaningful interoperability obligation of the kind found, for example, in Article 6(7) of the EU’s Digital Markets Act. [...] Second, the assessment criteria include alignment with Apple’s platform priorities and potential impact on Apple’s intellectual property rights. These criteria are inherently subjective and could be invoked to justify declining requests that would enhance competition. SCiDA Project - Response
(emphasis added)
Apple’s proposal, as publicly described, does not create any clear right for developers to access specific APIs or functionalities, even when Apple’s own services rely on them. It leaves Apple free to accept or reject requests based on broad, subjective criteria, to delay decisions, and to impose fees or conditions that are particularly harmful to Free Software and smaller developers. A weak UK model would provide Apple with arguments against stronger regimes such as the EU’s DMA. If the CMA endorses a light-touch approach, Apple can point to it as the “compromise” that others should follow, thereby undermining efforts to enforce robust obligations in the EU and elsewhere. It would waste the DMCCA’s potential at the moment when it matters most. Endorsing Apple’s voluntary scheme would confirm those fears and risk emboldening other gatekeepers to offer similarly weak proposals. Weak enforcement entrenches anti-competitive behaviour and harms UK innovators, many of whom build on or contribute to Free Software. If Apple remains free to limit interoperability and to discriminate against Free Software, UK-based developers will continue to face structural barriers to reaching users on iOS, and UK users will continue to be denied the benefits of an open, diverse software ecosystem. FSFE - Response
(emphasis added)
We acknowledge the CMA’s desire to be pragmatic so that it can take action quickly and proportionately, but we are concerned about the precedent it is setting by accepting a weaker level of intervention. [...] This may not be problematic if commitments fully and effectively resolve issues, however this is unlikely to be the case often and it may result in increased pressure on the CMA to enforce weaker remedies in place of stronger intervention that leads to better market outcomes. Increasing the likelihood of commitments being offered as a first port of call also adds burden to the process that may slow the pace that the CMA is able to achieve effective remedies. We encourage the CMA to recognise and guard against this risk. Which? - Response
(emphasis added)
Table of Contents
Table of Contents
1.1. The CMA’s Statutory Duty to Promote Competition
1.2. Legal Basis for Interoperability Requirements under the DMCCA
1.3. Voluntary Commitments vs Ex Ante Requirements
2. Review of Apple’s Proposed Interoperability Commitments
2.1. Apple Isn’t Committing to Sharing Anything
2.2. UK Developer Program Only
2.3. Broad and Gameable Rejection Criteria
2.4. Apple Allows for Billing for API Access
2.5. Weak Deadlines and Lack of Transparency
2.6. How Apple can Comply and Still Do Nothing
3. Lessons from History: The DOJ vs Microsoft
4.1. Benefits for Consumers and Businesses
4.1.1. Equal Memory Limits (Global)
4.2. Apple’s Response to Article 6(7)
4.2.1.2. Interoperability Specification Process
4.2.1.3. Third-Party Devices Specification Process
5.5. Does Accepting Apple’s Proposal follow the 4 P’s
6. CMA’s Criteria for Assessment
6.2. Historical Conduct in the EU
6.3. Historical Conduct in the US
6.5. Issues with Monitoring Under Current Proposal
7. Should Google have an Interoperability Requirement on Android
8. Why Weak Enforcement is Worse than Nothing
9. Why the UK needs a General Interoperability Conduct Requirement
1.1. The CMA’s Statutory Duty to Promote Competition
The CMA has recently made a number of concerning comments questioning the need to always push for competition:
Equally, it does not require us to take an overly narrow, ideological stance in defence of competition. In the current economic, political and geopolitical context, that would not, in my view, discharge our mandate in the UK’s best interests. [...] Not competition for its own sake, but in service of national priorities – specifically driving economic growth and improving household prosperity. Not competition above all else, but as a powerful tool to deploy alongside other levers – like tax, subsidy, investment, or regulation. [...] And mobile, where we secured meaningful commitments from Google and Apple to deliver improved certainty, transparency and fairness for thousands of UK businesses, dependent on app stores to access their customers. Those commitments – which include rigorous monitoring and reporting requirements - create immediate benefits without necessitating a lengthy formal process. Sarah Cardell - the CMA’s Chief Executive
(emphasis added)
It has also been suggested by the former chair of the CMA Marcus Bokkerink, that the CMA has effectively ceased enforcement of the DMCCA on US based tech giants:
I was asked if the current UK government approach to competition policy has had a chilling effect on enforcement. The short answer is two-fold. In anything to do with digital infrastructure, digital services, and AI involving US-HQd technology platform businesses with overwhelming market power, enforcement has effectively ceased (in turn discouraging innovations and alternatives to economic dependency from developing). Marcus Bokkerink - Former Chair of the CMA
(emphasis added)
However, promoting competition for the benefit of consumers is not optional. It is the CMA’s core statutory duty under the Enterprise and Regulatory Reform Act 2013:
(1)There is to be a body corporate known as the Competition and Markets Authority. (2)In this Part that body is referred to as “the CMA”. (3)The CMA must seek to promote competition, both within and outside the United Kingdom, for the benefit of consumers. Enterprise and Regulatory Reform Act 2013 - Part 3
(emphasis added)
That position was reinforced in the most recent government strategic steer, which made clear that free and fair competition, alongside consumer protection, is a driver of growth, innovation, productivity and investment in the UK:
The primary mission of this government is economic growth. Free and fair competition and effective consumer protection support growth by driving forward innovation, increasing productivity, and encouraging investment – including international direct investment – into the UK. Strategic steer to the Competition and Markets Authority
(emphasis added)
Moreover, the CMA is institutionally independent from the government. Tax, subsidy, investment and wider regulation are tools available to Parliament and government, not to the CMA. The CMA has its own statutory powers and responsibilities, and it should exercise those rather than pointing to policy levers that sit outside its remit.
Finally, the CMA has not explained in any meaningful detail why conduct requirements would fail to benefit UK consumers, or how they might harm them. Without that analysis, third-parties are left without a clear basis for assessing the claim that the CMA should refrain from using its DMCCA powers and instead rely on the government to act through tax, subsidy, investment, or other forms of regulation.
1.2. Legal Basis for Interoperability Requirements under the DMCCA
Interoperability was one of the very clear reasons that the CMA, using DMCCA, could impose conduct requirements.
This was highlighted during the parliamentary debates. As Viscount Camrose, former Under Secretary of State in the Department for Science, Innovation and Technology, explained:
Depending on the scope of the designation, the DMU can set conduct requirements under Clause 20(3)(e) to promote interoperability, not only with a platform but in a range of contexts, including web browsers, apps, operating systems and websites. Viscount Camrose
(emphasis added)
Damian Collins made a similar point in even stronger terms:
There are only in effect two app stores, and given the lack of interoperability, they are virtually monopolies. Damian Collins
(emphasis added)
The same point is reflected in the Explanatory Notes to the Act, which expressly state that the regime is intended to:
Ensure that designated undertakings comply with rules (called conduct requirements) on how they treat consumers and other businesses in relation to the activities in which they have been designated. [...] • Give the CMA powers to address proactively the root causes of competition issues in digital markets. It could intervene to impose interoperability obligations on designated undertakings to help new competitors enter the market Digital Markets, Competition and Consumers Act 2024 - EXPLANATORY NOTES
(emphasis added)
This is then spelt out directly in the Act itself. Section 20(3) provides that conduct requirements may be imposed for the purpose of preventing a designated undertaking from:
(b) using its position in relation to the relevant digital activity, including its access to data relating to that activity, to treat its own products more favourably than those of other undertakings; ... restricting interoperability between the relevant service or digital content and products offered by other undertakings; [...] (h) restricting the ability of users or potential users to use products of other undertakings. DMCCA - Section 20 (3)
(emphasis added)
Taken together, these materials show that interoperability was not a marginal or incidental issue in the design of the DMCCA. It was specifically identified by Parliament and directly incorporated into the statutory framework as one of the matters that conduct requirements may address.
This all suggests that there is a strong legal basis for the CMA to impose robust interoperability conduct requirements analogous to Article 6(7) of the DMA in relation to Apple or Google, should it choose to do so. Such an approach would not be an expansive reading of the CMA’s powers. It would be a straightforward use of powers that were plainly intended to address precisely these kinds of interoperability restrictions.
1.3. Voluntary Commitments vs Ex Ante Requirements
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)
A useful starting point is to ask what ex ante digital regulation is for.
Regulators around the world face a basic structural problem: a handful of technology firms have legal and financial resources that exceed those of the authorities overseeing them. In practice, that means fines can be absorbed as a cost of doing business, while antitrust cases are typically lengthy, complex, and difficult to prove.
Ex ante regimes such as the EU Digital Markets Act, the UK DMCCA, and Japan’s Smartphone Act are designed to address exactly these problems. First, they allow for penalties large enough that even the biggest firms cannot simply ignore them. Second, they empower regulators to set clear pro-competitive rules in advance for firms whose scale and market power justify such obligations.
That matters because it changes the enforcement dynamic. Under an ex ante regime, gatekeepers are expected to comply proactively and to demonstrate that they are doing so. The regulator no longer needs to spend years proving the full antitrust case from first principles. Instead, it need only show that the gatekeeper has failed to comply with the applicable conduct requirements and that those requirements were lawfully imposed under the statute.
This makes enforcement faster, more predictable, and more effective. It also gives gatekeepers the opportunity to come into compliance voluntarily before any formal investigation begins, while creating significant legal consequences for refusing to do so.
There is already strong evidence, including from the EU, that Apple has self-preferenced its own products and services by giving them better and earlier access to APIs.
In the browser context, this was also a finding of the Browser and Cloud Gaming Market Investigation Reference final report:
We conclude that the evidence demonstrates that Safari has or has had wider and more immediate access to functionalities on iOS than other mobile browsers. Browser and Cloud Gaming MIR - Final Report
(emphasis added)
The same conduct is also central to the US Department of Justice’s antitrust case against Apple, which alleges that:
Apple suppresses such innovation [...] by denying access to key points of connection between apps and the iPhone’s operating system (called Application Programming Interfaces or “APIs”). DOJ Complaint Against Apple
(emphasis added)
Given the scale of the revenue Apple derives from this conduct, and the length of time for which it has persisted, it is difficult to believe the company would voluntarily stop engaging in it. Indeed, the EU experience suggests the opposite. Apple not only undermined compliance through excessive delays in processing API requests, but, once deadlines were imposed, also challenged the EU in court in multiple cases.
This is precisely why the CMA should be cautious about relying on voluntary commitments for the most important issues. The areas where Apple and Google earn the greatest returns from anti-competitive conduct are also the areas where they have the strongest incentive to resist meaningful change. They are also the areas where intervention is most urgent, because they impose the greatest costs on UK consumers and businesses and reduce the quality, openness, and competitiveness of software and devices.
Against that background, it is hard to see how voluntary commitments could be effective in relation to the most serious forms of self-preferencing and exclusionary conduct. More likely, they risk delay. Worse, they may give gatekeepers an opportunity to argue that they are already addressing the issue through arrangements the CMA has itself endorsed.
By contrast, where firms are genuinely willing to change lower-priority conduct voluntarily, those issues would also appear well suited to formal conduct requirements. In such cases, the CMA may never need to enforce them, because the firms would comply without resistance. There are already many examples under the DMA of Apple and Google making changes without the need for a formal investigation or infringement proceeding.
For all of these reasons, we urge the CMA to treat conduct requirements as one of the fastest, clearest, and most legally secure ways to address the most serious forms of self-preferencing and anti-competitive conduct by SMS firms. It is not clear that voluntary commitments will do anything other than slow the process down. There is also a real risk that they will provide strategic cover for gatekeepers while the underlying harms continue.
Competition can be the key mitigation for the UK’s digital dependency [...] With the Digital Markets, Competition and Consumers Act [...], but slow implementation and weak early enforcement risk squandering a rare pro-growth and pro-SME opportunity. [...] The potential for huge economic growth from our tech sector is there, but competition is key. If competition flourishes, we will see more innovation, improved services and lower costs for consumers. Peter Fortune - UK MP
(emphasis added)
2. Review of Apple’s Proposed Interoperability Commitments
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 to reporting biannually more detailed data on the request system to the CMA.
This sounds promising until one examines the details, 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)
2.1. 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.
2.2. 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.
2.3. 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.
2.4. 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.
2.5. 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
(emphasis added)
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.
2.6. 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. This 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 regulatory environment 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.
3. 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 Judgment
(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 against 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
(emphasis added)
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.
4. Interoperability in the EU
To assess both the potential benefits of an interoperability obligation and the extent to which Apple might comply with such an obligation voluntarily, Europe and the DMA provides substantial evidence.
4.1. Benefits for Consumers and Businesses
Article 6(7) has already produced a number of benefits for EU consumers and businesses. In some cases these benefits have spread globally, including in the UK.
The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services. The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. DMA - Article 6(7)
(emphasis added)
For benefits that are locked to the EU, equivalent enforcement would bring them to the UK.
4.1.1. Equal Memory Limits (Global)
Sometimes the battle for open source and freedom can take on very prosaic and practical terms, but the wins can benefit everybody. To give an example: In Beeper we need more memory for showing notifications, because we support end-to-end encryption for networks like Signal, but Apple’s default was to only give 15 megabytes — barely enough to do anything. The previous CEO of Beeper, Eric Migicovsky, started a lobbying effort with the EU’s Digital Markets Act on behalf of the team to give third-party apps the same memory limits that Apple provides for their own apps, which is 50MB instead of 15MB. (And up to 250MB on their higher end devices.) Today we’ve gotten a notification that as part of iOS 26 update Apple has shipped to 2.3B devices around the world, our memory limits issue has been addressed globally, for every application developer, and some interoperability requests we had for SMS/RCS have been addressed for EU users. Kudos and huge thank you to Apple for giving us all new capabilities to build amazing experiences for users on par with what they seek to deliver themselves. Matt Mullenweg - co-founder of WordPress, founder of Automattic
(emphasis added)
Apple was limiting all non-Apple apps to 15MB of memory, while allowing far higher limits for its own apps of 50MB, and 250MB on their higher end devices. Matt Mullenweg, the co-founder of WordPress, founder of Automattic successfully lobbied Apple to fix this using Article 6(7) of the DMA.
A gatekeeper can provide services or hardware, such as wearable devices, that access hardware or software features of a device accessed or controlled via an operating system or virtual assistant in order to offer specific functionalities to end users. In that case, competing service or hardware providers, such as providers of wearable devices, require equally effective interoperability with, and access for the purposes of interoperability to, the same hardware or software features to be able to provide a competitive offering to end users. Digital Markets Act - Recital 55
(emphasis added)
Interestingly in this case it did not involve building or sharing a new API but rather equal access to existing APIs. This is covered by recital 55, which states that operating system gatekeepers must provide “equally effective interoperability”. The memory limit for non-Apple apps made the access to this made the interoperability with the hardware and software features of the device unequal, and thus in violation of Article 6(7).
4.1.2. Wi-Fi Aware (Global)
iOS devices cannot establish a P2P Wi-Fi connection with third-party connected physical devices through either of the two connection protocols, as Apple has neither made AWDL available to third-party hardware providers, nor made Wi-Fi Aware available to third-party iOS developers [...] 5.4.7. Measures that Apple should implement: [...] (240) Apple should make Wi-Fi Aware available to third parties. [...] In its response to the Preliminary Findings, Apple proposes to introduce Wi-Fi Aware […] to provide effective interoperability with the P2P Wi-Fi connection feature on iOS for third-party connected physical devices. DMA - Specification Proceeding - Features for Connected Physical Devices
(emphasis added)
The DMA’s specification proceeding into third-party devices compelled Apple to share Wi-Fi Aware with third-party developers in the EU. Wi-Fi Aware (NAN) enables direct, high-speed connections between nearby devices without internet or infrastructure. This is low level functionality with a lot of potential applications including airdrop, local multiplayer, IoT control, proximity services and as yet uninvented innovations.
Previously Apple had reserved the functionality by not sharing AWDL (Apple Wireless Direct Link, a proprietary, high-speed mesh networking protocol developed by Apple) or making Wi-Fi Aware available to third-party developers.
Crucially, this decision was not a voluntary announcement by Apple – it was imposed by regulators. Apple has kept quiet about these changes publicly, likely because they involve opening up formerly closed-off tech. The DMA enforcement timeline was highlighted in an EU Q&A site and legal annex, not an Apple press release.7 The European Commission’s language makes it clear this is about enabling third-party devices and apps to use high-bandwidth peer-to-peer (P2P) Wi-Fi features equal to Apple’s own, rather than Apple benevolently adopting a new standard. In fact, the EU order compels Apple to deprecate AWDL and ensure third-party solutions using Wi-Fi Aware are just as effective as Apple’s internal protocols. [...] Apple’s reluctant adoption of Wi-Fi Aware marks a pivot point for device connectivity. For years, we’ve seen a split: Apple’s ecosystem “Just Works” within itself (thanks to AWDL, AirDrop, etc.), while other platforms muddled along with standards that never quite matched the seamlessness or performance. That left cross-platform interactions hamstrung – the experience of sharing something between an iPhone and an Android was far from instant or easy. Adam Fish - Founder and CEO of Ditto
(emphasis added)
With iOS 26, Apple rolled out global support for Wi-Fi Aware.
Another interesting point here is that Apple will often claim security concerns but in this case when asked to actually back up those claims with evidence in a formal setting they failed to do so:
Apple’s reply to the Preliminary Findings, paragraph 376.c. Apple’s claims about integrity concerns regarding automatic Wi-Fi connection were unsubstantiated prior to the adoption of the Preliminary Findings. In fact, only in Apple’s mark-up of the Commission’s proposed measures of 23 January, did Apple even propose a mitigating measure, although again in an unsubstantiated way (see Section 4.7.7 of this Decision for details). In particular, Apple’s submission of 7 November 2024 and the cited slide deck presented on 18 October 2024, do not mention the automatic Wi-Fi connection or discuss any integrity, privacy or security concerns relevant to that feature. DMA - Specification Proceeding - Features for Connected Physical Devices
(emphasis added)
This is why placing the burden of proof on Apple to show that security measures are strictly necessary and proportionate is critical in any interoperability conduct requirement.
4.1.3. Host Card Emulation
iOS 17.4 or later includes APIs that support contactless transactions for in-store payments, car keys, closed loop transit, corporate badges, home keys, hotel keys, program membership, and event tickets from within compatible iOS apps using host card emulation (HCE). Users based in the European Economic Area (EEA) with an iPhone running iOS 17.4 or later can initiate in-person NFC transactions from iOS apps at compatible NFC terminals or mobile devices. Apple - Documentation
(emphasis added)
In iOS 17.4 Apple shared previously reserved NFC functionality with third-parties in the EU for a range of purposes. This particular functionality was not compelled to be shared under the DMA, but rather under a long running antitrust investigation in the EU. However, this is a good example of functionality that Apple could be compelled to share in the UK under a conduct requirement.
For the globally implemented fixes described above, the DMA did not require Apple to roll out these changes worldwide, only in the EU. Apple therefore deserves some credit for addressing these anti-competitive practices globally rather than waiting to be compelled to do so region by region.
4.2. Apple’s Response to Article 6(7)
Apple’s initial response to Article 6(7) appears to have been to simply delay complying with requests for interoperability. In many cases neither accepting them nor rejecting them.
Apple also had an undefined process with multiple unnamed steps. Requesters were often told that their application had moved to the “next step”, without any details on what step that was, or what step had just been completed. In the case of some of the third-party device requests, Apple kept this going for over 6 months.
Apple informed the Commission that it has moved some of the aforementioned requests to 'the next phase of the interoperability process.' (11) (12) At the same time, Apple is 'still undertaking an assessment' of other interoperability requests made pursuant to Article 6(7) of Regulation (EU) 2022/1925 and has not yet moved these to the 'next phase' of Apple’s own review process. Decision to a Specification Proceeding into Apple for Connected Devices
(emphasis added)
This repeated delay is mentioned in the Commission’s Implementing Decision.
On its website, Apple indicated that it would aim at providing developers updates every 90 days.It appears from the 108 interoperability requests received by Apple from January 2024 until 31 October 2024, that the time taken by Apple to process interoperability requests through the different stages is significantly longer than the timelines mentioned in the previous paragraph. Commission Implementing Decision
(emphasis added)
In response the EU Commission opened a specification proceedings into Apple interop process. A specification proceeding is a process by which the EU Commission can more precisely spell out how to comply with a particular part of the DMA. The proposed measures of the interop process specification proceeding included increased upfront transparency of internal iOS and iPadOS features, timely communication and updates, fair and transparent handling of rejections and a more predictable timeline.
The EU Commission also opened a specification proceeding into interop for third-party devices in relation to several iOS connectivity features, predominantly used for and by connected devices. Including notifications, automatic Wi-Fi connection, AirPlay, AirDrop and automatic Bluetooth audio switching.
As a result of the interop process specification proceeding the EU Commission has imposed an interoperability process on Apple due to a repeated failure by Apple to both share reserved functionality and a slow-walking of existing requests.
Under the new process, third-parties have the right to file interoperability requests with Apple under Article 6(7) of the DMA. These requests can be for any software or hardware feature available on iOS and iPadOS. This includes even subsets of features, i.e. if Apple is reserving a better version for its own apps, services or devices, as well as, third-party devices interoperating with iOS or iPadOS.
Apple is only obligated to provide access to this functionality within the EU.
The request process follows 3 phases:
Phase I – Eligibility phase: Apple assesses the eligibility request to ensure that the requests fit within the scope. Must be completed within 20 days.
Phase II – Project Plan: The Project Plan should be completed by Apple within 40 working days, starting from the end of phase I. Apple should communicate the project plan to the developer who will have the opportunity to provide its feedback on it.
Phase III – Development: to establish a predictable and reliable timeline for the development phase. Apple should develop interoperability solutions that require minor, mild, and significant efforts within 6, 12, or 18 months from the submission of the interoperability request, respectively.
4.2.1. Lawsuits
In response to Article 6(7) and the specification proceedings that attempted to make enforcement effective, Apple then took the EU Commission to court in three separate court cases related to Article 6(7).
4.2.1.1. Designation
In this case (still ongoing) Apple is taking the EU Commission to court claiming the following points:
- Article 6(7), the article imposing interoperability requirements, which Apple argues is illegal due to being disproportionate under the European Charter of Fundamental Rights.
- Apple in fact has 5 app stores, not one. i.e. the App Store on iOS, iPadOS, WatchOS, VisionOS and MacOS are distinct.
- iMessage isn’t a number-independent interpersonal communications service.
Apple is asking that the court to annul the Commission’s decision designating iOS as a gatekeeper, declare Article 6(7) inapplicable, annul the finding that Apple’s App Store is a single core platform service, annul the finding that iMessage is a number-independent interpersonal communications service, and order the Commission to pay Apple’s costs.
4.2.1.2. Interoperability Specification Process
This case (also still ongoing) relates to the final decision in the EU Article 6(7) specification proceeding against Apple. Article 6(7) of the DMA is the one which mandates that gatekeepers must provide API access to third-parties free of charge, subject to strictly necessary, proportionate and justified security conditions.
Apple is arguing in their court case that:
- These requirements are disproportionate under the European Charter of Fundamental Rights.
- The European Commission exceeded the limits imposed by Article 291 TFEU.
- That the Commission misapplied Article 6(7) of the DMA.
- That Apple should not have to share new functionality with third-parties at the same time it grants them to its own apps and services.
- Apple should not have time limits imposed on it for each step in the interop process.
- Developers should not be able to request a technical reference from Apple to discover what undocumented functionality is available to request interoperability with.
4.2.1.3. Third-Party Devices Specification Process
In this case (also still ongoing) Apple is arguing that the EU misapplied the law by imposing specific interoperability requirements for the following features:
Background Execution
Automatic Audio Switching
Proximity-Triggered Pairing
Close-range Wireless File Transfer
iOS Notifications
Media Casting
Automatic Wi-Fi Connection
NFC Controller in Reader/Writer Mode
High-Bandwidth Peer-to-Peer Wi-Fi Connection
Apple is also arguing that it should not have to share new functionality with third-parties at the same time it grants them to its own apps, devices and services.
Apple argues that it does not need to allow third parties with interoperability for future updates, including new functionalities, of the features controlled or accessed via iOS at the same time as they are available to Apple. According to Apple, such an obligation is not within the scope of Article 6(7) of Regulation (EU) 2022/1925 and would limit Apple’s incentives to innovate, increase the development cost of new features, reduce Apple’s competitive advantage and allow third parties to free ride on Apple’s innovation. Commission Implementing Decision
(emphasis added)
The highly detailed specification decision is available here and its update here.
5. The 4 P’s
Recently the CMA stated that the DMCCA will be governed by the four Ps.
These are:
- Pace
- Predictability
- Proportionality
- Process
To be successful, they rely not only on the CMA’s commitment to change, but also the willingness of businesses and advisors to engage constructively and co-operatively with what we are proposing. Sarah Cardell - Chief Executive of the CMA
(emphasis added)
Unfortunately, we believe accepting Apple's proposal would fail on all 4 of these fronts.
5.1. Pace
The CMA says digital markets move quickly and that its work must keep up with market dynamics while avoiding prolonged uncertainty that could chill investment and innovation. It emphasizes statutory time limits in the DMCCA, a duty of expedition, and a desire to focus on interventions that deliver positive outcomes quickly and effectively.
Apple's proposal places no obligation on it not to reserve APIs or better versions of APIs for its own apps, services and ancillary devices.
Apple’s proposal is too soft, too open-ended, and too dependent on Apple’s own internal priorities to deliver the rapid, market relevant outcomes the CMA says the regime should provide. A system where Apple need only try to send an update in four weeks, while retaining full discretion over whether anything is ever built, is not a pace oriented remedy.
Apple’s record in the EU makes the pace objection more serious. The Commission states that under Article 6(7), Apple must provide developers and businesses with free and effective interoperability with hardware and software features controlled by iOS and iPadOS. Yet the Commission still had to open specification proceedings. This supports the argument that absent binding obligations and enforceable deadlines, Apple will not deliver interoperability quickly on its own.
In this regard the proposal commitment fails on pace, as it will simply delay any potential effective remedy.
While it could be argued that this is simply an evidence collecting tool, the CMA has access to ample evidence in the EU both publicly and which they could request from the EU Commission.
5.2. Predictability
The CMA says predictability is central because businesses need confidence to invest and innovate.
Again Apple's proposed process fails on predictability, as it is entirely up to Apple what APIs it will share. The central defect is that Apple keeps all material decisions discretionary. It lists criteria for assessing requests, but those criteria are exceptionally broad and subjective: expected user and developer uptake, alignment with Apple’s platform priorities, potential implementation costs, possible impacts on user experience and performance, security, safety, privacy, integrity, accessibility, and possible impacts on Apple’s intellectual property rights. These criteria are not framed as narrow exceptions to a presumptive duty to interoperate. They are a set of open ended considerations that Apple itself applies. That means a developer cannot reliably predict whether a request will succeed, because Apple can reject any request at will and remain in compliance. Worse, Apple states expressly that even an eligible request does not create an obligation to build anything, and that outcomes remain at Apple’s discretion.
Apple will also not provide businesses advanced warning that their request has been successful.
While a cynic could argue that it is predictable that Apple simply won't share any APIs that give its own services a significant anti-competitive advantage, that is clearly not the intent of the CMA's guidance here.
Predictability also requires that businesses are able to understand how the CMA will exercise its powers, what regulatory pathway will be followed, and what outcomes they can reasonably expect. In this case, the CMA has undermined that predictability by departing from the anticipated DMCC framework without providing any clear indication, criteria, or explanation for doing so. The decision to rely on voluntary commitments, rather than pursuing conduct requirements, was not signalled in advance and does not appear to follow an articulated or consistent approach. As a result, developers and market participants cannot reliably anticipate whether future issues will be addressed through binding obligations or negotiated commitments, nor what standard of intervention will apply. This lack of clarity weakens confidence in the regime, makes it harder for businesses to plan and invest, and undermines the ability to rely on the CMA’s processes and expected next steps.
Only a small number of designations have been made so far. For Google’s and Apple’s mobile ecosystems, the CMA has relied on non-binding “commitments” rather than imposing binding conduct requirements. These non-binding commitments have no clear statutory basis under the 2024 Act, carry no legal consequences if breached and are not contemplated anywhere in the CMA’s published guidance. Their use risks weakening the regime and forcing the CMA to restart enforcement if firms fail to comply, which is precisely the outcome that the last Government sought to avoid. Peter Fortune - UK MP
(emphasis added)
5.3. Proportionality
At first glance, Apple might argue its proposal is proportionate precisely because it is modest and flexible. But that is not the CMA’s concept of proportionality. The CMA says proportionality is about interventions being targeted, evidence led, tailored to maximize impact while minimizing costs, and chosen where DMCCA intervention is the most effective route to deliver the desired outcome.
Is it really proportionate to permit Apple to continue reserving APIs for its own services, to the detriment of UK businesses and consumers? And can a proposal that allows this conduct to continue truly be regarded as the most effective means of delivering the outcome the CMA itself has identified below:
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)
The CMA’s proportionality framework requires that interventions be effective relative to the scale of the harm identified. In this context, the relevant evidence from both the EU and the US demonstrates a consistent pattern of delay, strategic obstruction, and “malicious compliance” by Apple when faced with interoperability or competition remedies. Even under binding regimes such as the DMA, the European Commission has had to initiate specification proceedings to secure meaningful outcomes, while in the United States Apple’s response to court-ordered remedies has involved the introduction of new barriers designed to preserve existing revenue streams. Against this background, a voluntary system in which Apple retains full discretion over whether and how to grant interoperability requests amounts to allowing it to mark its own homework. That is not proportionate to the scale of the competition problem identified. Where the evidence shows that weaker, discretionary mechanisms fail to change entrenched behaviour, a stronger, binding conduct requirement is not disproportionate but necessary.
On these grounds, we would argue that accepting Apple’s proposed commitments would fail on proportionality.
5.4. Process
It does not seem clear that the CMA is following the expected process with regard to the DMCCA. It is not clear what part of the DMCCA the CMA is relying on for these voluntary commitments.
On the legal status of the commitments, we note that the DMCCA does not contain an explicit mechanism for voluntary commitments of this kind, and recommend that the CMA clarify their normative foundation and the consequences of non-compliance. SCiDA Project - Response
(emphasis added)
The CMA may be relying on Section 36 of the DMCCA. However, this does not seem to fit the process as Section 36 appears to apply only where the CMA is accepting a commitment from an undertaking that is already subject to a conduct investigation. If that is the route being used here, the CMA should make that explicit and publish the procedural steps that led to it.
If Section 36 is in fact the mechanism being used, it also appears to limit the CMA’s ability to open a conduct requirement investigation into the same conduct unless one of the statutory exceptions applies. Given the form of these commitments, that could be a significant problem because it may restrict the CMA’s future enforcement options.
(b) the CMA beginning a new conduct investigation in relation to the behaviour to which the commitment relates where— (i) it has reasonable grounds to believe that there has been a material change of circumstances since the commitment was accepted, (ii) it has reasonable grounds to suspect that the undertaking has not complied with one or more of the terms of the commitment, or (iii) it has reasonable grounds to suspect that information which led it to accept the commitment was incomplete, false or misleading in a material particular. DMCCA - Section 36
(emphasis added)
In Apple’s case, none of those exceptions would obviously apply. There would likely be no material change in circumstances, no false or misleading information, and Apple could still comply with the commitment as drafted without sharing many important APIs. In that scenario, the CMA could arguably be prevented from opening a conduct investigation into interoperability because Apple would remain within the wording of the commitment.
The CMA has also been accused of misusing the word commitment in the first place which has a defined legal meaning.
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)
The way the DMCCA was expected to work as laid out, was that firms would be designated as having SMS status, then on an area by area basis the CMA would produce a binding conduct requirement. Nowhere in the SMS investigation was there any suggestion that voluntary commitments would be accepted from Apple and Google in place of conduct requirements.
Even parliament, which wrote the law, seemed somewhat surprised at the CMA's approach:
The CMA has recently started using the new powers granted by the Digital Markets, Competition and Consumers Act 2024 (DMCCA) to better protect consumers. Representations made to us throughout our consumer protection work suggest that there is plenty more for the CMA to do in this area. It is not clear it is making as many interventions as it should, nor is it clear it is fully using its new powers. For example, recently the CMA has sought voluntary undertakings from companies to remedy bad behaviour, rather than issuing binding orders. House of Commons - Business and Trade Committee
(emphasis added)
While it is obviously at the CMA's discretion which conduct requirements to create, it is unclear to us whether the CMA's process is being correctly followed here.
Finally, the CMA’s most recent Strategic Steer directs it to consider the actions being taken by competition and or consumer protection agencies in other jurisdictions internationally and, where appropriate, to ensure that parallel regulatory action is timely, coherent, and avoids duplication where those actions effectively address issues arising in UK markets.
The CMA should consider the actions being taken by competition and/or consumer protection agencies in other jurisdictions internationally, and, where appropriate, seek to ensure parallel regulatory action is timely, coherent and avoids duplication where these parallel actions effectively address issues arising in markets in the UK. Strategic steer to the Competition and Markets Authority
(emphasis added)
5.5. Does Accepting Apple’s Proposal follow the 4 P’s
The 4Ps are supposed to describe a regime that gives businesses confidence that the rules will produce timely, knowable, effective, and participative outcomes. Apple’s proposal gives businesses only the right to ask Apple nicely. It is not clear that the CMA accepting this proposal satisfies any of the criteria of the 4 P’s.
6. CMA’s Criteria for Assessment
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 above paragraph outlines four criteria by which the CMA will determine whether commitments as opposed to conduct requirements:
where firms have little incentive to change their conduct
where compliance is difficult to determine, observe or monitor
where measures can be easily circumvented
where an SMS firm’s historical conduct does not give us confidence it will work constructively with us
6.1. Apple’s Incentives
In contrast, limiting the features and functionality created by third-party developers—and therefore available to iPhone users—makes the iPhone worse and deprives Apple of the economic value it would gain as the platform operator. It makes no economic sense for Apple to sacrifice the profits it would earn from new features and functionality unless it has some other compensating reason to do so, such as protecting its monopoly profits. [...] Apple suppresses such innovation through a web of contractual restrictions that it selectively enforces through its control of app distribution and its “app review” process, as well as by denying access to key points of connection between apps and the iPhone’s operating system (called Application Programming Interfaces or “APIs”). Apple can enforce these restrictions due to its position as an intermediary between product creators such as developers on the one hand and users on the other. DOJ Complaint Against Apple
(emphasis added)
Better access to features and APIs on iOS for Apple’s apps, devices and services means that those services are superior to that of third-parties. In some cases it prohibits third-parties from offering those services at all.
Apple makes significant revenue from both services and ancillary devices (such as the Apple watch). In 2025, Apple made $109 billion net sales (including App Store, iCloud, Apple Music, Apple Books, Advertising etc) from services at a gross profit margin of 75.4%. In 2025, Apple made $35 billion net sales from Wearables, Home and Accessories, Wired has estimated that Apple Watch has made $127B in revenue over its first decade and 281M units shipped by end of 2024.
Were third-parties able to compete fairly with either services or wearables this could significantly and permanently harm Apple’s revenue. It would likely force them to either raise the quality of their products or accept lower prices thus harming their incredibly high profit margin.
This would also lower lock-in for the iPhone. Lock-in is an important strategy at Apple and interoperability undermines it at its core. If users can have a mix of Apple and non-Apple devices, that raises the risk that users might entirely exit the Apple’s ecosystem.
Apple uses smartwatches, a costly accessory, to prevent iPhone customers from choosing other phones. Having copied the idea of a smartwatch from third-party developers, Apple now prevents those developers from innovating and limits the Apple Watch to the iPhone to prevent a negative “impact to iPhone sales. [...] Indeed, as early as 2010, then-CEO Steve Jobs discussed how to “further lock customers into our ecosystem” and “make Apple[’s] ecosystem even more sticky.” Three years later, Apple executives were still strategizing how to “get people hooked to the ecosystem. DOJ Complaint Against Apple
(emphasis added)
6.2. Historical Conduct in the EU
Apple’s flawed initial implementation of Article 6(7), followed by the series of lawsuits it brought against the Commission over the specification proceedings needed to make that provision effective, strongly suggests that Apple is unlikely to adopt an effective interoperability solution in the UK on a willing or voluntary basis. In practice, that means the most viable route for imposing such an obligation is through a conduct requirement under the CMA’s DMCCA powers.
6.3. Historical Conduct in the US
Apple has not been compelled to share APIs in the United States, either by a court case or via a regulator. They have however been engaged in a very high profile court case with Epic over steering for in-app payments.
One can use their behavior in this case as a gauge to the degree to which Apple is willing to faithfully and genuinely engage in requirements from a regulator. In this case the requirements were court mandated, so one must assume that the compliance with voluntary requirements would be strictly worse.
Unfortunately Apple did not behave well in this case, and their behavior was quite possibly criminal:
Judge Yvonne Gonzalez Rogers said she was referring the matter to the US Attorney for Northern District of California to investigate whether a criminal contempt proceeding is appropriate. Lily Jamali - BBC
(emphasis added)
Though Apple largely prevailed in its original court case with Epic, the court issued an “anti-steering injunction” requiring that apps be allowed to direct users to external payment methods. The ruling left some flexibility in implementation, but Apple chose “an anti-competitive option at every step”.
Apple introduced a 27% commission on web purchases and layered on a deliberately intimidating warning screen for users leaving the app:
Rafael Onak, a user experience writing manager at Apple, instructed an employee to add the phrase “external website” to the screen because it “sounds scary, so execs will love it.” Another employee gave a suggestion on how to make the screen “even worse” by using the developer’s name, rather than the app name. “ooh - keep going,” another Apple employee responded in Slack. Even Cook got in on the action. When he finally saw the screen for approval, he asked that another warning be added to state that Apple’s privacy and security promises would no longer apply out on the web. In court, Apple tried to argue that the term “scary” didn’t actually mean it wanted the screen to scare people. “Scary,” it claimed, was a “term of art” — an industry term with a specialized meaning. In fact, the company claimed, “scary” meant “raising awareness and caution.” The court did not buy it, saying the argument strained “common sense. Jacob Kastrenakes - The Verge
(emphasis added)
Rather than engaging in serious, detailed security reviews and proposing proportionate safeguards, Apple’s internal discussions have included non-security personnel, including current Apple CEO Tim Cook, exploring how to make the alternative user experience deliberately “even worse”.
Apple also attempted to engineer the directive to allow external links in apps by creating new barriers and requirements that would similarly defang those orders. It created full-page “scare screens” (I referred to them as “This App May Kill You” screens), demanded that all links be to static URLs (neutering their utility), and kept editing the warning labels to dissuade users as much as possible from ever agreeing to follow the link. (Cook is specifically credited with amping up the language in the warning screens.) The company’s internal struggle is fascinating to read about. While Apple Fellow and longtime App Store overseer Phil Schiller doesn’t come across entirely smelling like a rose, he does end up looking far better than literally any other Apple employee in the ruling. Schiller “advocated that Apple comply with the Injunction”—imagine that!—while Tim Cook, CFO Luca Maestri, and the company’s finance team instead decided to concoct a strategy of malicious compliance that led to the poison pill of the 27% commission.” Jason Snell - Six Colors
(emphasis added)
This approach backfired on Apple when the judge found:
Apple willfully chose not to comply with this Court’s Injunction, It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple. Gonzalez Rogers
(emphasis added)
The court went further, holding Apple in civil contempt for misleading the court and abusing attorney-client privilege to delay proceedings. It ordered Apple to pay Epic’s legal costs and referred the matter to federal prosecutors for potential criminal sanctions against Apple and one of its senior executives.
This behavior should not raise confidence at the CMA that Apple will work constructively with them.
6.4. Risk of Circumvention
The historical conduct of Apple in both the EU and the US is strong evidence of the risk of circumvention. Given the number of ways Apple has given itself to not share functionality with third-parties in their proposal, we would argue that the proposal itself is evidence that Apple wishes to continue to reserve functionality or superior versions of functionality for its own services.
6.5. Issues with Monitoring Under Current Proposal
The current proposal primarily relies on aggregate statistics. Given the complexities of requests for API access this is unlikely to be an effective mechanism. A far more straightforward mechanism is to make all requests and responses public, unless the requester specifically wishes to make it (or parts of it) confidential. This is the approach the DMA has taken.
This is important for several reasons. One, it will allow like minded developers to work collaboratively with other requesters on the proposed interoperability solutions. Two, where Apple’s rejections are unreasonable, they can be publicly cited and pressure can be applied on Apple and finally it allows non-profits and other regulators to assess the degree to which Apple is sharing functionality in response to requests.
7. Should Google have an Interoperability Requirement on Android
We have heard fewer concerns from developers about lack of access to functionality for Google, where Android allows for broader third-party interoperability. CMA - Proposed Commitments - Call for Evidence
(emphasis added)
While we believe that Google is genuinely better behaved at not reserving APIs for its own usage, it should be straightforward for the CMA to impose an equivalent requirement on Google with respect to Android.
The fact that they are already mostly in compliance should make the burden of complying and the level of enforcement required from the CMA both low.
This requirement needs to consider APIs that are delivered via Google Play Services as Android APIs. One good example of an API that Google is refusing to share with third-parties is WebAPK minting.
8. Why Weak Enforcement is Worse than Nothing
There is a genuine concern here that if the CMA adopts a weak voluntary proposal such as what Apple has put forward, that not only could it be ineffective but that it could be used as ammunition to attack effective regimes such as the DMA. Apple could point to a weaker UK model as the alternative other jurisdictions should follow as they design their own rules, pulling global standards down until they are ineffective.
We are also concerned that by accepting such commitments that the CMA could limit its ability to enforce future commitments, as Apple could argue that it is abiding by terms that the CMA itself endorsed on interoperability.
Our view is that enforcement action has been quite weak,” Byrne said. “We are concerned about whether you might pull your punches and leave the new powers available to the CMA unused,” he added later, referring to the Digital Markets, Competition and Consumers Act, which came into effect last year and has significantly expanded the regulator’s powers, enabling it to give companies specific regulatory rules and engage in proactive enforcement, impose stronger penalties, and directly enforce consumer protection laws. Labour MP Liam Byrne - On opendemocracy
(emphasis added)
Apple has a long record of fighting digital regulation worldwide, often through friendly sounding third-parties. The company particularly dislikes the EU’s Digital Markets Act (DMA) because it is actually forcing meaningful changes at Apple and has already delivered multiple benefits.
At the same time, Apple has used noticeably softer language about Japan’s Mobile Software Competition Act (MSCA), which is less stringent in key areas. When announcing major App Store and iPhone changes for Japan, Apple argued that Japan’s approach “balances openness with security and user protection” better than the EU’s DMA, including because Apple does not have to support web based app downloads in Japan in the way it does under the DMA.
Broadly speaking, Apple says Japan’s MSCA does a better job of balancing openness with security and user protection than the DMA in the EU. For example, Apple does not have to support app downloads from the web in Japan like it does under the DMA. Apple retains ability to protect users from malware and other security risks. This is especially true when it comes to protecting children, as outlined below. Chance Miller - 9to5Mac
(emphasis added)
John Gruber, who was present in the same briefing as the 9to5Mac report, said Apple’s tone was even clearer than the published summary suggested. He wrote that Apple repeatedly framed the MSCA as more aligned with Apple’s privacy and security priorities than the DMA, and emphasized that Japan’s framework respects Apple’s intellectual property in ways Apple claims the DMA does not.
You can search, but you won’t find quotes from Schiller, nor any other Apple representatives, speaking of their “great respect for” and appreciation of the work they’ve done together regarding the European Commission and the DMA. [...] I was in the same briefing with Apple representatives as Miller, and I’d say Apple was more clear than that. In addition to seeing the MSCA as more aligned with Apple’s own priorities regarding privacy and security than the DMA, Apple repeatedly emphasized that the MSCA respected Apple’s intellectual property in ways that the DMA does not. Complying with the DMA is adversarial and obtuse. [...] Because of the DMA, Apple has delayed and outright withheld major features in the EU. iPhone Mirroring, one of Apple’s best new features in recent years, is still unavailable in the EU. Apple fully expects more features to be delayed or withheld from the EU as time goes on. (With Apple Watch, they’ve now been forced to remove (or perhaps better said, hamstring) a feature that existed since Apple Watch debuted in 2015.) There have been no such feature delays (let alone withholdings) in Japan" John Gruber - Daring Fireball
(emphasis added)
One group, The App Association has said:
“Addressing the negative effects of the Digital Markets Act (DMA) on small businesses has been a priority for the App Association”. “The DMA is hamstringing small tech companies in the U.S. and EU”. “In taking aim at big tech, it is causing untold collateral damage on App Association members and other small tech companies that rely on the global reach of curated online marketplaces” “Reducing security and trust in the app ecosystem will only ‘level the playing field’ for gatekeepers and large developers” The App Association
(emphasis added)
Reading this, one might become concerned that app developers are genuinely worried about stronger tech rules for Apple and Google. However, it appears that the app association is not quite as independent from Apple as it makes out:
[[Apple]] plays a dominant behind-the-scenes role shaping the group’s policy positions, according to four former App Association employees who asked not to be named discussing internal matters Bloomberg - Apple Flexes Muscle as Quiet Power Behind App Group
(emphasis added)
The App Association says it “gives a voice to small technology companies” and that its “policy priorities reflect the opportunities and challenges today’s small business app developers and IoT innovators face in the app ecosystem.” But its positions on major legislation have aligned with Apple’s. The group’s list of policy statements going back to early 2017 include some specifically praising Apple and others opposing legislation that Apple also opposes, such as antitrust bills targeting Big Tech. Jon Brodkin - Ars Technica
(emphasis added)
Washington D.C. tech industry group The App Association boldly refers to itself as, “the leading industry voice on the app economy,” and says it represents more than 5,000 app makers and connected device companies spread out around 27 countries worldwide. What The App Association’s website doesn’t say is that more than half its estimated $9 million worth of sponsorships revenues in 2020 came from one company—Apple. Mack DeGeurin
(emphasis added)
The App Association, perhaps unsurprisingly, was one of the few groups with a positive viewpoint on Apple’s and Google’s voluntary commitments in the UK:
The commitments from Apple and Google are good news for small British app developers and a sensible solution to the CMA’s concerns. [...] ‘The CMA’s consultative approach shows they have heard the concerns of our members, who reject the EU model of heavy-handed regulation where government bodies become de-facto product designers for the tech we all use daily. The App Association
(emphasis added)
The CMA needs to guarantee that any proposal it accepts, at a minimum, does not reduce the benefits from foreign digital regimes. As documented in this response, a number of these benefits have spread to the UK, and are currently benefiting UK consumers and UK businesses.
The CMA must also ensure that accepting such voluntary commitments does not weaken its ability to pursue conduct requirements in the future.
The global regulatory environment must be considered when imposing conduct requirements. Weak enforcement sets precedent for future weak enforcement, strong enforcement does the opposite.
9. Why the UK needs a General Interoperability Conduct Requirement
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.
This is in particular critical to allowing the Web to compete fairly as an interoperable alternative to Apple and Google’s native app ecosystems. Allowing browsers, and via them web apps, to compete fairly unlocks the world's best interoperable solution to app development and distribution. API access both for browsers and the web apps they power as middleware, is a critical part of making this viable. By allowing browsers to securely provide API access to the web apps they power, this disassociates that access from the conditions and fees that Apple and Google impose on developers. Providing browsers with a right to access required APIs is a key part of enabling this.
For native apps, including third-party browsers, 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)
9.1. 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
(emphasis added)
Buy your mom an iPhone Tim Cook
(emphasis added)
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
(emphasis added)
9.2. 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
(emphasis added)
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
(emphasis added)
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
(emphasis added)
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 victims of a DMA pause would be America's most innovative upstarts — especially AI start-ups. 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’s 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)
10. 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 second issue with the proposed approach is that accepting commitments may set an unintended benchmark for the acceptability of commitments in place of Conduct Requirements. In allowing these priority issues to be resolved through commitments, and noting the prominence that is associated with the first set of interventions in this investigation (and only the second interventions proposed by the Digital Markets Competition Regime as a whole), SMS firms may take encouragement that offering commitments is a viable way to resolve issues that have been identified … and it may result in increased pressure on the CMA to enforce weaker remedies in place of stronger intervention that leads to better market outcomes. Increasing the likelihood of commitments being offered as a first port of call also adds burden to the process that may slow the pace that the CMA is able to achieve effective remedies. We encourage the CMA to recognise and guard against this risk. Which? - Response
(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.
This is especially important for third-party browsers with their own engines and the open, interoperable web ecosystem they enable. Allowing that ecosystem to thrive and compete on fair terms would also reduce the regulatory burden on the CMA in relation to app stores, by placing meaningful competitive pressure on SMS app stores to moderate their fees and policies or risk losing developers. Effective API access, particularly for browsers, is essential to unlocking this ecosystem and delivering its benefits to UK businesses and 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. We recommend that the CMA team meet directly with the EU enforcement team responsible for DMA Article 6(7) and with the US Department of Justice team leading the Apple case to align on evidence, enforcement lessons, and practical remedies under the Multilateral Mutual Assistance Framework. We recommend that the CMA defer any final decisions on interoperability until these discussions have taken place and the resulting evidence, technical detail, and enforcement lessons have been reviewed and incorporated. This ensures the CMA’s approach is grounded in real-world enforcement experience and avoids predictable loopholes as well as results in remedies that are practical, measurable, and indeed enforceable.
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.
OWA would like to make the following recommendations:
- Our primary recommendation is that the CMA reject Apple’s proposed commitments and instead pursue conduct requirements that ensure genuine interoperability
- The interoperability process must be clear, detailed and have defined steps.
- Each step must have binding deadlines for Apple.
- Apple must enable a public tracker system, where developers can submit their requests and make those requests public, with public responses while reserving the ability for the developer to make confidential submissions.
- 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.
11. Toward A Brighter Future
OWA believes that the Web’s unmatched track record of safely providing frictionless access to information and services has demonstrated that it can enable a more vibrant digital ecosystem. The web’s open, interoperable, standards-based nature creates an inclusive environment that fosters competition, delivering the benefits of technology to users more effectively and reliably than any closed ecosystem.
OWA’s goal is to ensure that browser competition is carried out under fair terms, that user choice in browsers matters, and that web applications are provided equal access and rights necessary to safely contest the market for digital services.
OWA believes competition, not walled gardens, leads to the brightest future for consumers, businesses, and the digital ecosystem.
12. References
- CMA - Proposed Commitments - Call for Evidence (Cited: A, B, C, D, E & F)
- SCiDA Project - Response (Cited: A & B)
- FSFE - Response (Cited: A)
- Which? - Response (Cited: A & B)
- Sarah Cardell - the CMA’s Chief Executive (Cited: A)
- Marcus Bokkerink - Former Chair of the CMA (Cited: A)
- Enterprise and Regulatory Reform Act 2013 - Part 3 (Cited: A)
- Strategic steer to the Competition and Markets Authority (Cited: A & B)
- Viscount Camrose (Cited: A)
- Damian Collins (Cited: A)
- Digital Markets, Competition and Consumers Act 2024 - EXPLANATORY NOTES (Cited: A)
- DMCCA - Section 20 (3) (Cited: A)
- Browser and Cloud Gaming MIR - Final Report (Cited: A)
- DOJ Complaint Against Apple (Cited: A, B, C, D, E, F & G)
- Peter Fortune - UK MP (Cited: A & B)
- Coalition for App Fairness (Cited: A)
- News Media Association (Cited: A)
- Tom Smith - Former Legal Director at the CMA (Cited: A & B)
- Bruce Lawson (Cited: A)
- Apple Proposed Commitments (Cited: A, B & C)
- why API access should be free (Cited: A)
- has already had to run a specification proceeding (Cited: A)
- A proceeding that is now the target of a lawsuit from Apple (Cited: A)
- USB-C charging for iPhones (Cited: A)
- support for game emulators (Cited: A)
- NFC access for third-party payments (Cited: A)
- the new default apps page (Cited: A)
- cross-platform AirDrop support (Cited: A)
- US vs Microsoft - Finding of Fact (Cited: A & B)
- US vs Microsoft - Final Judgment (Cited: A)
- ordered a breakup remedy (Cited: A)
- Gene Burrus (Cited: A)
- DMA - Article 6(7) (Cited: A)
- Matt Mullenweg - co-founder of WordPress, founder of Automattic (Cited: A)
- Digital Markets Act - Recital 55 (Cited: A)
- DMA - Specification Proceeding - Features for Connected Physical Devices (Cited: A & B)
- Adam Fish - Founder and CEO of Ditto (Cited: A)
- Apple rolled out global support for Wi-Fi Aware (Cited: A)
- Apple - Documentation (Cited: A)
- but rather under a long running antitrust investigation in the EU (Cited: A)
- Apple kept this going for over 6 months (Cited: A
- Decision to a Specification Proceeding into Apple for Connected Devices (Cited: A
- Commission Implementing Decision (Cited: A
- a specification proceedings into Apple interop process (Cited: A
- The proposed measures (Cited: A
- specification proceeding into interop for third-party devices (Cited: A
- imposed an interoperability process on Apple (Cited: A
- this case (Cited: A)
- This case (Cited: A)
- final decision in the EU Article 6(7) specification proceeding against Apple (Cited: A)
- In this case (Cited: A)
- Commission Implementing Decision (Cited: A
- highly detailed specification decision is available here (Cited: A)
- its update here (Cited: A)
- DMCCA will be governed by the four Ps (Cited: A)
- Sarah Cardell - Chief Executive of the CMA (Cited: A)
- Section 36 of the DMCCA (Cited: A)
- DMCCA - Section 36 (Cited: A)
- House of Commons - Business and Trade Committee (Cited: A)
- Apple made $109 billion net sales (Cited: A)
- profit margin of 75.4% (Cited: A)
- $35 billion net sales from Wearables, Home and Accessories (Cited: A)
- Wired has estimated that Apple Watch has made $127B in revenue over its first decade and 281M units shipped by end of 2024 (Cited: A)
- Lily Jamali - BBC (Cited: A)
- Jacob Kastrenakes - The Verge (Cited: A)
- Jason Snell - Six Colors (Cited: A)
- Gonzalez Rogers (Cited: A)
- referred the matter to federal prosecutors for potential criminal sanctions against Apple and one of its senior executives (Cited: A)
- is WebAPK minting (Cited: A)
- Labour MP Liam Byrne - On opendemocracy (Cited: A)
- Chance Miller - 9to5Mac (Cited: A)
- John Gruber - Daring Fireball (Cited: A)
- The App Association (Cited: A)
- Bloomberg - Apple Flexes Muscle as Quiet Power Behind App Group (Cited: A)
- Jon Brodkin - Ars Technica (Cited: A)
- Mack DeGeurin (Cited: A)
- The App Association (Cited: A)
- CMA - Mobile Ecosystems Market Study (Cited: A)
- Unnamed Apple Employee (Cited: A)
- Craig Federighi - Apple's Senior Vice President of Software Engineering (Cited: A)
- Vox Media's LiQuan Hunt (Cited: A)
- Tim Cook (Cited: A)
- Steve Jobs (Cited: A)
- Steve Jobs (Cited: A)
- Phil Schiller (Cited: A)
- calls for the Competition and Markets Authority (CMA) to be “more pro-business” (Cited: A)
- Ryan Browne - CNBC (Cited: A)
- Former CMA Regulator (Cited: A)
- Luther Lowe - Y Combinator - Head of Public Policy (Cited: A)
- CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (Cited: A)
- Multilateral Mutual Assistance Framework (Cited: A)
13. Open Web Advocacy
Open Web Advocacy is a not-for-profit organization made up of a loose group of software engineers from all over the world, who work for many different companies and have come together to fight for the future of the open web by providing regulators, legislators and policy makers the intricate technical details that they need to understand the major anti-competitive issues in our industry and potential ways to solve them.
We are available to regulators, legislators and policy makers for presentations/Q&A and we can provide expert technical analysis on topics in this area.
For those who would like to help or join us in fighting for a free and open future for the web, please contact us at any of the links below.
- Mastodon: @owa@mastodon.social
- Website: open-web-advocacy.org
- X: @OpenWebAdvocacy
- LinkedIn: @open-web-advocacy
- YouTube: @openwebadvocacy
- Discord: OpenWebAdvocacy
- Website: open-web-advocacy.org
- Website: open-web-advocacy.org
