iOS Browser Performance WebKit Rules: What Apple's Engine Requirement Actually Means

A note on sourcing: benchmark data in this article comes primarily from Apple's own WebKit engineering blog. DMA compliance analysis draws on Open Web Advocacy, an advocacy group with an explicit position on this issue. The DMA text itself is primary law. Where claims come from parties with financial or policy stakes, that is noted.

The debate over iOS browser performance WebKit rules often turns on a specific number: 30%. A widely circulated claim holds that Apple's mandatory WebKit requirement costs iPhone users nearly that much in rendering speed. The figure is specific enough to be newsworthy. It is also too specific to accept without scrutiny, because no independent benchmark comparing Google's Blink or Mozilla's Gecko against WebKit on the same iPhone hardware appears in the sources reviewed for this article.

The broader competition issue is better documented than the 30% figure itself.

Every browser on iPhone, including Chrome, Firefox, Edge, and Arc, is required to run Apple's WebKit rendering engine. The version of Chrome on your iPhone is a WebKit browser with a Google interface on top. Any speed comparison between it and Safari measures UI and feature choices, not engine differences. Because iOS browsers all use WebKit, comparisons between Safari and Chrome on iPhone do not isolate engine performance at all.

The browser engine market has shrunk from five major engines in 2013 to three today. WebKit, Google's Blink, and Mozilla's Gecko are all that remain, with WebKit required for all iOS browser development globally, according to Mozilla earlier this year. Europe's Digital Markets Act was meant to change that. The law explicitly prohibits platform gatekeepers from requiring browser vendors to use the gatekeeper's own engine, with a compliance deadline of March 2024. Fifteen months after that deadline passed, not one browser vendor had shipped an alternative engine on iOS, Open Web Advocacy reported last July.

That failure to produce results is why the performance debate remains permanently hypothetical.

What WebKit's own benchmarks show and what they don't

Speedometer is a benchmark suite that simulates web app responsiveness, running tasks like rendering to-do list applications built with popular frameworks such as React, Vue, and Angular. JetStream targets JavaScript and WebAssembly workloads. Both are useful proxies for real-world browser speed. Neither, as currently published, includes a side-by-side comparison of different engines running on the same iPhone hardware.

WebKit is not standing still. Apple's engineers report that Safari's Speedometer 3.0 score improved roughly 60% between Safari 17.0 and Safari 17.4, with a subsequent optimization pass delivering a further 6.5% gain, benchmarked on a MacBook Air M2 running macOS 14.4, the WebKit blog noted in April 2024. More recently, a single architectural change to WebAssembly garbage collection handling produced roughly a 40% improvement on the relevant JetStream 3 subtests, contributing to an overall 10% gain from Safari 26.0 to Safari 26.4, the WebKit team reported earlier this year.

Every figure above compares WebKit to an earlier version of itself.

Those numbers say nothing about how WebKit on an iPhone compares to Blink or Gecko on the same device, because no such test has been published. The "almost 30% performance cost" claim implies exactly that kind of cross-engine comparison. That data does not exist in the public record from any independent source.

The practical upshot for users today: switching from Safari to Chrome on iPhone changes your interface, your sync ecosystem, and some feature availability. It does not change your rendering engine. Performance differences between iOS browsers reflect app-level engineering decisions. The only way to answer the cross-engine question is through actual market entry, which is precisely what the DMA was designed to enable.

What iOS browser engine restrictions actually block: the DMA requirement vs Apple's implementation

DMA Article 5(7) states that a gatekeeper "shall not require end users to use, or business users to use, to offer, or to interoperate with, a web browser engine... of that gatekeeper," as cited by Open Web Advocacy. Apple was required to comply by March 2024. In principle, Google and Mozilla could today ship Blink and Gecko on iPhones sold in EU member states.

Apple has made some changes. The company now permits browser vendors to include both WebKit and their own engine within the same app, and has extended the ability to test third-party engines to developers outside the EU, Open Web Advocacy documented last July. At a DMA regulatory workshop, Apple's VP of Legal, Kyle Andeer, told attendees that vendors like Google and Mozilla have "everything they need" to ship and have simply "chosen not to do so."

Open Web Advocacy identifies two barriers as the most significant remaining obstacles.

The first is developer testing access. Apple allows native app developers outside the EU to test EU-specific functionality, but offers no equivalent path for web developers building against third-party browser engines on iOS. Without that access, raising the cost and risk of targeting a non-WebKit engine substantially, Open Web Advocacy noted.

The second is security update continuity. Apple has not confirmed that security patches would continue reaching EU users who travel outside the EU for more than 30 days. The ambiguity is not theoretical: Apple has already stated it will block updates for apps from third-party stores for users outside the EU past that threshold. Apple has not released any explicit statement covering browsers using their own engine downloaded from Apple's App Store under the same travel scenario, according to Open Web Advocacy. For a security-sensitive product, that unresolved question is a significant deterrent to shipping.

Mozilla's Damiano DeMonte characterized Apple's compliance approach as making it "as painful as possible" for competitors to offer real alternatives to Safari, framing the remaining obstacles as deliberate barriers rather than engineering oversights.

The stakes extend beyond consumer browser choice. Open Web Advocacy has noted that if a web capability doesn't work in WebKit on iOS, developers building for broad mobile audiences may not be able to ship it at all, which means WebKit's implementation pace shapes what the web can do, not just what Safari can do. Mozilla makes a related point: with WebKit mainly confined to Apple devices, Gecko is currently the only cross-platform challenger to Blink, making the iOS engine question central to the health of browser diversity overall.

Why the dispute has high commercial stakes

Apple's financial interests don't establish that its compliance approach is legally inadequate. That is a question for regulators. They do explain why Apple faces no obvious commercial pressure to make rival engine deployment frictionless, and why the stalemate may persist.

Apple reportedly receives approximately $20 billion per year from Google to maintain Google as Safari's default search engine, a figure representing roughly 14 to 16 percent of Apple's annual operating profit. Each percentage point of Safari market share lost to rival browsers carries an estimated $200 million annual revenue cost, according to Open Web Advocacy, drawing on figures that have surfaced in antitrust proceedings. These are advocacy-group estimates, not audited figures, but the order of magnitude is consistent with what has emerged in litigation.

The App Store adds a second pressure. Apple collected an estimated $27.4 billion from $91.3 billion in App Store sales in 2024, Open Web Advocacy calculated. Web apps already account for roughly 70% of app-like software on desktop. A meaningful shift toward more capable web apps on mobile, enabled by unrestricted engine competition, could substitute for native iOS apps. Even a 20% shift would represent an estimated $5.5 billion annual reduction in App Store revenue.

Apple's official framing is architectural. Andeer has argued that WebKit was a deliberate security and privacy design choice for iOS from the beginning, and "has worked for 18 years." The U.S. Department of Justice, in its antitrust complaint, characterized Apple's security framing as "an elastic shield that can stretch or contract to serve Apple's financial and business interests," a sharply different reading of the same history, both quoted by Open Web Advocacy.

Neither characterization resolves the technical question. They do illustrate why the two sides are unlikely to find common ground without regulatory compulsion.

What iPhone users should know right now

For users, the immediate picture is straightforward. Switching browsers on iPhone today changes your interface, your sync ecosystem, and some feature availability. It does not change your rendering engine. Safari and Chrome on iOS run the same underlying technology. Whether a rival engine would be faster, more capable, or both remains genuinely unknown, because rival engines have never been permitted to compete on the platform.

The broader structural concern is consolidation. Mozilla has noted that if a small number of vertically integrated companies controlling browser engines also control search, AI, operating systems, and advertising, meaningful competition on the open web becomes substantially harder to sustain. The contraction from five major engines in 2013 to three today is the backdrop against which Apple's compliance choices play out.

DMA Article 8 requires Apple not just to technically permit alternative engines, but to demonstrate that its compliance measures are "effective in achieving the objectives" of the regulation. Whether EU regulators formally assess Apple's program as meeting that standard will determine whether iPhone users ever get the market conditions necessary to answer the performance question from actual data, rather than a number nobody can currently verify.