iOS Browser Performance: Microsoft Data Shows 28.6% Gap

A set of benchmark results published by a senior Microsoft engineer has put a concrete number on something browser developers and open web advocates have complained about for years: iOS browser performance is being held back by Apple’s insistence that every browser on the iPhone use its own WebKit rendering engine. The data suggests the cost to users is real, measurable, and larger than most people probably assumed.

• iOS browser performance data from Microsoft shows a Chromium-based Edge prototype beating Safari by 28.6% on Speedometer 3.1.
• Apple’s WebKit-only rule has suppressed iOS browser performance for 17 years, according to Open Web Advocacy.
• The EU’s Digital Markets Act opened the door to alternative engines in 2024, but no browser maker has shipped one yet.
• Technical barriers and App Store requirements are cited as the main reasons progress on alternative engines has stalled.

The Numbers Microsoft Put on the Table

Kyle Pflug, group product manager for the Microsoft Edge Web Platform, posted benchmark comparisons on Monday pitting a research prototype of Edge — one built using Apple’s BrowserEngineKit framework and running the Blink rendering engine that powers Chromium — against Safari on a device running iOS 26.5.1. The results weren’t close.

On Speedometer 3.1, the industry’s most widely cited browser responsiveness benchmark, the Blink-based prototype scored 49.27 versus Safari’s 38.3. That’s a 28.6% gap in raw iOS browser performance, on Apple’s own test, on Apple’s own platform. The Blink prototype also beat Safari by 13.1% on JetStream 3, a demanding JavaScript benchmark (306.35 vs. 270.9), and edged it out by 2.1% on MotionMark 1.3.1, which measures graphics rendering capability (4,773.52 vs. 4,673.68).

Pflug was careful to frame these as preliminary results from his own device rather than controlled lab conditions, and the prototype itself isn’t a product anyone can download. But the direction of the data is hard to wave away. When a research build — not even a polished shipping product — already outperforms the incumbent by nearly 29% on a benchmark the incumbent’s own parent company created, that tells you something about where the ceiling actually is. The iOS browser performance ceiling, in other words, is an artificial one.

Why Every iPhone Browser Is Secretly Safari

To understand why this matters, you need to understand a rule Apple has enforced since the App Store launched in 2008. Every browser distributed on iOS must use WebKit, the rendering engine Apple built and that powers Safari. Chrome on iPhone? WebKit underneath. Firefox on iPhone? Also WebKit. Microsoft Edge on iPhone — until this prototype existed as a research curiosity — also WebKit.

This means that for the entire history of the smartphone era, the only rendering engine that has ever run on an iPhone is the one Apple controls. Every performance improvement Google ships to Blink, every optimisation Mozilla pushes to Gecko, every rendering capability that lands in Chromium — none of it reaches iOS users. They get whatever Apple ships in WebKit, on Apple’s schedule, with Apple’s priorities. The knock-on effect on iOS browser performance is cumulative and significant.

The practical consequences go beyond benchmark numbers. Web APIs that have been available in Chrome and Firefox for years sometimes take much longer to appear in Safari. Features that web developers rely on to build more capable, app-like experiences on the open web have historically landed on iOS last, if at all. Apple has always maintained that WebKit restrictions exist for security and privacy reasons, but critics have long argued the rule also conveniently keeps the mobile web less capable than native apps — which happen to live in Apple’s App Store.

The EU Opened a Door Nobody Has Walked Through

The European Union’s Digital Markets Act was supposed to change this. From March 2024, Apple was required to allow alternative browser engines on iOS in the EU, delivered via a framework called BrowserEngineKit. It was a significant regulatory win on paper. In practice, more than two years on, not a single browser maker has shipped a non-WebKit engine to iOS users.

The reasons are a mix of genuine technical complexity and structural friction that critics say Apple has done little to reduce. Building and maintaining a separate browser engine for a single platform is expensive. The DMA’s requirements also mean that any browser using an alternative engine must be published as an entirely separate app — you can’t simply update Chrome or Firefox on iOS to use Blink or Gecko. Users would need to download a completely different app, fragmening the install base and complicating product development for companies that already maintain separate iOS and Android builds. Poor iOS browser performance is therefore compounded by the very rules meant to fix it.

Open Web Advocacy, a non-profit that has been pushing for browser engine competition on iOS since before the DMA existed, told The Register that Pflug’s numbers illustrate a ’17-year cost to consumers.’ The group is calling on the European Commission to open a specification proceeding — essentially a formal process to instruct Apple precisely how it must remove the remaining barriers, rather than leaving the company to define what ‘compliance’ means on its own terms.

Why This Is About More Than Speed Scores

Benchmark numbers are useful because they’re concrete, but the real argument here is structural. Open Web Advocacy’s position — and it’s a hard one to dismiss — is that restricting iOS browser performance isn’t just about whether a webpage loads a fraction of a second faster. It’s about what the mobile web is capable of doing at all.

When the web can’t match what native apps can do on the platform most people carry in their pocket, businesses are pushed toward building iOS apps. And iOS apps live in the App Store, subject to Apple’s 15–30% commission, its content policies, and its review process. A more capable mobile web is, structurally, a competitor to that ecosystem. Whether or not that’s the reason Apple has maintained its WebKit rule, it’s certainly the effect. Depressed iOS browser performance, viewed through that lens, is not a side issue — it’s central to how the mobile internet is shaped.

Microsoft’s data lands at an interesting moment. Apple is under more regulatory pressure in Europe than at any point in its history, with the DMA forcing changes across payments, app distribution, and browser rules. The iOS browser performance gap has now been quantified in a way that’s difficult to ignore — not by a fringe advocacy group, but by engineers at one of the world’s largest software companies, using Apple’s own benchmarks.

What Needs to Happen Next

Pflug’s research prototype isn’t a product launch. Microsoft hasn’t announced plans to ship a Blink-based Edge for iOS in the EU, and the gap between ‘research prototype’ and ‘app in the App Store’ is significant. But the prototype’s existence proves the technical case: given the opportunity to run a proper rendering engine on iOS hardware, a browser can meaningfully outperform what Apple’s WebKit currently delivers.

Whether that opportunity becomes real for users depends almost entirely on regulatory momentum. If the European Commission acts on Open Web Advocacy’s request and forces Apple to make BrowserEngineKit genuinely workable — not just technically available — browser makers might finally have a path to shipping alternative engines without the structural penalties that have kept them away so far. That would be the fastest route to closing the iOS browser performance gap for everyday users.

Until then, every iPhone user running Chrome, Firefox, or Edge is still, under the hood, running Safari. And if Microsoft’s numbers are anything to go by, they’re running a version of the web that’s almost 30% slower than it needs to be.

Source: MacRumors

Frequently Asked Questions