The UK's Mobile Browsers and Cloud Gaming Market Investigation Reference (MIR) has published its final report. The conclusion is clear: Apple’s “WebKit restriction”, which forces all browsers on iOS to use Apple’s engine, harms competition, stifles innovation and functionality, particularly for Web Apps.

Most importantly, the MIR recommends a complete reversal of Apple’s ban on third-party browser engines. For the first time, a regulator proposes a remedy requiring Apple to allow third-party browsers to install and manage Web Apps using their own engines. This is a critical win for developers, startups, and anyone who relies on an open web.

These remedies are not just theoretical. The UK’s Competition and Markets Authority (CMA) has now launched Strategic Market Status (SMS) investigations into both Apple and Google under the new Digital Markets, Competition and Consumers Act (DMCC). Many of the MIR’s remedies, including lifting Apple’s browser engine ban, have already been integrated into the SMS investigations, signaling the CMA’s clear intent to enforce them swiftly once designation is complete, which is set to happen within nine months.

This report is a landmark moment for web and browser competition. While there is still work ahead, this marks strong action by yet another country's regulator to restore fair competition between browsers and between Web Apps and native app stores. Open Web Advocacy is proud to have played a role in this process and remains committed to seeing these remedies fully implemented. We would like to thank the CMA and the MIR team for their tireless work over the last 4 years. We would also like to thank every developer, business, and supporter who helped make this possible. Together, we are one step closer to an open web that can compete effectively.

Conclusions

The report (which is more than 600 pages) contains a number of significant conclusions which we have split by section. We haven’t covered everything that the report lays out.

Apple’s WebKit Restriction

We conclude that the WebKit restriction means that there is no competition between browser engines on iOS.

We also conclude that the WebKit restriction harms competition in the market for mobile browsers on iOS.

We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to improve the performance of their mobile browsers on iOS.

We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to innovate and improve their mobile browsers on iOS.

We conclude that Apple’s WebKit restriction increases costs of rival browser vendors as it requires them to develop and maintain an additional version of their mobile browser, based on WebKit, to serve iOS users.

We conclude that this reduces the features available to consumers and web developers, and limits effective competition between browser vendors on iOS on security, privacy, and performance.

We conclude that the WebKit restriction does not give rise to rivalry-enhancing efficiencies in mobile browsers on iOS that would offset the negative effects on competition associated with the WebKit restriction we have identified

We conclude that the WebKit restriction therefore limits the features available to users and decreases competition between mobile browsers on privacy features on iOS. MIR’s Final Report

We wholeheartedly agree with the MIR’s conclusion that the WebKit restriction limits users’ choice, raises costs for developers and browser vendors, reduces the features and performance available to both users and developers, and undermines browser competition on iOS.

Apple Security Justification for Banning Rival Browser Engines

Although the evidence provided by Apple shows that fragmentation is a problem on Android, and increases the risk of n-day attacks, we note that the appropriate benchmark to the WebKit restriction is not one where there are no restrictions placed on browser vendors to manage the risk from fragmentation. Instead, Apple could use alternative safeguards, such as managed entitlements, or requirements for browser vendors to update their browser engines in a timely manner, to reduce the risk from fragmentation.

Second, as described above, Apple has submitted that WebKit has certain security advantages as a browser engine on iOS compared to any potential alternative browser engines, given integration between software and hardware, coordination between Apple’s engineering functions, and Apple’s ongoing security analyses.

However, we note that as part of the measures Apple has announced in response to the DMA, Apple has made some of these security features available to other browser engines, such as Pointer Authentication Codes, demonstrating that benefits of hardware integration could potentially be extended to other browser engines.

Evidence also indicates that all the major browser engines take a stringent approach to testing for and fixing security vulnerabilities. Apple’s submissions that it is the only browser engine developer that could be trusted to perform this function on iOS therefore seems weak.

Although some of the evidence cited above is from several years ago, it nonetheless indicates that alternative browser engines undertake security testing at a similar level to Apple, and we have not seen evidence to suggest that this has changed since then.
MIR’s Final Report

We are delighted that the MIR team has seen through Apple’s plausible-sounding but ultimately weak arguments that only they can be trusted to implement a browser with its own engine on iOS. In particular their refutation of the argument that Safari would have superior security due to a refusal by Apple to share certain iOS hardware security APIs such as Pointer Authentication Codes. This argument has been undone by the EU’s Digital Markets Act forcing Apple to share this functionality.

Web Apps

New features and improvements are a key parameter of competition between browsers. We conclude that by preventing, or making it more difficult, for browser vendors to implement new features and improvements, Apple’s WebKit restriction limits the ability of rival browser vendors to compete on iOS. We have seen evidence of limitations impacting security, privacy, and performance improvements, and support for other features, notably those important for web apps and PWAs.

We consider that limited competition in the markets for browser engines and mobile browsers on iOS has led to worse outcomes for web developers than we would expect in a well-functioning market. There is evidence that WebKit has been slower to support new mobile browser features, particularly in relation to web apps, and that this is a particular concern for developers interested in more innovative features such as those for web apps.
MIR’s Final Report
(emphasis added)

We agree with the MIR team’s assessment that the WebKit restriction has been particularly damaging to the feature set and performance of Web Apps and that this is the result of it limiting competition in the markets for mobile browsers on iOS.

Safari Self-Preferencing

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.
MIR’s Final Report

While a more minor issue compared to the total ban on porting browser engines to iOS, we agree with the MIR team that Apple should not be able to reserve iOS functionality for Safari or delay sharing it with third-party browsers.

Apple-Google Search Deal

We conclude that the ISA revenue shares are significant and that therefore their impact on Apple’s and Google’s financial incentives to compete in the supply of mobile browsers on iOS is also significant.

We conclude that the ISA revenue sharing arrangements significantly reduce Apple’s and Google’s financial incentives to compete, including via investing in Safari and Chrome respectively, and therefore adversely impact competition in the supply of mobile browsers on iOS.

We conclude that the ISA does not give rise to rivalry-enhancing efficiencies that are able to offset the negative impact on competition of the ISA’s revenue-sharing provisions.
MIR’s Final Report

For those wanting more details about the Apple-Google Search deal (ISA), worth $20 billion annually, the report is often hilariously (and annoyingly) vague due to confidentiality:

Screenshot of a report. It states 'In relation to Apple's submission we note that', followed by 3 redacted dotpoints. Then it states 'In relation to Google's submission we note that', followed by 3 redacted dotpoints.
Screenshot of section of MIR Final Report on the Apple-Google Search Deal

However, we entirely support the MIR in their assessment that Google paying Apple for Google Search Revenue in iOS Chrome significantly undermines browser competition. We would go further and say that this is bordering on a non-compete agreement for browsers on iOS between Apple and Google.

Choice Architecture on iOS

We conclude that Apple’s practices of pre-installing only Safari contributes to low user awareness of other mobile browsers.

We conclude that the added friction involved in accessing a third-party browser app impacts usage and retention and that differences of approach to the placement of Safari and alternative mobile browsers on a device home screen limit the ability of rival mobile browsers to compete with Safari on iOS.

We conclude that Apple’s choice architecture practices in the device factory settings that are presented to users when they first use a new mobile device, limit mobile browser competition on iOS.
MIR’s Final Report

We agree with these assessments and support the proposed remedies such as a choice screen on start up and granting the chosen browser a spot in the hotseat/dock.

We conclude that users’ inability to uninstall Safari is unlikely to impact users’ ability to download an alternative mobile browser given that users are able to remove Safari from the default home screen, and therefore, this is unlikely to limit competition between mobile browsers on iOS.
MIR’s Final Report

This is disappointing, as it would have been easy to implement, especially since the DMA already requires it. We believe that allowing Safari (and Chrome on Android) to be uninstalled is important psychologically as it indicates to users it is just another app that can be replaced.

Note the operating system webview, i.e., WkWebView and Android WebView do not need to be uninstallable.

In-App Browsers

We conclude that Apple’s ban on alternative browser engines for in-app browsing on iOS reduces competition in the market for the supply of in-app browsing technology on iOS as it prevents app developers such as Meta from introducing an IAB based on an alternative to Apple’s WKWebView.*
MIR’s Final Report

Our viewpoint on this is complex and not easily summarized.

The MIR has approached the issue on in-app browsers from the view that app developers should be able to choose which browser (and which browser engine) handles outbound links to third-party websites clicked on in that non-browser app.

Our view is that the user's chosen browser (i.e. their default browser) should always handle those links and at the very least the app should have to ask permission to override the users default browser.

We consider that remote tab IABs would be similar to SFSafariViewController in that they are low-cost and easy-to-implement for the app developer. Remote tab IABs would, therefore, represent an avenue via which alternative in-app browsing technology providers such as browser vendors could exert competitive pressure on Apple’s own in-app browsing technology offering

We further note that enabling remote tab IABs on iOS would also provide the option for app developers to call upon a user’s default browser for in-app browsing if they wish

Second, the inability of browser vendors to offer remote tab IABs also harms their ability to compete in the market for mobile browsers on iOS as it prevents them from accessing a sizeable and likely growing proportion of web traffic. Indeed, offering remote tab IABs would allow browser vendors to benefit from this traffic, which would translate into increased usage (and better web compatibility with their underlying browser engine), would drive increased engagement with and brand awareness of their browsers, and would allow them to support their existing customers better by providing a more ‘consistent’ web browsing experience on the device. This would increase competitive pressure on browsers on iOS, including Safari.
MIR’s Final Report

We raised a key concern that SFSafariViewController is effectively hardwired to Safari, unlike Android Custom Tabs, which, unless explicitly overridden, respects the user’s default browser choice. Our proposal to the MIR team was straightforward: Apple should be required to upgrade SFSafariViewController so it always uses the user’s default browser, while Google should be prohibited from hard-coding Android Custom Tabs to Chrome in apps like the Android Google Search app.

The user’s choice of default browser is meaningless if non-browser apps can ignore it when opening web links. If links from apps don’t open in the default browser, then what exactly is being defaulted?

You can read our full paper here.

WebAPK Minting

The above evidence does not show that Chrome has greater access to functionalities required to implement user-facing features relative to third-party mobile browsers, with the exception of WebAPK minting. However, given the availability of alternative methods for installing web apps on Android, our view is that this does not impact competition. For the other functionalities considered, the evidence suggests that third-party mobile browsers have equivalent access.
MIR’s Final Report

This is disappointing, and we disagree with the MIR team's assessment. Alternative methods for installing Web Apps do not integrate well with Android, as evidenced by Google needing to implement WebAPK minting for Chrome. We do not believe that Google should be able to reserve important functionality for its own browser. We have written extensively about this topic and will continue to advocate to force Google to share WebAPK minting under the DMCC.

DMCC and MIR Remedies

We conclude that a recommendation to the CMA Board in the manner expressed in the Our remedy sub-section above is the most appropriate way to address effectively and comprehensively the AECs we have identified.
MIR’s Final Report

In our response paper we were concerned that there could be a significant delay caused by the MIR not using its powers to fix the most critical issues it had identified. That said, we understood the appeal of the DMCC ability to monitor and enforce requirements. We proposed implementing the most critical remedies now using the MIR’s powers and having the DMCC as a monitoring and enforcement body.

OWA suggested implementation of a minimum ‘core set of the most critical remedies’ (eg to address the WebKit restriction) at the conclusion of the market investigation. Once the DMCC Act was in force, the DMU could take over responsibility for ongoing enforcement, addressing any remedies that have been ‘bypassed or whose objectives remained unfulfilled’.
MIR’s Final Report

We are deeply appreciative of the MIR team's detailed and convincing arguments as to why handing on these recommendations onto the CMA to implement under the DMCC will be effective, less risky and not result in significant delay. This is significantly strengthened by the CMA’s investigation into Apple’s and Google’s Strategic Market Status (SMS) directly incorporating the MIR’s core recommendations, making it clear the CMA intends to act quickly once designation is complete, expected within nine months.

In any event, we do not consider that interventions which the CMA may decide to impose under the DMCC Act powers would necessarily take significantly longer to implement than the remedies which could be imposed via the EA02 remedy-making powers. In particular, we note that:

(a) As set out in the Digital markets competition regime sub-section above, the CMA commenced SMS designation investigations on 23 January 2025 to assess whether to designate Apple and Google with SMS.

(b) The DMCC Act allows for SMS designation assessments to be conducted in parallel with designing CRs, meaning that they could in principle be imposed at the end of a designation investigation, which is subject to a nine-month statutory deadline. In this context, we note the CMA’s stated intention to start considering potential interventions in parallel with its work on whether to designate Apple and/or Google, whilst recognising that any decisions on such interventions will be dependent on the designation decisions.

(c) Remedies imposed by orders or undertakings following a market investigation may, depending on their complexity, also take some time to devise and implement. The EA02 provides for a remedy implementation phase to make the order or accept undertakings of up to six months (extendable by up to four months) after the final report is published. This may then be followed by a further phase before such remedies take effect.

We consider that the likelihood of the CMA Board acting on our recommendation in a timely manner is high. In particular, and as set out above, we note that:

(a) On 23 January 2025 the CMA opened SMS investigations into Apple and Google in respect of their mobile ecosystems (including mobile browsers, browser engines and in-app browsing technology);

(b) In its ITC, published on the same day, the CMA noted that it would be able to consider this final report once it is published. MIR’s Final Report

Remedies

The MIR has proposed the CMA implement the following remedies under the DMCC:

Allowing Alternative Browser Engines on iOS

A requirement for Apple to allow use of alternative browser engines on iOS with access granted to iOS to browser vendors using alternative browser engines on equivalent terms to that made available to WebKit, Safari or third-party applications.

Equivalence of access is clarified to include:

(a) enabling access in a way which respects the technical architecture of alternative browser engines;

(b) enabling access to all of the current operating system-level features and functionalities that WebKit and Safari currently use;

(c) enabling access to all other current operating system-level features and functionalities that exist on iOS and are available for use by third-party applications, but which WebKit and Safari currently do not use;

(d) enabling access to future operating system-level features and functionalities available to WebKit, Safari, or third-party applications, whether or not WebKit and Safari choose to use them;

(e) enabling access to the required iOS functionality to allow browser vendors using alternative browser engines to install and manage progressive web apps (PWAs) using alternative browser engines; and

(f) enabling access to the required functionality to allow browser vendors using alternative browser engines to check whether their mobile browser has been set as default

Interopability Requirements for WebKit Browsers on iOS

An interoperability requirement mandating Apple to: (i) grant equivalent access to functionality used by Safari to browser vendors using the version of the WebKit engine as specified by Apple on iOS; and (ii) grant such access within a reasonable timeframe.

Allow In-App Browser to use their Own Browser Engine

(a) A requirement for Apple to: (i) allow native app developers on iOS in the UK to use their choice of browser engine for in-app browsing within their native app (a ‘bundled engine’); and (ii) provide interoperability with bundled engines for in-app browsing (‘bundled engine IAB’)

(b) A requirement for Apple to allow sufficient cross-app functionality to enable native apps to invoke third-party browsers (regardless of the browser engine they use) to support in-app browsing.

Prohibition of the Chrome Revenue Share.

A prohibition on Apple receiving a share of iOS Chrome's Google search revenue.

Various Choice Architecture Changes for iOS

(a) A requirement for Apple to ensure the use of a browser choice screen at device set-up.

(b) A requirement for Apple to ensure the placement of a default browser selected by the user in the ‘application dock’/‘hotseat’ or on the default home screen at device set-up.

(c) A requirement for Apple to ensure the use of a browser choice screen after device set-up.

(d) A requirement for Apple to share user data on default browser settings with browser vendors.

(e) A requirement for Apple to ensure that the frequency of default browser prompts and notifications is limited across multiple access points

Various Choice Architecture Changes for Android

(a) A requirement for Google to ensure the use of a browser choice screen at device set-up.

(b) A requirement for Google to ensure the placement of a default browser selected by the user in the ‘dock’/‘hotseat’ or on the default home screen at device set-up.

(c) A requirement for Google to ensure the use of a browser choice screen after device set-up.

(d) A requirement for Google to ensure that the frequency of default browser prompts and notifications is limited across multiple access points.

Note: while the document is called “Appendix D: Remedies not taken forward in this market investigation”, this is because the MIR will not implement the remedies themselves but has rather deferred this responsibility onto the CMA under the DMCC.

Timeline of Events

For those only loosely following, or just tuning in, this is the culmination of a multi-year series of regulatory events which OWA has been heavily involved in.

OWA was formed on the 12th of March 2021 due to dissatisfaction with the slow pace of features being added to iOS Safari and the excessive number of bugs. We realized, after a series of unsuccessful attempts to woo Apple to voluntarily start work on these features and increase Safari’s budget, that the problem was two-fold. A total absence of browser competition on iOS due to Apple’s ban of rival browser engines and that Apple was actively disincentivized to allow Web Apps to effectively compete with apps sold via their own App Store.

On the 15th June 2021, the UK’s Competition and Markets Authority (CMA) launched a market study into mobile ecosystems, attempting to assess potential sources of harm to consumers within 4 broad themes:

  • Competition in the supply of mobile devices and operating systems.

  • Competition in the distribution of mobile apps.

  • Competition in the supply of mobile browsers and browser engines.

  • The role of Apple and Google in competition between app developers.

In early October 2021 we had a meeting with the CMA to explain how effective browser competition was being prevented on iOS and how this was harming both consumers and developers by preventing Web Apps from being a viable competitor to native app stores. The meeting consisted of three presentations by Alex Moore, Stuart Langridge and Bruce Lawson. These presentations were primarily focused on iOS Safari's (and by extension all browsers on iOS) lack of support for push notifications.

Two weeks later (and after more than a decade of refusing to do so), Apple quietly began work on push notifications for iOS Safari.

On 21st of December 2021, the CMA published their Interim Report into Mobile Ecosystems. At the time they stated they were not launching a Market Investigation Reference, presumably because they were waiting for new powers under the DMCC bill.

In this report the CMA came to several critical conclusions including:

As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer (to the extent that they are governed by the browser engine as opposed to by the UI).

Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from.
Interim Report into Mobile Ecosystems
(emphasis added)

They also noted that Apple has two perverse incentives to hold back WebKit and to hinder Web Apps’ ability to compete with the iOS App Store:

First, Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. Safari has a strong advantage on iOS over other browsers because it is pre-installed and set as the default browser. The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari (for example being less able to accelerate the speed of page loading and not being able to display videos in formats not supported by WebKit). As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google.

Second, and as discussed in Competition in the distribution of native apps, Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues. Interim Report into Mobile Ecosystems
(emphasis added)

You can see our response to the report here. Including our Walled Gardens Report where we laid out the case that Apple’s ban of third-party browser engines was effectively a ban on third-party browsers.

In addition to our own response, a large number of developers wrote in, many answering our call to submit their views. You can read their responses expandable below:

Developer Responses

We are deeply grateful for this as it gave the case for pursuing remedies to fix browser and Web App competition immense weight.

The CMA issued their Final Report into Mobile Ecosystems on the 10th June 2022 and announced it was considering opening a market investigation reference (a serious investigation where the CMA has strong evidence of anti-competitive behaviour and sets out to fix it).

On the 22nd of November 2022, the CMA announced it had decided to launch a Market Investigation Reference into Browser and Cloud Gaming.

In their reference decision they listed the following potential remedies:

  • removing Apple’s restrictions on competing browser engines on iOS devices;
  • mandating access to certain functionality for browsers (including supporting web apps);
  • requiring Apple and Google to provide equal access to functionality through APIs for rival browsers;
  • requirements that make it more straightforward for users to change the default browser within their device settings;
  • choice screens to overcome the distortive effects of pre-installation; and
  • requiring Apple to remove its App Store restrictions on cloud gaming services.

They then published an issues statement on 13th of December 2022. You can read our response to the issues statement here.

On the 31st of March 2023, the MIR was suspended following a Competition Appeal Tribunal judgment and order. Unfortunately, they delayed starting the investigation while waiting to see if the UK government was going to pass new laws granting them stronger powers to deal with anti-competitive behaviour by tech giants. These laws were working their way through parliament at the time and were expected to be passed into law in 2024.

Due to this, Apple managed to successfully get the MIR dismissed, not by arguing before the tribunal that the CMA was substantially wrong about any of its anti-competitive behaviour, but on the legal technicality based around the timing of the opening of the investigation.

As a result of this, the MIR was paused. It remained suspended for almost 9 months. The CMA appealed the decision and on the 1st of December 2023 London's Court of Appeal overruled the Competition Appeal Tribunal's decision and stated that the MIR could be reopened.

In June and July 2024 the MIR published a series of 6 extremely detailed papers covering their findings:

You can read our response here.

Following this the MIR team published their 7th paper, detailing remedies. You can read our response paper here.

While the paper contains a number of excellent remedies, not least of which is prohibiting Apple from banning browser engines from iOS, we were deeply concerned that the MIR will fail in its goal of allowing third-party browsers to enable effective competition from Web Apps.

This goal was highlighted in the opening statement in the MIR:

We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete. Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority
(emphasis added)

Specifically, we were concerned there was no remedy that would allow browsers to install and manage Web Apps using their own engine. That is, Apple would be able to lock all browsers (including ones with their own engine) into using their current WebKit implementation of installed Web Apps. We wrote an article at the time titled: “UK’s Browser and Cloud Investigation may fail to allow Web App competition” explaining our concerns and asking interested parties and developers to write in.

On the 22nd of November 2024, the MIR team published their Provisional Decision Report.

We are delighted to say that the MIR team has listened to both us and all of the many many businesses and web developers who wrote in. A huge thank you to every developer and business that took the time to write in and explain their concerns, it really makes a difference!

For example, ‘equivalence of access’ would need to include enabling third-party browsers using alternative browser engines to install and manage PWAs (rather than relying on WebKit to support parts of this process), including enabling mobile browsers using alternative browser engines to implement installation prompts for PWAs.
MIR - Provisional Decision Report

While a very crude measure, “web app” went from being mentioned 5 times in the remedies paper to 300 times in the provisional decision report.

Additionally, the MIR team stated that they were not intending to implement any remedies directly but would make recommendations to the CMA to be implemented under the DMCC.

You can read our response to the provisional decision report here.

The Digital Markets, Competition, and Consumers Act (DMCC) 2024 came into effect on the 1st of January 2025, granting the UK regulator authority to designate companies with Strategic Market Status (SMS). This can be thought of as the UK’s equivalent to the EU’s Digital Markets Act, although it has differences in how it is implemented as covered in this article.

On the 23rd of January 2025, the CMA opened an investigation to designate Apple and Google as having SMS status under the DMCC. You can see their request for comment here and our response here.

Importantly the key remedies from the MIR appear directly in the SMS, indicating the CMA intends to tackle them immediately upon successful designation. Designating Apple and Google will take approximately 9 months and should be completed before the end of 2025.

This brings us to the present and the MIR’s Final Report, published on March 12, 2025, exactly four years since OWA’s founding and after four years of near-continuous advocacy.

Takeaway

The remedies set out in the final report are pivotal, with the most critical being a full reversal of Apple’s browser engine ban. Importantly, the report includes a specific remedy ensuring that third-party browsers can install and manage Web Apps using their own engines, an essential step toward restoring competition between Web Apps and gatekeepers' app stores.

We want to extend our deepest thanks to the MIR team for their tireless work over the past 15 months on an issue that is both technically complex and highly nuanced. While we may differ on a few sub-topics, there is no question that these recommendations will have a profound, lasting and positive impact on the mobile browser and Web App markets.

These remedies have not been set aside. Many of them have been carried directly, almost word for word, into the CMA’s SMS investigations into Apple and Google. We call on the CMA, under the DMCC regime, to swiftly designate both companies with Strategic Market Status and move quickly to implement these critical remedies.

This has always been a long fight, but this report marks a major victory on the path toward fair and open browser competition. We are incredibly grateful for the support we’ve received, both financial and volunteer, and we remain committed to seeing this through. We’ll keep pushing until browsers and Web Apps can compete on a level playing field across all operating systems, everywhere.