# Apple's WebKit Feature Pace and Browser Competition on iOS

DevFeed: [Apple's WebKit Feature Pace and Browser Competition on iOS](<https://devfeed.tech/articles/comforting-myths-26558.md>)

Original publisher: [Read original article](<https://infrequently.org/2025/09/cupertinos-comforting-myths/>)

Author: Alex Russell

Published: 2025-09-23T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [WebKit](<https://devfeed.tech/topics/webkit.md>), [browsers](<https://devfeed.tech/topics/browsers.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [apple](<https://devfeed.tech/tags/apple.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [features](<https://devfeed.tech/tags/features.md>), [standards](<https://devfeed.tech/tags/standards.md>), [web](<https://devfeed.tech/tags/web.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

## AI overview

This opinion article examines Apple's approach to web-platform collaboration and feature development, arguing that WebKit has trailed Blink and Gecko while Apple's iOS policies prevent competing browsers from shipping alternative engines. It introduces data intended to assess claims about Apple's handling of challenging APIs.

## Source excerpt

Update: The charts below were inappropriately snapped, compressing the range of values. This has been corrected. Feature availability numbers also changed since drafting and have been updated. In several recent posts, I've attempted to address how the structure of standards bodies and their adjacent incubation venues accelerates or suppresses the potential of the web as a platform. The pace of progress matters because platforms are competitions, and actors that prevent expansions of basic capabilities risk consigning the web to the dustbin. Inside that framework, there is much to argue over regarding the relative merits of specific features and evolutionary directions. This is healthy and natural. We should openly discuss features and their risks, try to prevent bad consequences, and work to mend what breaks. This competitive process has made browsers incredibly safe and powerful for 30 years. Until iOS, that is. Imagine my surprise upon hearing that Apple isn't attempting to freeze the web in amber, preserving advantages for its proprietary platform, and that it instead offers to redesign proposals it disagrees with. Contents Background Is Apple Engaged In Constructive API Redesign? General Trends Hard Cases Overall Impressions What's Happening Here? As I have occasionally documented, this has not been my experience. I have relatively broad exposure to the patterns of Apple's collaboration, having designed, advised on, or led teams that built dozens of features across disparate areas of the platform since the Blink fork.1 But perhaps this was the wrong slice from which to judge? I've been hearing of Apple's openness to collaboration on challenging APIs so often that either my priors are invalid, or something else is at work. To find out, I needed data. Background A specific parry gets deployed whenever WebKit's sluggish feature pace comes up: "controversial" features "lack consensus" or "are not standards" or "have privacy and security problems" (unspecified). The