Performance Measurement is easy to get wrong. Healthy competitions feature competitors trading the lead with regularity. As reliably as the Sun rises in the East, new benchmarks launch projects to re-architect internals to pull ahead. The Performance Argument #Īs an engineer on a browser team, I've been privy to the blow-by-blow of various performance projects, benchmark fire drills, and the ways performance marketing impacts engineering priorities.Īll modern browsers are fast, Chromium and Safari/WebKit included. Safari has many good features, and in an open marketplace, choosing it is entirely reasonable. MacOS Safari is compelling enough to have maintained 40-50% share for many years amidst stiff competition. Safari trails competing macOS browsers by roughly the same amount, but it's not a crisis because genuine browser choice enables meaningful alternatives. Lastly, while this post does measure the distance Safari lags, let nobody mistake that for the core concern: iOS App Store policies that prevent meaningful browser competition are at issue here.
We should not expect uniformity in the short run - it would leave no room for leadership. It's good for teams to be leading in different areas, assuming that the "compatible core" of features continues to expand at a steady pace. Even worse are situations that cannot be addressed through browser choice. What's unhealthy is an engine trailing far behind for many years. Second, projects having different priorities at the leading edge is natural and healthy. Apple Corporate is at fault, not Open Source engineers or the line managers who support them. They are, pound for pound, some of the best engine developers and genuinely want good things for the web. We should look at trends rather than individual releases to understand the gap Apple created and maintains between the web and native.īefore we get to measuring water levels, I want to make some things excruciatingly clear.įirst, what follows is not a critique of individuals on the Safari team or the WebKit project it is a plea for Apple to fund their work adequately and allow competition. It might be raining features right this instant, but weather isn't climate. We have to check reservoir levels and seasonal rainfall to know if we're in a drought. These points can be simultaneously valid and immaterial to the web's fitness as a competent alternative to native app development on iOS. Misdirections often derail the debate around browsers, the role of the web, and App Store policies on iOS. This post mines publicly available data on the pace of compatibility fixes and feature additions to assess the claim. This is a bold assertion, and proving it requires overwhelming evidence. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.
Apple claims that browsers on iOS are platforms sufficient to support developers who object to the App Store's termsĪpple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered.Apple forces developers of competing browsers to use their engine for all browsers on iOS, restricting their ability to deliver a better version of the web platform.Apple bars web apps from the only App Store allowed on iOS.Speaking of being hobbled, the original post gave Apple credit for eventually shipping a useable implementation of IndexedDB. This hobbles gaming and immersive media experiences in a way that is hard to overstate.
EXPERT CHOICE SAFARI 12 UPDATE
Update (June 16th, 2021): Folks attempting to build mobile web games have informed me that the Fullscreen API remains broken on iOS for non-video elements.