"Why", I ruminate, "should someone who understands the state of play give Apple credit for doing less than the minimum while rubbishing those who have consistently done more?"
Like Apple's previous marketing of Safari 16.4 and Safari 26, the conjoined September release of Safari and iOS 27 documents an achingly slow release cycle. It would be one thing if the features or spec conformance were world-beating, but looking closely at the release notes, Safari 27 is set to deliver fixes for issues that, by and large, competing engines didn't suffer.1
Don't get me wrong: it's great that Apple is focusing on quality; it remains a persistent issue for Safari. But how much relief should long-suffering web developers expect?
It would appear that Safari is closing on Firefox, but this is misleading. Apple managed seven releases over the past year, or a roughly eight week cadence. Mozilla and Chromium, meanwhile, have released 12 versions to stable, or one a month. These serve as denominators (7.4 weeks vs. 4.3) when calculating rates of improvement. Safari's larger increase in passing tests between nightly and stable versions (1558 vs. 990 for Firefox) looks large, and Apple wants us to think that's down to renewed focus. On a time-weighted basis, however, Safari continues to improve more slowly than Firefox, logging 207 improved tests per week since the last stable release versus Firefox's 230 and Chromium's 460.
Safari's WebKit remains least improved since this time last year. Source: wpt.fyi
Because new features are constantly added to browsers, the denominator continues to increase over time. It's helpful, then, to look at the change in tests passing as a fraction of all tests. This highlights the extent to which engines are progressing (or regressing) relative to the web's potential:
Apple might not care to implement some of the features Safari isn't passing tests for, but is that a reason they should be denied to all iOS users? And what does it say that others can improve relative to the overall test set, but WebKit has fallen further behind? Source: wpt.fyi
Total passage rates imply the role of engines as the blockers of widespread compatibility, but aren't a foolproof indicator. For example, if every engine failed the same way, it would be regrettable, but compatible. Web developers wouldn't have cause to throw shade at one browser more than others, so perhaps overall test failure rates obscure more than they clarify?
Helpfully, wpt.fyi also generates charts for tests that fail in just one engine; that is, cases where two browsers implement a feature correctly, and only one is out of conformance. But for bugs unique to that codebase, the web would be more capable and less costly to develop for. The higher the count, the more an engine holds back progress:
Lower is better. Over the past eight years, Safari's WebKit nightly builds have uniquely failed double the number of WPT tests as Firefox's Gecko on average. WebKit consistently racks up 3-4x as many single-engine failures as Chromium's Blink engine across the same time period. Source: wpt.fyi
At the time of writing, WebKit nightlies are alone in failing ~4,200 tests, Gecko is next at ~2,400, and Blink is the least incompatible with just under 800 unique failures. These relative rates have remained stable across many years, indicating higher sustained investment in Blink and Gecko versus WebKit.
Lower is better. With the recent addition of the Test262 test suite for JavaScript, WebKit's contribution to feature impairment becomes even more pronounced. Source: wpt.fyi
Including the test262 JavaScript conformance suite, we see a huge spike in WebKit-exclusive test failures. This is thanks to Blink and Gecko shipping the new Temporal API this spring. Temporal has been in development for nearly a decade; it hardly snuck up on Cupertino. Judging by the Safari 27 blog post, and confirmed by the state of the nightly test runs, it will not be included when new features ship in September.
Apple has repeatedly claimed to regulators that there's no need for real choice in iOS browsers because Safari is more than capable and the team is well funded. It's unclear how those claims can be squared with such an embarassing showing on a long-anticipted feature that Apple has no objection to.
One critique raised by this visualisation is that tests are not features. Some areas (like Temporal) include exhaustive test suites with many sub-tests, driving up their relative numbers. Other features may be foundational or internally complicated, but may have proportionally fewer WPT tests.
Thankfully, webstatus.dev has collated a feature-oriented view of the same data. Looking across the past decade, it shows that WebKit is the predominant reason features remain unavailable to users and developers, forcing both into the App Store where Apple demands a 30% cut:
Lower is better. As of June 30th, 2026 Safari is alone in blocking 59 features, Firefox keeps 43 from becoming widely available, and Chromium is blocking nine.3Source: webstatus.dev
Blink has consistently maintained the lead on features and conformance over the past decade, but iOS users remain stuck with Apple's buggier, less capable engine, no matter which browser they choose.
Looking at large, heavily tested, uncontroversial regions of the platform shows that the gap isn't simply down to features that Apple thinks are problematic; even in areas where Cupertino is fully engaged, it consistently trails:
With that much cash available, WebKit should be trouncing all comers; instead, it's barely middle of the pack when it isn't losing outright. Stable Firefox passes 84.9% of CSS tests, while Safari clears 86%, or a 1.1% difference:
Test passage rates for the css/ folder as of July 3rd, 2026. Source: wpt.fyi
Results from nightlies suggest that Safari 27 will widen Apple's lead versus Firefox to 1.6%, while trailing both Stable and Canary versions of Chromium (93.4% and 95.5%, respectively).
Improvement is improvement, but Apple's layout engine remains riddled with O(n^2) behaviours. Both Mozilla and the Chromium community funded multi-year rearchitecture projects improve rendering performace, but Apple has not made similar investments.
In other uncontroversial areas, such as networking, Apple's engine loses handily — both today and into the future. The fetch specification underpins browser networking, and WPT scores again highlight the consequences of subsistence-level funding for WebKit:
This continuing embarrassment is not a divergence from historical trends. But for Cupertino to feel any shame, or face any consequences, influential developers like Jeremy will need to look past marketing.
That chasm is instrumental in trapping users and developers in the extractive vice of Cupertino's App Store. A persistent, material gap in capabilities creates a perception of the web being less-than; a budget option for the unserious. Should users choose more capable, more private, less buggy browsers for a larger share of their computing needs, Apple might lose the leverage that enables it to extract rents.
Cupertino can put up with a lot of things, but it can't abide that. Which is why it spends lavishly to deflect and delay true browser choice, rather than investing those resources in the Safari team.
Having looked at the data, and having manually dug into dozens of the fixes listed for WebKit in the Networking and HTML sub-areas, I can say with some confidence that Jeremy's praise for Apple's comparative rate of bug fixing is simply off-base.
Cupertino might be talking up how much it cares, and we might all be desperate for green shoots given Apple's iOS hostage-taking, but our most fervent wishes and FruitCo's carefully presented narrative do not to change the reality that Apple is consistently out-engineered and out-invested by a non-profit with 1/40th the web-derived revenue. Against a near peer, the results of Cupertino's continuing under-investment are squalid.
What we see in these differences has a name: greed.
Apple is extracting tens of billions of dollars in private profit from browsers while socializing the costs to every digital business forced to work around Safari's buggy engine. Ecosystem-wide deadweight losses are even higher, impacting every user and business forced into the App Store by the incapability of Apple's browser. Not coincidentally, this is where Cupertino extracts a second vig. Higher prices for everyone else are not a bug to the monopolist's mind, but a confirmation of their own rightness and purity of charachter. Sure, that sounds like lunacy, but a lot of things go down more easily when you're absolutely rolling in it. Just ask anyone at Apple.
Like test conformance, security and performance are also indicators of quality that comes from consistent investment over time. News recently broke that a Blink for iOS prototype is showing massive performance upside relative to Safari on Apple's own hardware:
The Blink for iOS prototype tested on Apple's own benchmarks, on Apple hardware. In the most representative test suite (Speedometer), Chromium leads by more than 25%.
That's to say nothing of the heavily requested features no developer can use on iOS thanks to Apple's sandbagged engine. Safari engineers have worked behind the scenes to keep important, oft-requested features out of Interop where a lack of progress might make Cupertino's choices more legible. As a result, we (Edge) maintain a parallel dashboard to track progress on important features cut from Interop through secret vetoes:
Firefox scores more than 3x stable-channel Safari's showing this year.
In more visual form, here's the Chromium iOS prototype versus Safari 26.5 running a test page that exercises just some of the features Apple is holding back:
If Apple allowed browser competition, all of these features would become instantly available to web developers willing to recommend better browsers to their users. Which is exactly what Cupertino fears.
Blink and Gecko-based iOS browsers would unlock more capable, more responsive, less buggy websites while simultaneously improving security. Progress would accelerate in a world with competition if only because it would spur Apple to finally fund WebKit at a competitive level. Under-investment is the absentee father of many starving children.
But today, Apple hasn't turned that corner. It's trotting out the same tired playbook:
Chronically under-fund WebKit despite raking in tens of billions in profit from the web every year.
Watch Safari fall behind on features, standards conformance, security, and performance.
Force web developers to cater to that broken target through anti-competitive policies.
Furiously stage-manage any standards or standards-like process that threatens to create visibility or accountability.
Market occasional releases as "big" in some narrow dimension.
One clue might be the Chromium-originated features he objects to. It's easy to be distracted by things you dislike and think "those people aren't paying attention to <good things>, they're just off on a tangent doing <bad things>". But that sort of feeling isn't data. I am not a fan of all recent Chromium features; in fact I'm the proximate reason the prompt() API hasn't launched more widely in the Chromium ecosystem.5
As a Blink API OWNER, my potential concerns about trailblazing efforts take on a specific cast: Chromium and Blink are explicitly organised to make and defend space for leadership, but our ability to lead in new areas is tied to quality. Final feature launch checks are focused on plausible interoperability — will the specs, tests, and implied architecture choices allow other engines to become compatible? — and demonstrations of developer support.
A few years ago I gave a talk for Blink developers outlining how the pieces fit when trying to solve problems for web developers:
TL;DR:, we don't trust ourselves to know all the answers. Instead, the API OWNERS look for quality signifiers, both from an implementation perspective, but also (and more importantly) from the perspective of end developers. When Blink is in the lead, our process is explicit about testing ourselves in an internally adversarial process to answer the question: "does this feature solve an important problem well?"
The key constituency for determining the answer are web developers, not other browser engineers or standards grandees. Working Groups gaining consensus after outbreaks of go fever have been the authors of much suffering, so we explicitly work to ground our analysis in sources of evidence less subject to groupthink.
Blink's process sets a high bar because we know the project is out in front, thanks in no small part to Apple's behobblement of both WebKit and Gecko. It's thanks to Blink's continuous work on conformance and compatibility that we can make path-breaking bets on feature investigations and spend the 3-5x it takes to get it right; particularly when other vendors do not join those (very public) efforts, or weigh in only to object to the colour of the bikeshed at the very last minute.
That's also why we've built mechanisms like Origin Trials to test features without risk of accidental burn-in. Developer feedback is the primary quality signal we evaluate above baseline reviews for security, performance, privacy, and accessibility. It also explains why Blink requires legible explainers, wide review, reasonable specifications, and good tests. We insist that web developers be able to understand and help shape proposals while they're malleable, and when the cement sets, tests and specs should be complete enough to ease the burden on other implementers.
The goal of this system is to pack as much learning as possible into feature development up front, listening to web developers, iterating as we go, and shipping at the speed of developer confidence.6
That's not a recipe for perfection, and nobody would claim we are infallible, but it is a recipe for leaving things a bit better than we found them. Listening intently to web developers and iterating in good faith is foundational to our process. But because we are so often in the lead, and so often iterating in public, work hangs in a liminal state longer than things might if we were able to count on other browser vendors engaging constructively. This invites critique, fair and misdirected alike. That's a price we're willing to pay to keep delivering the features developers tell us they need.
So if Jeremy has a problem with specific features, I hope he'll come to us with a critique of their qualities, rather than their optics. Because it's quality that we are always working to build and defend, and it's quality that makes space to solve new problems, rather than endlessly relitigating prior battles.
FOOTNOTES
Many of the fixes Apple enumerates are issues that have been identified simultaneously in WebKit and other engines.
Contributors sometimes fix bugs in multiple engines at the same time; an upside of the modern Open Source browser ecosystem. In other cases the addition of test collateral to WPT encourages projects to quickly address newly discovered gaps.
In these cases, Apple's forced delay for feature releases hurts the pace of compatibility across the ecosystem. Safari 27 was announced in early June but doesn't launch until September, nearly four months later. Meanwhile in Chromium, the already quick 4-week release cycle has delivered fixes to the Stable channel from nightly builds in two to three months since 2021.
Not content to rest on that relative advantage, Chromium is in the middle of moving to a two-week release cycle, and most Chromium-based browsers (Chrome, Edge, Opera, etc.) are committed to keeping that faster pace. Instead of a normal-priority fix taking two to three months to stabilise and deploy, the window will now be six weeks at the slowest. Patches that land just before branch cut could see deployment in just over a month, or 4x faster than Apple's feature release cadence for Safari 27.
The upshot is that many fixes first developed for WebKit will appear for users and developers in Chromium browsers ahead of Safari 27's release. Separate and apart from the large feature gaps that remain endemic to Apple's engine, the slower pace of deployment continues to slow progress across the entire web ecosystem.
Cupertino can pre-blog all it likes, but the world doesn't improve until the bits on users' disks are upgraded. ⇐
The total number of tests enabled varies by less than 1% between engines. Therefore, we can safely compare pass-rates to get a sense of completeness and quality. ⇐
There is reason to think that Chromium is missing fewer features than webstatus.dev captures because WebGPU is incorrectly marked as unsupported.
Apple has recently increased its investments in WebKit, but it does not seem likely to have broken $1BN/year, all-up. Even the most Bork-addled thinkers cannot deny that margins this large, this sustained, on a product with defects so glaring must be the result of anti-competitive abuses of market power. Earning more than 40x Mozilla's income on a pure substitute, while delivering a substantially inferior product, hinges on excluding more competitive players from entering iOS.
A market with real competition would force Apple to invest substantially more, would quickly improve quality across the ecosystem, and would deliver major gains to developers and end-users. Which is precisely why Apple won't allow it. ⇐
The case of the prompt() API is a microcosm of Blink's values in a telling moment: a call we got wrong. As far as I can tell, Google enabled it for Chrome, proximately, in order to have something to talk about at I/O. This is a failure mode we try to guard against. Other Blink-ecosystem browsers pushed back, noting the lack of public test collateral and challenges in achieving interoperability. Unfortunately, and to my shame, I spotted that the Intent had garnered the necessary three votes to ship weeks after the branch cut.
What happened next matters a great deal.
Instead of doubling down on their position, Googlers took the concerns in the thread seriously, patiently answered questions, and are now working with the community to generate a comprehensive test suite. That should have happened prior to removing the OT requirement, but there is now a path to plausible interoperability based on objective quality metrics. No other Chromium-based browser is likely to ship until they're satisfied with the results.
This is an uncomfortable and unusual situation. The API OWNERS have been clear with the team that they are expected to be responsive to ongoing developer feedback post-launch, and if radical changes are necessary post-launch, the Blink process provides that flexibility on an exceptional basis. Teams are guided not to make breaking changes, in part, because it harms developers. Because we care deeply about developers and not breaking the web, that harms the reputation of the team among the API OWNERS. Groups with a track record of causing pain for the ecosystem face heightened scrutiny when proposing subsequent features, and it's safe to say that the group that pushed prompt() through without bringing the rest of the Chromium community along is now in that unenviable position.
Because Blink and Chromium feature useful, anonymised telemetry, we can keep hawkish tabs on growth of use of the API, currently several orders of magnitude below the rule-of-thumb use threshold (0.03% of pageloads) above which changes and deprecations become much harder to pull off. We're still in a moment when all's to play for. ⇐
Jeremy is sceptical about the motives of Googlers asking which features to prioritise, and scepticism is always healthy — but only when applied evenly.
To get a sense of the degree of good faith inquiry, we have to judge by track records; which engines give developers a structural voice in feature evolution? Which processes force work into the venues where developers can engage without committing to a Working Group meeting schedule (e.g., through incubation venues)? Which products provide transparent ways to engage, test early prototypes, and force developers to iterate in public?
By contrast, which teams are working tirelessly to tear down and ignore easy-on-ramp venues? Fail to provide open processes for feature approval or insight into roadmaps? And which teams most often present fait accomplis, rather than opportunities to shape the future? ⇐
This long-established pattern is as frustrating as it is predictable. Silicon Valley's journalists fail readers by neglecting to connect the dots between the forces that kept desktop OSes open and the suppressive tactics the mobile duopolists1 deploy to prevent similar outcomes. And this despite connections handed to them on a platter by OWA and others. In 2026, the choice to cover app store regulation exclusively through the lens of steering and native app alt stores is a yawning blind spot.
Capable browsers, and the PWAs they support, hold the power to grow an ecosystem of applications that no gatekeeper can own or tax, based on standardised APIs that resist enclosure. Apple goes to extreme lengths to prevent the emergence of browser engine choice to obstruct the app store's most credible disruptor. But few outlets are connecting these dots for readers.
Cupertino is terrified of the web's potential, but you'll never read about it on the pages of Wired, MIT Tech Review, The Verge, or 404. Loyal readers remain uninformed, never clocking how regulators have acquiesced to the gatekeepers' stalling and misdirection. Only The Register and TNS understand what time it is, covering the essential points regularly:
Apple is succeeding in delaying real browser choice through underhanded and unlawful tactics
Regulators are not enforcing the laws effectively in these areas
Users and local businesses lose as a result
These regulatory and journalistic failures are not victimless, circumscribing what technology can be for us all, both positive and negative.
In 2026, it should go without saying that billionaires at the helm of Big Tech firms cannot be trusted to do anything but cower and pirouette for MadKingTrump. The "good ones" have been proven feckless when presented with opportunities to defend democracy and decency. The rest are either actively fascist, fascism-curious,fascist-enabling, or so engrossed in tax dodging they haven't clocked the rule of law succumbing to attacks by their peers. Not that there's much hope they'd stand up for it; they've got theirs, Jack.
These are the masters of the universe demanding control over what happens on our most personal computers.
In an era when they still claimed to be changing the world for the better, the lies told to justify an invasive, unsafe ecosystem of native apps went down more easily. The duopolists provided shockingly deep hooks into our lives for native app developers while shielding them from adversarial interoperability. In exchange, they demanded control over distribution and taxed the pants off the gambli... — sorry, "casual games" — and privacy degrading social media apps that powered the growth of the native app ecosystem.
Accomplishing this feat required defeating threats from open technologies, because open platforms allow users to assert their interests in the face of abusive and predatory software. If users had a vote where useful software could be acquired, or could use browsers for more of their needs, it wouldn't be possible to tax developers at such a high rate. The anti-privacy, anti-user agenda that Apple and Google draw excess profits from cannot survive serious challenges by open technology, which is why the duopolists have worked to hobble them. This is reason enough for democracies to demand portable, standards-based software.
Democratic societies also have wider interests, and we see clearly that trusting Apple and Google with as much market power as they demand is a threat to those goals. The shocking ethical derelictions of the app stores provide yet more reasons to demand regulators legalise open technology.
Software and digital services benefit from network effects, creating acute winner-take-all dynamics in markets where countervailing forces are suppressed. Traditionally, those crosswinds for would-be monopolists have included over-the-top applications, Open Source software, adversarial interoperability, and end-user modulation within open ecosystems (e.g., ad-blocking extensions). Over time, these disciplining factors can break the hold of short-term monopolists, returning power to users and forcing abusive proprietors of services to do better by society or risk losing market share as moats dry up from the pressure.
The iOS and Android duopoly have rendered these recourses illegal and impractical, minting a small number of durable winners. The CEOs and founders of these colossuses are the new tech oligarchs, and their actions in recent years provide compelling arguments against both money in politics and the idea that there can be such a thing as a "good" billionaire.
This corrosive effect is only possible thanks to the intense concentrations of wealth enabled by perverted market structures. These twisted markets are themselves the result of decades of neo-liberal anti-antitrust groupthink. Contra Bork, the social contributions of robust antitrust enforcement aren't limited to lower prices. Reducing the power of private actors promotes stable institutions and honest dealing across a wide swath of society. Samuel Bagg frames the opportunities for antitrust enforcement similarly:
...many practices of constitutionalism are justified on similar grounds: i.e., that first-order constraints on the abuse of power can only be sustained through second-order limits on the concentration of power more generally. Where modern constitutionalism aims primarily to limit the concentration of public power, however, the anti-monopoly tradition follows earlier materialist forms of constitutionalism in viewing the concentration of private power as equally dangerous (Andrias 2015; Fishkin and Forbath 2014;Khan 2018). After all, problems of capture arise not from the existence of public power as such, but from its relationship to private interests.
Back in the 1950s and 1960s, the anti-monopoly enforcers were of a different and much tougher mindset. They were closer in disposition to Theodore Roosevelt and tended to see the stakes of anti-monopoly as transcending mere economics and spilling into questions of democracy and political destiny. Influenced by the recent experience of the Second World War, American officials believed that fascism and corporate monopoly were linked. They feared that excessive corporate power would bleed into fascism or contribute to a communist uprising. Famed antitrust enforcer Thurman Arnold blamed German monopolies for helping Hitler rise to power.
Like Wu and other Brandeisian thinkers, Bagg finds counterweights to these corrosive forces useful, both structurally and specifically:
Countervailing power is the natural complement to anti-monopoly. Both demands are set in motion by the insight that capture is most often perpetrated by certain hegemonic actors and groups — i.e., those with the most concentrated private power and organizational capacity — and that protecting the public interest thus entails special attention to those specific forces. Where anti-monopoly entails targeting their resources and organizational capacity directly, however, practices of countervailing power aim to support their opponents.
The web is such a countervailing power, bringing with it a large ecosystem of developers and publishers that can jump-start mobile contestability. Real browsers and web apps present a potent, two-sided ecosystem competitor. Because browsers feature low switching-costs compared with replacing phones, and provide a standards-based, interoperable app platform, they carry maximum potential to disrupt the market-concentrating effects of app stores whose software catalogues are welded to specific OSes. These properties pose a credible threat to the smartphone duopoly's extractive, anti-competitive status quo. Indeed, we can expect real browser competition to finally make Apple and Google competitors. This can return economic surpluses to users and businesses, rather than the duopolist's shareholders.
A web liberated to compete has already demonstrated the power to align forces that erode gatekeepers' influence through competition between browsers and their engines. Interoperability and a grounding in royalty-free standards pairs with this competitive engine to expand the penumbra of capabilities. Those capabilities, in turn, enable new entrants without the need to simultaneously convince a critical mass of developers to build for a new OS.
Because browsers commoditise OS features, the competition between them — both internal to, and across the existing Android and iOS deployed base — grows a corpus of essential apps that any new entrant needs (the Bridge Strategy). Instead of forcing a new smartphone OS to convince every software house to build new apps for their new APIs simultaneously, or to brave legal and technical threats as they implement Apple and Google's APIs wholesale, browsers and PWAs shrink the missing software gap tremendously. Should browsers make hay on iOS and Android the way the DMA's drafters hoped, new market entrants only need to port competent browsers (a much smaller lift) and fill in a greatly reduced app gap.
But even if a new competitor doesn't emerge thanks to the web, browsers discipline incumbents in-place by providing competition with their proprietary software ecosystem. This competition cuts across categories and eventually emerges in every vertical that browsers are capable enough to support.
This brings us finally to the positive browser product category effects of competition. When mobile OSes feature sustained browser competition, the incumbents themselves help to expand the web's carrying capacity or risk marginalisation.
This dynamic played out in the 2000s and 2010s as Internet Explorer lost share to competitors thanks to Microsoft's under-funding. Firefox, Chrome, and Safari worked to expand the power of the web, pushing IE's once 90+% dominance to the curb while dramatically growing the list of tasks users turn to the web for. Eventually, Microsoft capitulated, switching to Chromium to regain compatibility with a dynamic, growing web that threatened to pass it by.
Proprietary incumbents prioritise user needs over their own extractive agendas when competition from open ecosystems is enabled by low switching costs.2 This paves the way for competitors, expanding the power and relevance of low-cost, interoperable technology with each competitive iteration. We have seen the web's wedge work against API enclosure on the desktop, with a large majority of all new desktop software being written first as web applications and only later (and optionally) wrapped in WebViews to deliver needs from a shrinking set of "last mile" capabilities that the web doesn't provide out of the box.
Such is the power of interoperability made manifest; it's far past time for the tech press and regulators to speak clearly about the anti-web game the duopolists are playing to prevent the web from breaking out.
Several points are plain to anyone engaged in mobile ecosystems. There are many sub-points to quibble about, and various parties talk their own books, but the broad strokes are accepted by all sides:3
The web provides a portable and (potentially) capable way to deliver software.
Every contemporary phone with a touch screen has more than enough computing power to run full-fledged browsers that can support capable web apps.
Yet the smartphones almost every wealthy person carries support only less-capable,lower-quality browsers.
This suppresses the web's relevance through compounding wealth and quality effects.
Apple and Google's anti-competitive policies keep web apps from threatening the foundations of their App Store revenues by forcing developers to build to the APIs that the incumbents control. This grounding in Apple and Google's proprietary APIs is the root of the duopolist's power. They use it in combination with threats and promotional inducements from their stores to enlist developers in promoting features of the hardware and services they monetise.
Open, interoperable, safe-by-default runtimes with standardised APIs threaten the foundations of this structure by breaking the duopolist's chokehold over software distribution. Browsers, and their core function of abstracting away the proprietary APIs of OS vendors, create a tax-free zone outside the grasp of the OS incumbents' mafioso App Store tactics. To ensure the web cannot threaten the API enclosure today's mobile ecosystems are founded on, browser competition must be suppressed and browsers themselves incapacitated.
That Apple has managed to pull this off is a scandal. But our tech press and commentariat do not cover the web as a true threat to App Stores. Instead, they fixate on alt stores as a mechanism to supplant gatekeeper control. This is a gift-in-kind to the duopolists. By failing to acknowledge the power of the web to disrupt entrenched OSes (as demonstrated by the past 20 years of desktop computing), the press are failing to communicate the stakes of regulatory failure to enable browser competition. This, in turn, excuses woolly regulators as they squander the ripest opportunity for reform in living memory.
The dream of the alt store is a mirage, or at least a distraction. Windows is able to sustain several successful native app distribution alternatives in addition to Microsoft's own store (e.g., Steam and The Epic Games Store), but these systems are tied to specific verticals and the APIs desktop developers target are de facto open and stable, thanks to regulatory interventions of the last century. And app stores aren't event the dominant desktop software distribution channel.
Mobile app stores, by contrast, are the only game in town and have significantly larger scope. This grants them power to tie together and monetise a host of services. Disrupting this cozy arrangement will require a vast ecosystem and deep integrations that no native alt-store can contemplate bootstrapping today.
The web presents one of the only ecosystems with enough existing use and investment to plausibly re-create a substantial fraction of this ecosystem value without the cold-start problem. Other challengers face a daunting choice: focus on a less expansive vision by diverting into narrow app categories, or depend heavily on OS services and APIs. Either option reduces contestability and detracts from the potential for a successful, interoperable mobile software ecosystem.
Browsers provide an alternative. Because they synchronise payment instruments, identity, and user preferences over the top of the OS, users experience reduced friction when transferring to the web versus a competing native ecosystem. And because most folks already invest a significant fraction of their digital lives with their browser, apps that run on the web are a more credible threat to the status quo than alt stores filled with native apps that must choose between rebuilding all of this from scratch or buttressing the lock-in of OS vendors.
Regulators facing choices about where to invest scarce resources should foreground browser engine choice and web apps because they create mass behind their agenda and bring a powerful, pre-existing ecosystem to bear. The alternative is playing whack-a-mole with gatekeepers over easily divide-and-conquered alt stores.4 Once browser-based apps can address the bulk of the market, the lift required to institute fair distribution terms in other verticals will be substantially reduced.
Instead of promulgating proprietary APIs, the web provides an answer to regulators' central problem: how to bootstrap an ecosystem of interoperable software?
Capable browsers are the proven answer. Unleashed by aggressive policy intervention a quarter century ago, the web has become the most abundant app store of all time. As the D.C. Circuit Court predicted in finding against Microsoft in 2001:
...were middleware to succeed, it would erode the applications barrier to entry. Because applications written for multiple operating systems could run on any operating system on which the middleware product was present with little, if any, porting, the operating system market would become competitive. Id. p p 29, 72.
But as the District Court found, middleware will not expose a sufficient number of APIs to erode the applications barrier to entry in the foreseeable future.
What the court failed to understand in 2001 was that Microsoft had already made the browser a complete platform. Even after Redmond disbanded the team after IE 6's release, that browser would go on to midwife applications like Google Maps, GMail, and Google Docs; in its zeal to see off Netscape, Microsoft sowed the seeds of Win32's irrelevance. Firefox, Chrome, and (yes) Safari built on the momentum, unlocking adjacent possibilities that brought new categories into the web at a rapid clip. Today, design, CAD, software development, and scientific computing regularly happen in-browser and more than 70% of desktop "jobs to be done" are now handled on the web.
PWAs complete the story for the mobile era, unlocking participation in the tap-and-swipe ecosystem today's duopolists are working enclose through app stores. Just as it was a quarter century ago, the web is already the answer; we just need to clock as much and legalise powerful mobile browsers.
So-called alt stores are a less compelling solution because of their reduced power to ignite competition and inability to lower switching costs. Instead of providing developers with standardised APIs, they weave the duopolist's proprietary technologies and services into each app. This reduces app portability, increases developer costs, and raises the incumbent's moats against new OS entrants. A hat-trick of lock-in.
Instead of settling for a world in which alternatively distributed apps must attempt to re-create the technical foundations of interoperability for themselves, regulators can win both interoperability and momentum for their efforts by unblocking real browser choice and PWAs enabled by it. Browser engine projects feature large teams whose entire job is to intermediate between OS-specific APIs and web apps, enabling developers to write to a single interoperable platform out of the box.
The opportunity to harness both a large ecosystem of developers used to building for an interoperable platform, and teams of C++/Rust engineers accustomed to competing to provide improvements to that interoperable platform should have rocketed the web to the forefront of every regulator's thinking. The new powers that the EU's DMA, the UK's DMCCA, and Japan's MSCA provide in theory need concrete enforcement actions to bring the duopolists to heel, and the web's advantages in efficiency of regulatory intervention, reduction in security risk, and pre-existing cross-OS interoperability are unparalleled.
It pains me deeply to acknowledge that the institutions handed new powers by the DMA,the DMCCA, and the MSCA are universally failing to prioritise the transformative power of browsers as they work to enforce the provisions of these laws. Instead of focusing fire on the lowest-risk, highest leverage intervention, regulators are being side-tracked and talked down from pursuing aggressive browser choice enforcement.
In case procedural hurdles weren't enough disincentive, Apple also hobbled its browser SDK, omitting support for obviously in-scope features including the ability to handle in-app links, support web apps on the home screen, and disambiguate push notifications. It has built and shipped all of this for Safari, in some cases relatively recently, so it wasn't a case of forgetfulness. Brushed back from attempting to murder web apps on the eve of DMA enforcement, Apple simply chose to duck complying with the law by dressing up violation in umbrage and legalese.
Cupertino's design carefully omits the capabilities that would unlock direct competition with the app store, safe in the knowledge that so long as Safari is the only browser with access, it can keep the web hobbled and broken. This is a blatant affront to the DMA's plain meaning and legislative intent, and dovetails with extralegal attempts to apply maximum pressure on the EC to accept less than half a loaf.
Recall that Apple initially argued that it didn't have time to comply given a mere two-year run-up. It was enough time for all of Apple's competitors, but somehow not for the self-proclaimed titans of software from Cupertino.
That was two years ago.
Has the offer improved regarding these strategic omissions? Not one iota.
Indeed, Apple is now lying to our faces; from its latest DMA compliance report (emphasis added):
(45) For the purposes of allowing alternative web browser engines to interoperate with iOS and iPadOS, Apple makes a suite of functionalities available so that browser apps and apps providing in-app browsing using alternative browser engines can be installed and run on iOS and iPadOS in the EU. Apple provides authorized developers access to technologies within the system that enable critical functionality and help developers leverage high-performance modern browser engines. These technologies include Just-in-Time compilation (which provides performance benefits by helping browsers to quickly and efficiently render JavaScript content), multiprocess support, and more. Third-party browser apps using third-party web browser engines can support and run web apps.
This misleading text suggests that Apple has provided APIs to competitors to support these core use-cases through their own engines; it manifestly has not.
Faced with such strategic flouting of these the law, one might assume regulators with a sense of their own prerogatives and legislative intent might respond with overwhelming force.
Rather than treating Apple's belligerent, maximalist strategy as a joined-up attack aimed to deny oxygen to the most effective competing ecosystem, the DMA's enforcement group has ratified Apple's redrawn boundaries through studious inaction. Like Sykes and Picot with a ruler, Apple has drawn lines that favour its interests above all else, and authorities that could countermand its declarations are notable only by their absence. The perspective from Brussels seems to be that these questions are now simply competing claims by equally mucky mud wrestlers, rather than galling non-compliance and an affront to the point of the DMA.
Rather than bearing down on structural issues, regulators appear immersed in dense debates with the scofflaw's counsel over inconsequential details. Even in the areas that it is levying fines, the EC is not challenging the structure of Apple's power. This is tantamount to settling for lipstick on the status quo. If the DMA was designed to redress the problems it enumerates, this is failure by the EC's own yardstick. We're entering year three of DMA enforcement, and meaningful change is not obviously closer. Why not?
No amount of punch-pulling or case-buttressing will prevent Cupertino from rolling out its shockingly large army of lawyers. Apple alreadyspends more on lawyers every year than the fines the EU is proposing!
This is the same company that used lawyerly nonsense to hold up the UK CMA's investigation for nine months, implausibly arguing the regulator hadn't brought the boom down fast enough on its own bad behaviour, and therefore couldn't do so later. It was never a serious argument, but when dressed up in enough £1000/hr legalese, Apple's calculated attempt to create delay paid massive dividends. Nine months of regulatory delay is worth many billions to Cupertino.
Apple is conducting a maximalist campaign against the very concept of the rule of law when its profits are at risk, and having paid off a deeply corrupt US administration, the intensity and reach of that campaign is only increasing. All of this should create a deep, abiding suspicion of Cupertino's motives, removing the benefit of the doubt wherever it claims contestability is a reality on iOS. No self-respecting regulator can take anything Apple's lawyers say at face value in 2026. But there's only a price for duplicity when those with authority recognise the pattern and apply suspicion, rather than deference.
Regulators (not to mention the press) are well within their rights to take on board Apple's misrepresentations, astro-turfing, and serial non-compliance when calculating how aggressively to act. Instead, the EU's DMA team, the UK's CMA, and Japan's regulators are falling for the same shenanigans over and over; treating each encounter as a blank slate, happy to pretend a disquieting history of belligerent non-compliance is immaterial to arguments offered today.
This is both a tactical error and a strategic blunder.
At a tactical level, extending deference to each new pile of misdirections allows Cupertino to play for time; when you're the incumbent, delay is winning, and regulators that do not demand prompt changes weaken their own future hand. Strategically, failure to demand changes right bloody now in the face of material non-compliance denies the regulator the benefit of even a weak fleet in being effect. And declining to demand immediate change in areas most likely to create the deepest, most generative effects grants Apple ongoing regulatory relief in the form of reduced structural competition.
Of course it harms EU businesses that they cannot target a platform across mobile OSes, and that EU businesses instead have to bear high ongoing development and servicing costs to participate in proprietary app stores. It is obviously negligence on the part of newly empowered regulators to allow Apple's gerrymandering attempts. Cupertino has worked to draw constrictive borders around browsers for the last several years; demarcations that just happen to exclude capabilities that would make mobile computing truly contestable.
Since regulators and the tech press are not connecting the dots from first principles, desktop computing analogues, legal precedent, or the lengths Cupertino has gone to prevent the web from breaking out, it must be repeated:
Browsers are app stores.
If we want effective alternatives to the gatekeeper's app shops, nothing will be more effective than unleashing real competition from the web. Browsers are stores filled with a priori interoperable software and with low friction installation thanks to PWAs! And they feature incredible security! Protections so strong that you don't even have to hang a "beware of dog" sign out front.
Should we collectively accept this premise and expand our understanding of software contestation to include the web as a viable alternative in the app store story, what would that mean? The duopolists are working overtime to silo the discussion to their preferred proprietary technologies, why? Is that worthy of investigation and discussion?
For regulators, this perspective is a treasure map. Enabling true browser competition unlocks both internal and cross-OS competitive forces, unleashing firms with an interest in interoperability on both sides of the browser market. But for regulators to get credit for converting on this incredible opportunity, their constituents will need to hear about it. And on that front, we've got a lot of work to do.
We get plenty of TopGear-but-for-phones and "CEO said a thing" coverage, but very little coverage of the way access to APIs shapes our digital lives. Most outlets still treat access like it's a real beat, depriving them of the distance necessary to contextualise the duopolists' actions in a frame their PR staff dislike. The closer a publication gets to the mainstream, the worse the distortion seems to get.
Few tech outlets, including irreverent youtubers, seem to recognise that the web is the single biggest threat to mobile app stores, opting instead to cover minor news of alt stores tremors like The Big One. This misleads readers about the stakes and distorts the incentives of regulators.
Reporting that borrows the narrative frame the duopolists prefer enlists otherwise excellent outlets as allies of the billionaire class. Too many reporters uncritically accept that app stores are how we must think about mobile software, regurgitating this narrative through stories filed in a browser on their laptops. Apple, Google, and the handful of "winners" the app stores bless profit massively from centralisation. Reporters and editors further the goals of the broligarchs by failing to reframe mobile competition in a more historically grounded light.
Perhaps regulators will find their way without the help of a thoughtful, tenacious tech press; stranger things have happened. But judging by The Verge, Wired, and the FT, they're going to need all the luck in the world.
FOOTNOTES
Understood through the lens of price segregation, we can see that there is no real competition between Android and iOS. For more than a decade, the mobile market has presented a pantomime of competition, wherein all wealthy users buy iPhones and everyone else buys Androids, while OEMs not named Apple continue to send low-volume "halo" Android devices to reviewers to keep up the appearance that they are somehow a challenge to Apple's dominance of the high-margin premium and ultra-premium market segments.
Apple and Google preside over stable co-monopolies, separated like oil and water by point-of-sale device pricing. Both understand the other will not challenge the market's segmentation, buttressed by incompatible proprietary software and services ecosystems.
For Apple, this assurance comes from the financial model for its entire enterprise. Apple does not enter lines of business where it cannot guarantee at least 30% net margin. This is a stable property of Apple's behaviour that market analysts now rely on. Any deviation from trend would not enhance Apple's market value as it expanded its market sized, but would paradoxically discount its shares by reducing traders' ability to understand Cupertino’s imputed future profits per share.
Google, for its part, doesn't understand the profitability bear trap Apple finds itself in, and fears Cupertino might release a low-margin iOS device, wiping out what little profit remains in the Android ecosystem. The Android and Pixel teams yearn to see and Android-based "iPhone Killer". For similarly structural reasons, they never will.
The Pixel brand cannot succeed because the firm will never allocate enough capital to make vertically integrate and generate scale for sales. This leaves it — along with the rest of Android ODMs — without sufficient leverage and integration discipline to produce devices with similar quality, longevity, and post-sale monetisation upside. Because Android OEMs lack the same low-SKU-count concentration of buying and production scale, profits never materialise for a promising device. Apple might only have 20% of the market, but it pours that entire volume into a small number of custom high-volume orders. From CPUs to screens to custom connectors, Cupertino always buys in extreme volume.
Android OEMs, meanwhile, split their purchasing across hundreds of SKUs, and most have smaller war chests than Google and worse prospects for vertical integration. As long as Qualcomm has everyone over the barrel (and they do), it will never be possible for an Android OEM to break the structure of the duopoly. Android is therefore destined to define low-margin devices. Knowing this drags all Android participants away from post-sale quality improvements that might allow the ecosystem to aspire to better. This sucks for OEMs and ODMs, but the volume of the business makes the structure stable, and for some, comfortable. ⇐
It's no coincidence that Apple's basic stance towards browser competition is that you can have a better mobile browser, you just need to buy a different phone, suffer the loss of all of your Apple-ecosystem services and data, and worry about the availability of important apps.
High and uncertain switching costs are core to Cupertino's suppression of browser competition, and it's bewildering that neither the tech press nor regulators seem to have clocked the gambit for what it is. ⇐
There are, of course, multiple ways to speak about these undisputed facts, and native app partisans are particularly practised at their variant of three-card monty.
When pressed, some begin reciting a list of missing PWA capabilities. This is offered as a reason to prefer native apps, and a reason why web apps are "not serious".
If handed evidence that open, interoperable versions of these features are not available because of Apple's suppression, they will claim that it is not safe for browsers to offer them. This is often couched as evidence of Cupertino's far-reaching wisdom.
Evidence that Apple's alternate — authoritarian control over APIs and software distribution — has not been particularly safe is usually dismissed out of hand. Point out that most energy invested in APIs over the past decade has worked to attenuate their power to the position browsers begin the bidding, and native app partisans reframe this work as proof of the necessity of gatekeepers, rather than evidence of their frequent fallibility.
There are also generally digressions into privacy, where native app fans seem unable to understand that it was the duopolists that provided unfettered access to shocking amounts of invasive data to native apps by default. Despite performative curbs, this situation largely persists, facilitated by the gatekeepers. The idea that we should trust them now, when they are the same unrepentant players that took shockingly little care when handing unrestricted APIs to tech's worst actors, is generally parried with "but Facebook bad!". Kayfabe is treated as serious drama. The deeper complicity is not engaged, and this line of inquiry is generally fruitless. Many wear the brand of phone in their pocket like a jersey for their favourite team, not a complex business with many incentives and cross-pressures.
These counterparties are also generally unfamiliar with the ads ecosystem and how the native duopolists created a "snoopers gap" that generated pressure for ad-funded apps to push users away from more privacy-respective, adblock-enabling browsers, and towards less mediated and transparent native app alternatives. The reality that those prompts were not the result of an intrinsic positive technology difference is not seriously entertained.
The web has a long track record of protecting users more effectively on both privacy and security than native API monocultures, and providing extension points to allow users to further shield themselves without waiting on beneficent App Store proprietors. Should that reality make a dent, the next conversational shuffle turns to browsers not already having won the field. This is couched either as evidence of some ineffable technical inferiority on the web's part or a claim for why it wouldn't be possible for a transition to start now; never mind that both Windows and macOS made similar turns on a similar time scale. It is never accepted as evidence of active suppression of the web by the gatekeepers.
Which brings us back to the start of the game.
Having played many pointless rounds with folks who, on the surface, seemed open to discussing the issue, I can only recommend checking to see what sort of phone your counterparty carries before wading in. iOS partisans are particularly attached to the idea that Apple knows best. It is often counterproductive to engage, no matter how loudly they claim to support the web.
One of the benefits of being locked in the privilege bubble, after all, is freedom from introspection. Wealth's blanket soothes the anxieties of the status-seeking mind, and supporting the nonsensical positions by those with higher status is imagined to be a harmless bit of in-group signalling. ⇐
It didn't take a genius to predict that a successful alt store would prod the duopolists to make life inhospitable for developers trying to straddle open ecosystems where they are available and gatekeeper options where they aren't. The unpredictable element was that Apple played those cards before a store even got going in earnest.⇐
