TL;DR: A lot happened in 2025 for browsers and web apps with new investigations, laws, and court cases across the EU, Japan, the US, Australia, and the UK. OWA continues to play a key role in pushing for fair and effective browser and web app competition on all platforms. Apple is now barred from blocking third-party browser engines on iOS in 28 countries, soon likely 30. However, it continues to resist real competition. Learn what is happening worldwide and how you can help!

2025 in Review. We review everything for OWA in 2025 and what’s coming up! The whole team would like to thank everyone who joined us by volunteering or donating to fight for the future of the web! With big steps in 2025, we can’t wait to see what we can do together in 2026!

As the calendar turns and we step into 2026, it's a perfect moment to reflect on 2025’s developments, achievements, and what lies ahead regarding regulators, browsers, and web applications. The momentum we have built over the past year did not happen by accident. It was shaped by persistence, collaboration, and a shared belief that the open web deserves to be allowed to compete fairly.

Looking back on 2025, the pace was relentless. Through it all, meaningful progress was made, not in theory, but in real outcomes that strengthen the ecosystem we all depend on. While it is a long road to fair and effective browser and web app competition, change is happening.

The lesson from 2025 is clear. When those who love what makes the web amazing come together, we can achieve wonders!

We would like to thank everyone who contributed their time or financial support to this cause. None of this would be possible without you.

If you love what we're doing and would like to support our work, please consider making a donation.

OWA is a registered not-for-profit fighting for the Web against heavily financed gatekeepers to ensure the future of Browser competition and Web Apps

OWA has so much more work to do advocating for the web all over the globe. We will always need your support, and you can do that in many ways:

What is OWA?

Open Web Advocacy is a not-for-profit whose mission is to educate regulators, policymakers, businesses, and the public on the intricate technical details they need to understand both the major anti-competitive issues affecting browsers and web apps and the promise of a more open and competitive future enabled by capable web apps.

We aim to allow both browsers and web apps to compete fairly on all operating systems. At the heart of this is ending Apple’s longstanding ban on third-party browser engines on iOS.

We do this by talking to regulators all over the world including in the EU, the UK, Japan, the US and Australia. We also produce educational content and talks with the aim of explaining key issues that are holding back the mobile web and how to fix them.

We believe that as a direct result of our work the following achievements have been made:

The Web could be an outstanding mobile application platform. It already dominates on desktop, where more than 70 percent of user time is powered by web technologies. It offers so many innate advantages: build once with a single code base, run smoothly on every operating system, enjoy strong security, high performance, broad interoperability, and freedom from gatekeepers. No fees from operating system gatekeepers. No app store rules. No app review. Consumers win through higher quality, more secure, more private and cheaper software. Developers win by having a direct relationship with their customers free from gatekeeper fees, censorship and control.

Yet this future is being prevented by anti-competitive practices. If we work together, we can change that and create a world where the Web can finally compete on equal terms across all platforms

The EU

The Digital Markets Act

In the EU, the landmark Digital Markets Act came into force on 7th March 2024.

It contained 3 incredibly important passages for browsers and web apps.

First, prohibiting browser engines is banned:

Article 5(7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services. Digital Markets Act - Article 5(7)
(emphasis added)

Second, the DMA explicitly states why gatekeepers can not ban third-party browser engines: Gatekeepers should not be able to dictate the functionality of web apps:

When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users. Digital Markets Act - Recital 43
(emphasis added)

Third, gatekeepers must provide access to all the same APIs that are available to the gatekeepers own apps and services. This access may be subject to strictly necessary, proportionate and justified security conditions:

Article 6(7) 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. Digital Markets Act - Article 6(7)
(emphasis added)

Finally the DMA comes with real teeth. It grants the Commission the power to fine gatekeepers found not to be in compliance up to 10% of global revenue, which in Apple’s case would be up to $39 billion USD per offence.

Apple, however, is taking a belligerent and obstructionist approach to the DMA. With a three trillion dollar market value and over 1 billion dollars a year in legal spending, Apple has legal power that outstrips that of small nations. It is also not afraid to step as close to the line of non-compliance as possible. As Apple’s former general counsel Bruce Sewell explained, the strategy when he was at Apple was to steer as close to the line as possible because “that’s where the competitive advantage occurs”, and even large fines are seen as acceptable costs.

Apple's Browser Engine Ban Persists, Even Under the DMA

However, despite the DMA aiming to allow browsers to compete fairly with their own engines, not a single browser vendor has successfully ported their engine to iOS in the last 21 months.

Both Google and Mozilla began porting their browser engines Blink and Gecko respectively to iOS. Other browser vendors are dependent on these ports to bring their own engines to their browsers iOS, as their products are typically soft forks (copies with modifications) of Blink or Gecko.

However there were significant issues with Apple’s contract and technical restrictions that made porting browser engines to iOS “as painful as possible” for browser vendors.

‘Apple’s proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari [...] This is another example of Apple creating barriers to prevent true browser competition on iOS. Damiano DeMonte - Mozilla
(emphasis added)

In June 2024, we published a detailed analysis on why Apple was not in compliance with the DMA and why it would be difficult for any browser vendor to port under these conditions.

In June 2025, we followed up with a paper outlining in detail the exact barriers that Apple had put in place and why their solution was still not in compliance with the DMA. We also had the opportunity to question Apple directly on this at the DMA workshop.

Many of Apple’s barriers rely on vague security and privacy grounds for which Apple has published no detailed technical justification for both their necessity and proportionality. As the US’s Department of Justice wrote in their complaint:

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

At the DMA workshop this year, we directly raised with Apple the primary blocker preventing third-party browser engines from shipping on iOS. Apple claimed that vendors like Google and Mozilla have “everything they need” to ship a browser engine in the EU and simply "have chosen not to do so”.

We recognize under the DMA that we've been forced to change. And we have created a program that keeps security and privacy in mind, that keeps the integrity of the operating system in mind, and allows third parties to bring their browser engine, Google, Mozilla, to the platform. And for whatever reason, they have chosen not to do so. Kyle Andeer - Apple - Vice President Apple Legal
(emphasis added)

Apple has been fully aware of these barriers since at least June 2024, when we covered them in exhaustive detail. Multiple browser vendors have also discussed these same issues with Apple directly. The suggestion that Apple is unaware of the problems is not just ridiculous, it’s demonstrably false. Apple knows exactly what the issues are. It is simply refusing to address them.

The most critical barriers that continue to block third-party engines on iOS include:

  • Loss of existing EU users: Apple forces browser vendors to create entirely new apps to use their own engine, meaning they must abandon all current EU users and start from scratch.

  • Web developer testing: Apple allows native app developers outside the EU to test EU-specific functionality, but offers no equivalent for web developers to test their software using third-party browser engines on iOS. Apple stated during the workshop to expect updates here but has provided no details since.

  • No updates on long trips outside EU: Apple has not confirmed they will not disable browser updates (including security patches) if an EU user travels outside the EU for more than 30 days. This, far from being a security measure, actively lowers users' security by depriving them of security updates.

  • Hostile legal terms: The contractual conditions Apple imposes are harsh, one-sided, and incompatible with the DMA’s requirement that rules for API access can only be strictly necessary, proportionate security measures.

Apple has addressed two of the issues we raised in our original paper:

However, the most critical barrier remains firmly in place: Apple still forces browser vendors to abandon all their existing EU users if they want to ship a non-WebKit engine. This single requirement destroys the business case for porting an engine to iOS. Building and maintaining a full browser engine is a major undertaking. Requiring vendors to start from scratch in one region (even a region as large as the EU), with zero users, makes the investment commercially nonviable.

Instead, transaction and overhead costs for developers will be higher, rather than lower, since they must develop a version of their apps for the EU and another for the rest of the world. On top of that, if and when they exercise the possibility to, for instance, incorporate their own browser engines into their browsers (they formerly worked on Apple's proprietary WebKit), they must submit a separate binary to Apple for its approval. What does that mean exactly? That developers must ship a new version of their app to its customers, and 'reacquire' them from zero. Alba Ribera Martínez - Lecturer in Competition Law and Digital Markets
(emphasis added)

OWA at the EU Parliament

In October, OWA was invited to attend and give a short speech on our views of Apple’s compliance with the Digital Markets Act (DMA) at a meeting with the Working Group on the Implementation of the Digital Markets Act.

In our speech we argued that the Web was critical to EU society and that Apple was not complying with the DMA.

The open web is essential to a free European society. It enables every EU consumer and business to connect and transact without living under the thumb of tech giants. Its strength is that it is ubiquitous, built on open standards and free from gatekeeper control. If you want to reach users on every device without gatekeepers telling you how to run your business, the web is your only choice.

Apple understands well the power of the open web, in fact, they launched the iPhone with the key promise of having a 'full browser'.

But now, on Apple’s mobile operating system, the Web is blocked from reaching its full potential. Apple prevents third-party browsers from using their own engines, underinvests in its own browser Safari, and hides the option to install web apps that compete with its own app store. [...]

Take third-party browser engines on iOS. Nineteen months after the start of DMA compliance, they are still missing. Apple requires browser makers to restart from zero users if they want to use their own engines, and at one point blocked browser vendors from even testing their own browsers outside the EU. It is still unclear whether these browsers will continue to work when EU users travel. These conditions and many others make it impossible for competitors to invest in porting their engines to iOS.

This means that EU consumers and EU businesses lose. They lose by having lower quality, less interoperable browsers with poorer support for web apps. This in turn denies a competitor to both Apple’s and Google’s app stores, which raises costs and lowers quality, and damages security and privacy across the entire mobile app ecosystem. OWA - At EU Parliament Working Group

You can read our full speech here.

EU Successes

At the recent DMA workshop, Apple claimed they would not "export a European law to other jurisdictions". However, Apple has, in fact, already extended several EU-driven regulatory benefits globally, including USB-C charging for iPhones, support for game emulators, NFC access for third-party payments, the new default apps page, no longer hiding the option to change default browser if Safari was already the default, and most recently cross-platform AirDrop support.

These benefits are real, they are tangible and they are spreading globally.

DMA - Apple Court Cases

Apple is taking the EU Commission to court in three separate court cases related to Article 6(7).

Designation
In this case (still ongoing) Apple is taking the EU Commission to court claiming the following points:

  1. Article 6(7), the article imposing interoperability requirements, which Apple argues is illegal due to being disproportionate under the European Charter of Fundamental Rights.

  2. Apple in fact has 5 app stores, not one. i.e. the App Store on iOS, iPadOS, WatchOS, VisionOS and MacOS are distinct.

  3. iMessage isn’t a number-independent interpersonal communications service.

Apple’s claim to have multiple App Stores is despite the fact that users use the same Apple account across all of them, and pay once for apps on all of them. As well as this, developers upload and update their apps to all of them in a single process.

Apple is also challenging iMessage’s classification as a number-independent interpersonal communications service, despite the fact that you can use iMessage without a phone number, and despite the EU Commission having already decided against designating it as a gatekeeper.

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.

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.

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.

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)

For example, in relation to interoperability for third-party devices, Apple slow-walked their request process for over 9 months. The requests mentioned date back as far as March 2024, yet Apple neither implemented nor formally rejected them. 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)

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.

Under the DMA, Apple can attach security measures when it opens up access to a particular feature in order to protect the integrity of the operating system. However, these must be justified by Apple and must be objective. This document has a lot of discussion as to exactly what this means.

If you are a third-party company or developer that requires functionality that Apple currently reserves for itself in the EU to make your apps or devices better (or possible), then you can follow this process and make an interop request. All of these requests can be done at a non-legal technical level, as simple technical requests for required functionality. Apple is not allowed to ignore these requests and must respond in writing within the above time limits.

Apple is arguing in their court case that:

  1. These requirements are disproportionate under the European Charter of Fundamental Rights.

  2. The European Commission exceeded the limits imposed by Article 291 TFEU.

  3. That the Commission misapplied Article 6(7) of the DMA.

  4. 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.

  5. Apple should not have time limits imposed on it for each step in the interop process.

  6. Developers should not be able to request a technical reference from Apple to discover what undocumented functionality is available to request interoperability with.

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

You can read the highly detailed specification decision here and its update here.

It is this specification proceeding that has led to globally available support for AirDrop between iOS and Android.

Google Choice Screen Hotseat

While Google does allow browser vendors to compete with their own engines on Android, they have undermined the effectiveness of the EU browser choice screen by not granting the chosen browser the hotseat.

On iOS in the EU, selecting a third-party browser from the choice screen replaces Safari in the hotseat (dock), ensuring the user’s choice is respected. This change has already led to meaningful gains in market share; Mozilla, for example, saw its daily active users double in France and Germany on iOS, where the hotseat change is implemented. DuckDuckGo’s findings suggest that replacing Safari in the hotseat boosted the iOS choice screen’s effectiveness by a factor of nine. Yet Google refuses to make an equivalent change on Android, relying on an unreasonably narrow and, in our view, incorrect interpretation of the Digital Markets Act. Even when users choose a different browser, Chrome remains prominently placed, undermining their decision and steering them back toward Google’s own product.

We directly questioned Google on this at the DMA workshop. Read this article for our full analysis.

WebAPKMinting

For over 8 years, Google has failed to keep its commitment to share the ability to install web apps with third-party browsers on Android, despite public requests from Samsung, Microsoft, Brave & Kiwi browser.

In 2015, Google introduced a method on Android to install web apps and subsequently replaced it with a better system called "WebAPK minting" in 2017. This system allows Chrome on Android to install web apps that integrate well with the operating system. At the time, now more than 8 years ago, Google promised to share this with third-party browser vendors. However, as of today this functionality is still exclusive to Chrome on most Android devices (Note: Samsung has implemented their own version for Samsung Internet on Samsung devices).

QUESTION: I am a developer of another browser on Android, can I have this seamless install process?

We are working on it. We are committed to making this available to all browsers on Android and we will have more details soon. Google

A WebAPK is a thin wrapper Native App that provides a splash screen, system launcher integration, and system settings configuration points. When launched, a WebAPK essentially starts a tab in the browser which installed the WebAPK, loading the specific URL the web app developer configures. Google has implemented this API using Google Play Services.

All native apps on Android are packaged as APKs, either via an app store such as Google Play or via sideloading. WebAPKs allow web apps to be integrated into the OS for the purposes of discoverability, permissions management, shortcut creation, registering urls with the operating system (so links will open in the web app instead of a browser tab) and uninstallation. This means that web apps installed as WebAPKs are able to be shown in Android’s app drawer and search, system app pages such as apps, storage, screen time and battery usage, and shown without a browser badge.

Android’s security model is built around signed native APKs. In order for web apps to integrate properly on Android without significant architectural changes, web apps need to be wrapped in a signed native APK. This allowed Google to support web apps across existing versions of Android without having to introduce a new architecture to support web apps and wait for years for it to be updated.

Is Google Obligated to Share It?

Under Article 6(7) of the DMA, Google is obligated to share operating system APIs available to its own services with third-parties free of charge. In the recent DMA workshop it was clarified by the Commission that Google Play Services APIs were considered operating system APIs under the DMA. Thus, WebAPK Minting is an operating system API which Google is exclusively granting to Google Chrome in violation of Article 6(7).

OWA has been pushing for this functionality to be shared in multiple jurisdictions and published a paper outlining this issue in more detail. Google is clearly obligated to share this functionality in the EU and Japan.

The UK’s MIR unfortunately disagreed with us in their final report on this specific issue, however we will continue to push for it to be fixed under the DMCC.

The EU Should Open a Proceeding into Apple under the DMA

Apple is not complying with the DMA in relation to browsers, browser engines and web apps. The EU Commission has given Apple ample time to remedy their compliance and has had sufficient time (21 months) to see that the act will not be effective in these goals under the current compliance Apple has implemented.

The EU Commission should open a preceeding into this and compel Apple to comply with Article 5(7) of the DMA. These changes will finally allow browser vendors and the Web to compete fairly on iOS.

The UK

The UK was particularly busy this year with a new law, investigations closing and new ones opening. OWA has worked with the UK’s Competition and Markets Authority (CMA) for the last four years across 3 separate investigations. You can read a full timeline of our involvement here.

We are incredibly thankful for the hard work and dedication the CMA has shown in pursuing an issue that, while critical to mobile software development, is so densely technical. Their hard work looks set to finally pay off under the DMCC, which will finally grant the CMA the power to fix the wrongs that both the mobile ecosystem investigation and the mobile browsers and cloud gaming market investigation reference identified.

DMCC

First the Digital Markets, Competition, and Consumers Act (DMCC) came into force on 1st January 2025. This act grants 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. The DMCC mostly leaves it up to the CMA to decide what rules are appropriate to impose; the DMA dictates its rules with significantly less room for flexibility.

Firms with Strategic Market Status designation will be required to adhere to one or more tailored conduct requirements. The DMCC Act provides a structured framework for the Competition and Markets Authority (CMA) to follow when implementing these requirements.

Non-compliance with a conduct requirement could result in substantial penalties, amounting to up to 10% of the company’s global turnover.

Only the largest companies can be designated: those with turnover greater than £1 billion in the UK or £25 billion globally, thresholds introduced “to make clear that smaller firms will not be in scope”.

MIR Investigation Ended

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)

This year the UK's Mobile Browsers and Cloud Gaming Market Investigation Reference (MIR) came to a close.

They published its final report in March. The conclusion was 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 recommended 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.

The report (which is more than 600 pages) contains a number of significant conclusions including:

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.

SMS Investigation

In order for a company to have a code of conduct imposed on it by the DMCC, it must first be designated as having Strategic Market Status.

In January 2025, the CMA launched such an investigation into both Apple and Google with respect to their mobile ecosystems. You can read our response to Apple’s SMS investigation here and our response to the proposed decision here.

On the 22nd of October 2025, the CMA formally designated both Apple and Google as having Strategic Market Status. We analysed in depth what this might mean here.

The SMS investigation reaffirmed many of the findings of the previous mobile ecosystems and MIR.

During the SMS investigation, the CMA discussed a number of potential obligations it may impose on Apple and Google in relation to browsers, browser engines and web apps.

They were:

  • “A requirement for Apple to provide equivalent access to functionality for browsers using alternative browser engines.”

  • “A requirement mandating Apple to provide equivalent WebKit access for all WebKit-based browsers on iOS.”

  • “A requirement for Apple in respect of in-app browsing to provide interoperability with bundled engines for in-app browsing and allow sufficient cross-app functionality to enable third-party browsers to provide in-app browsing in native apps.”

  • “A requirement for Apple not to enter into agreements with Google where it receives search advertising revenues connected to the use of Chrome on iOS.”

  • “A requirement for Apple and Google to make changes to choice architecture for browsers.”

  • “A requirement that prevents Google from making payments to OEMs and its licensing of its first-party apps and proprietary APIs conditional upon the prominent display and specific default-settings for Google Chrome on Android devices.”

  • “A number of the above requirements would need to be complemented by ensuring Apple: (i) permits browser apps to use alternative browser engines; and (ii) enables browser vendors using alternative browser engines to install and manage progressive web apps.”

According to the CMA these interventions could lead to greater browser and web app competition:

These types of potential interventions could lead to greater competition for developing browser features related to performance, privacy and/or security which support user needs. They could also encourage greater use of web apps as an alternative to native apps accessed through a mobile app store, which could lead to lower development costs and lower barriers to entry and expansion for app developers and greater accessibility of apps by users. CMA - SMS Investigation Request for Comment
(emphasis added)

According to the CMA’s current roadmap, they will be conducting investigations into both “Requiring Apple to allow third-party browsers and app developers to use alternative browser engines on iOS and iPadOS” and “to explore the potential for Progressive web apps” in the first half of 2026. We will be reporting more on this as it happens!

Japan

In June 2024 Japan’s parliament passed into law the Smartphone Act - officially the Bill on the Promotion of Competition for Specified Software Used in Smartphones, similar to the EU’s Digital Markets Act and the UK’s Digital Markets, Competition and Consumers Bill

The legislation was based on the Final Report by Japan’s Headquarters for Digital Market Competition, which Open Web Advocacy consulted on. Our submission is available here.

Crucially, this bill directly prohibits Apple’s long-standing ban on third-party browser engines on iOS.

In July this year Japan’s Fair Trade Commission published the Mobile Software Competition Act (MSCA) Guidelines, which clarifies how the Smartphone Act will be interpreted and enforced. In particular, for designated providers such as Apple:

  • Banning browser engines is prohibited, as are actions “preventing” their adoption.
  • There must be functionally equivalent API access for 3rd parties, subject to justifiable measures.
  • It must be easy to change the default settings of the operating system.
  • A choice screen for browsers must be provided “promptly after the first activation”.

The act came into full effect on the 18th of December this year.

We’d like to extend our gratitude to the extensive work over many years by the HDMC, JFTC and others in improving browser, browser engine and web app competition.

On December 17th, Apple published how it intends to comply with the new law with respect to browser engines. However, Apple looks set to use the same tactic it has used in the EU to avoid complying with the same provision of the Digital Markets Act for the last twenty-one months. Namely, Apple demands that browser vendors lose all their existing Japanese users and produce a brand new browser, rather than simply updating their existing users. Apple will also not allow browser vendors to use their own engine on iPadOS and other iOS variants.

Read our detailed analysis here.

DOJ vs Google

In late 2020, the U.S. Department of Justice (DOJ), in conjunction with state attorneys general representing 11 states, brought a landmark antitrust case against Google for unlawfully maintaining a monopoly in the general search engine market. In August 2024, Judge Mehta ruled in favor of the DOJ, declaring unequivocally that “Google is a monopolist, and it has acted as one to maintain its monopoly”.

We believe this ruling was correct, necessary, and that the DOJ’s case was compelling.

The DOJ then proposed an extensive list of remedies aimed at restoring competitive conditions in the market for general search engines in the United States. The vast majority of these numerous remedies the DOJ proposed seemed reasonable and proportionate. But amidst this sweeping package, two key remedies in particular had the potential to cause significant, severe, and sustained collateral damage to the web platform.

They were:

  • A total ban on search engine revenue sharing deals between browser vendors and Google.
  • A forced sale of Chrome by Google (and barring Google from re-entering the browser market for 10 years).

While we fully understood the rationale behind prohibiting search engine revenue-sharing agreements and supported the DOJ's decision to cancel the Apple-Google search deal, which undermines iOS browser competition and, with a possible 98.5% profit margin, channels only a minimal share of its value into web platform development. However, we were concerned about the unintended consequences this approach may have on smaller browsers, particularly Mozilla. Stripping Google of, at most, an additional 1.15%, and likely only 0.74%, of U.S. search traffic does not justify the risk of bankrupting a key contributor to the open web ecosystem.

THE COURT: So I mean, it seems to me Mozilla, in some sense, would have a more compelling argument than you because it's not like Apple is going to go out of business if I don't -- you know, if you can no longer get revenue share. You've got other sources of revenue; Mozilla hardly has any. UNITED STATES OF AMERICA vs GOOGLE LLC

Even more concerning was the likely collapse in web platform investment if Google is forced to sell Chrome. Google currently funds an estimated 90% of Chromium development. Chromium is the open-source project that powers a number of browsers including Chrome, Edge, Opera, Samsung Internet, Vivaldi, Brave, and many other smaller browsers. If Google is forced to divest Chrome and can no longer fund the project, that investment may evaporate overnight. Smaller browsers do not have the resources to fill that gap. In total, this could result in an estimated 70% drop in funding for the web platform, a catastrophic blow to the ongoing evolution of the web. Progress in new web features could stagnate, and the performance and stability of the web platform will deteriorate.

This in turn would harm the ability of the web to compete with the mobile app store duopoly of Apple and Google, directly undercutting the DOJ’s case against Apple, and threatening recent progress by UK and EU regulators to improve competition between browsers and between web apps and native apps. Critical efforts to port both Chromium and Gecko to iOS could have been abandoned entirely.

Our concerns were widely shared by those who work in or rely heavily on the browser technologies.

With this in mind, we wrote an extensive piece that outlined our concerns in exhaustive detail in a piece titled “Break Google’s Search Monopoly without Breaking the Web” and met with the DOJ to express our concerns.

We appreciated that the DOJ took these concerns seriously and acknowledged the importance of a viable future for Chromium and the open web in its Revised Final Judgment Proposal, which required an evaluation of the buyer’s business and investment plans, including those for the open-source Chromium project. The proposal states:

The evaluation of any potential buyer shall include the potential buyer’s proposed business and investment plans (including those for open-source project Chromium), the United States’ evaluation, at its sole discretion, of any potential risks to national security, the potential buyer’s plans for sharing and protecting user data included in the acquisition, and any other issues a potential buyer may present. Plaintiffs’ Revised Proposed Final Judgment (emphasis added)

Despite this we were still greatly concerned that these changes could be devastating to the funding of the web platform. In our paper we proposed the following potential alternative remedies:

Ultimately in September, Judge Mehta rejected both the DOJ’s ban on browser search engine deals and a forced sale of Chrome. The final remedies were significantly less forceful than both the DOJ’s and our suggested replacements.

Google will not be required to divest Chrome; nor will the court include a contingent divestiture of the Android operating system in the final judgment. Plaintiffs overreached in seeking forced divesture of these key assets, which Google did not use to effect any illegal restraints. Judge Mehta

While many were understandably disappointed that Judge Mehta did not go further in dismantling Google’s Search monopoly, and the underlying goal of the remedies was justified, we were greatly relieved that he did not inadvertently inflict vast harm on the web platform’s funding via these two remedies.

Google is reportedly planning to appeal and the DOJ has been silent on the issue but as yet to our knowledge no formal appeal documents have been filed by either party. The final judgement was entered on the 5th of December 2025. It appears both parties have 60 days to appeal, meaning the deadline would be 3rd February 2026.

DOJ vs Apple

In 2024 the Department of Justice (DOJ) launched a lawsuit against Apple arguing that they have illegally monopolized the US smartphone market. The government claimed Apple broke the law by maintaining a closed ecosystem for the iPhone in pursuit of profits and at the expense of consumers and innovation.

The essence of the DOJ case is that Apple has made iPhones worse for US consumers in order to increase lock-in, reduce interoperability and block competitors from competing. The DOJ also argues that Apple uses security and privacy as a shield to justify its anticompetitive conduct.

Apple wraps itself in a cloak of privacy, security, and consumer preferences to

justify its anticompetitive conduct. Indeed, it spends billions on marketing and branding to promote the self-serving premise that only Apple can safeguard consumers’ privacy and security interests. Apple selectively compromises privacy and security interests when doing so is in Apple’s own financial interest DOJ vs Apple

The DOJ has a number of examples of how Apple has done this, including discussing Apple's ban on third party browser engines and how lack of visibility for web apps on iOS makes them unviable.

Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content. DOJ vs Apple
(emphasis added)

One of the reasons that many users on iOS are unaware of how to install web apps is Apple has for years refused to implement install prompts and hidden away the mechanism for installing them on the share menu. At the same time, Apple has gone to great lengths to make it easy to link to and install Apple’s on iOS app store native apps from Safari.

The DOJ vs Apple case is slowly working its way through the court system. Currently the case is in the document discovery phase, which Apple has recently requested an extension till the 15th June 2026 to produce what Apple claims is over 11 million documents. This suggests that the actual trial will not start until late 2027.

Australia

In 2024, the Australian government agreed to new competition laws for digital platforms.

The new laws will be based on the ACCC's recommendations in their Digital platform Services Inquiry - Interim Report No. 5 which includes:

The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.

We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS. Digital platform Services Inquiry - Interim Report No. 5

They conducted a public consultation in early 2025. You can read our response here.

Essentially Australia is planning to implement a cross between the UK’s DMCC and the EU’s DMA with the aim of ensuring that Australian consumers and businesses can benefit from the increased competition in digital services.

A lack of competition in Australia’s digital markets can stifle productivity and innovation, reduce choices, and lead to higher prices for Australian consumers and small businesses.

Australians need mandatory codes for the most powerful digital platforms to prevent harms from a lack of competition

This lack of competition can limit growth opportunities for other firms, stifle innovation, reduce consumer choice and lead to higher prices. Examples include self-preferencing of their own products and services, exclusivity agreements, and conduct that makes it unnecessarily harder for consumers to switch to a competitor’s service.

Mandatory codes of conduct offer a flexible, targeted solution to address these harms in particular digital markets where intervention is most needed. App marketplaces / mobile operating systems and ad tech services should be prioritised. Key findings from the Digital Platform Services Inquiry Final Report

The ACCC have directly highlighted ended Apple’s ban on third-party browser engines:

The ACCC’s Regulatory Reform Report noted that Apple requires all browsers on iOS to be built using its WebKit browser engine. Further, Apple prevents WebKit from accessing certain APIs and iOS functionality, which restricts the functionality of web apps compared to native apps. As a result, the Regulatory Reform Report noted that Apple iOS users do not have the option to use browsers that can offer a wider range of innovative features and functionality. Instead, they are limited to using browsers built using Apple’s WebKit browser engine. The ACCC noted its concern that this limits the ability for web apps (which are accessible through browsers rather than through the Apple App Store) to impose a competitive constraint on native apps. Digital Platform Services Inquiry Final Report

The Australian Competition and Consumer Commission (ACCC) will gain powers to designate platforms, monitor compliance, and enforce obligations. Penalties are substantial: up to AUD$50 million, three times the benefit gained, or 30% of turnover during the breach period – whichever is greatest. App marketplaces and advertising technology will be first in line and social media may follow. [...]

The ACCC won’t wait for complaints. It will monitor designated platforms proactively, with powers to compel documents, conduct inquiries, and investigate suspected breaches. If the regulator finds non-compliance and the penalty calls for a portion of turnover during the breach period, it’s a value that scales with the size of the violation and the size of the firm. The Modern Regulator

The new law is expected to be put before the Australian parliament in early 2026.

Tim Berners Lee Supports Ending Apple’s Browser Engine Ban

In a recent interview with The Verge, Sir Tim Berners-Lee, inventor of the World Wide Web and HTML, has expressed support for compelling Apple to allow other browser engines on iOS, as more competition leads to more innovation and bright ideas. He also states that having a powerful browser on iOS would "change the dynamic" with respect to web app's viability on mobile.

You can see the full original interview here and our analysis here.

Do you think that Apple being made to allow Chromium to run on the iPhone, for example, will actually lead to new browser innovation? Nilay Patel - The Verge

When you have a competition between different sections of the layer, it tends to increase innovation. You get more bright ideas out there. Sir Tim Berners-Lee

What’s happening in 2026?

2026 is set to be an exciting year for browser and web app competition.

CMA Investigation

The UK’s CMA is going to conduct two investigations into Apple under the DMCC. One is into browser engines on iOS, the other is into the potential of web apps on iOS. These investigations will likely result in the CMA imposing bespoke rules on Apple to fix competition issues related to these topics such as prohibiting Apple ban on third-party browser engines, allowing API access for browsers and allowing browsers to install and manage web apps using their own engine.

Japan’s Smartphone Bill

As discussed above, we do not believe that Apple’s current solution with Japan’s new Smartphone law is compliant nor will it lead to fair browser competition on iOS in Japan. This will be a key area of focus of OWA in 2026, stay tuned for more updates.

Our aim is that either Apple will make changes to be in compliance or Japan's regulator will step in and open an investigation.

Australia

Australia will likely be putting their version of the DMCC and DMA before the Australian parliament. This will likely add Australia to the 28 countries that now explicitly prohibit Apple’s ban on third-party browser engines.

As with other countries, a law being passed is only the first step. Regulators will then need to proceed through the formal process of designation, code of conducts and investigations.

Will the EU Commission investigate?

At the start of the year, we published a paper outlining how Apple was not in effective compliance with Article 5(7) of the DMA. It is now twenty one months since the DMA came into force, no browser vendor has successfully ported a competing engine to iOS. The financial, technical, and contractual barriers Apple has put in place remain insurmountable. These restrictions are not grounded in strictly necessary or proportionate security justifications.

We have outlined in detail why we believe Apple is not in effective compliance and is required under the DMA to make further changes. The EU commission has the power to fix this in 2026 by opening a proceeding into Apple and compelling them to make changes or face significant fines.

What now?

2026 promises to be a pivotal year, making it more important than ever for both developers and consumers to have strong advocacy for browser and web app competition. We sincerely thank everyone who generously contributed their time and expertise, whether through drafting or reviewing regulatory submissions, enhancing and building our website, engaging in detailed discussions, providing invaluable feedback, or participating in conferences and meetings; and those who helped provide financial support. You made the web a fairer, more competitive and more exciting platform.

OWA has so much more work to do advocating for the web all over the globe. We will always need your support, and you can do that in many ways:

If you have the opportunity, please join us in 2026!