Tag: webkit

Rendering Engine Diversity on iOS

Posted on

Last week, some interesting news broke about Google and Mozilla prepping versions of their iOS browsers to use their own rendering engines rather than simply being a wrapper around Webkit, Apple’s rendering engine. If you aren’t familiar, iOS has rules that prevent browser makers like Google and Mozilla from embedding the engine that handles layout and features in their browsers. Instead, they have to use the one that Apple provides, which is called Webkit and is the engine that powers Safari. This means that the only real reason to use Chrome over Safari is the UI or features like bookmark and password sync, but other web technology differences are non-existent.

This has gotten Apple into hot water in recent years, as the overwhelming popularity of the iPad and iPhone gives Apple the power to dictate a ton about how the “mobile web” looks and acts. One imagines this possible change on Apple’s part is due to anticipated antitrust rulings & legislation against Apple mounting. Given that, it might behoove Apple to get ahead of the issue and simply relax restrictions, but either way it would appear the dam might be breaking soon.

According to Statcounter, Chrome commands about 65% of the browser market share on the desktop and mobile. One arguing in favor of allowing other rendering engines would say that there likely won’t be much of a difference in adoption numbers if Blink and Gecko are allowed to run natively on iOS, but there’s a lot to unpack about the pros and cons of such a move.

What are some of the pros of rendering engine diversity?

If Apple does this (regardless of why they do it), there are definite advantages to having more competition on iOS.

It’s likely that allowing other rendering engines onto iOS would increase competition in the market and lead to better quality and more innovative solutions. Apple has done a better job in the past few years – the Interop initiative has borne a lot of fruit for all of the major browser makers, and I’m hopeful that continues. Still, knowing Chrome or Firefox could add more pressure for Apple to up their game across the board would lead to a lot of innovation on the platform. Webkit is actually a good rendering engine in most ways but it falls short when it comes to some of the features Progressive Web Apps need. This pressure would likely force WebKit to adopt those features as well.

Users would have a greater choice of rendering engines and be able to choose one that best suits their needs. Folks could choose to use Chrome, Firefox, Arc (seriously, check out Arc) or something else if the features make more sense for them, and competitors could compete on more than just adding a few features on top of the rendering engine they are handed. In addition, this choice could lead to extensions finally making their way to non-Safari browsers on mobile. Having native 1Password integration on mobile is a game-changer and I wouldn’t entertain switching on mobile until things like that and a solid ad-blocker are available on other browsers.

This is likely wishful thinking based on what I see on the Mac (Safari runs circles around Chrome and Firefox when it coems to battery life and performance), but rendering engines may offer better performance and more efficient use of system resources than the Webkit engine, resulting in a smoother user experience. Different rendering engines may have better compatibility with different types of websites and web applications, improving the overall browsing experience. In general, many sites work best on Chrome and having fallback options when something isn’t working in Safari would be a fantastic experience for users on iPhones and iPads.

If done right, there’s a great chance we could see tons of innovation in the mobile browser space. In my opinion, Safari on iOS is a really solid browser but Apple’s incentives to prioritize some web standards (cough, PWAs, cough) might not align with their business interests (App Store and their 30% cut). Having true competition will mean that Apple will be forced to focus on the entire spectrum so that developers don’t go “Chrome only”, thus sidelining Safari on mobile platforms completely.

Are there any cons?

There are definitely cons, but the biggest one is the potential decline of WebKit as a first-class citizen. Organizations often can’t or won’t be bothered to have a testing strategy around multiple browsers, but instead choose to support the dominant browser (Chrome). Once a certain marketshare threshold gets crossed, developers and businesses will treat Gecko and Webkit like second class citizens. I don’t agree with the strategy, but locking users into Webkit/Safari on iOS & iPadOS does ensure a floor of market percentage that can’t be taken away. I do believe that a variety of standards-comptabile rendering engines should exist to keep each other in check, but creating an artificial monolopy isn’t the way to accomplish that. There are a few other risks:

Allowing other rendering engines onto iOS could potentially introduce new security vulnerabilities and make the platform less secure. Different rendering engines may have different standards for rendering web content, which could lead to compatibility issues and broken websites for users. Even if Apple does open up, I’d imagine we’ll see entitlements introduced to only allow some companies to ship their own browsers.

Also, the introduction of different rendering engines could lead to fragmentation of the platform and make it more difficult for developers to create consistent experiences across different devices. There’s also the risk that allowing other rendering engines onto iOS could decrease the control that Apple has over the platform and potentially result in a less consistent and user-friendly experience.

The biggest risk for Apple is WebKit’s decline, but that assumes they do nothing to compete. If they open things up and also invest in their platform, I’m confident engineers will continue to build toward standards and Safari/WebKit will be fine.

What do I hope happens

As a Safari user, I really hope to see increaesd competition as it should make Apple’s browser better but also gives power users an off-ramp if they need more functionality. Yes, there is a risk to opening up to allow other engines but I personally think it’s worth it. The gravity of a default experience will still draw the vast majority of iOS users to Safari and as a result force most companies to still support WebKit. The increased competition, however, should be a good thing for all consumers.

There’s a great series on browser choice on iOS that’s worth a read. I commented on this a few years ago and I still believe the same thing. Alex Russel can be correct but also have a perspective that’s very Google-centric as well. The truth is likely somewhere in the middle.

To Safari’s credit, Webkit has been getting a ton of investment in the past 12-18 months. I admire the Safari and Firefox teams’ focus on privacy and want them to remain as a counterweight to Google and their desire to use “standards” as an argument to push their own vision for the web on all of us. Funny how it typically involves us spending more time using the web and giving up our data in the process.

This year’s WWDC will be very interesting, as I’d imagine if we’re going to hear about changes to Apple’s browser policies, that’ll be the time they’ll roll out.

Progress Delayed Is Progress Denied

Posted on

From The Infrequently Noted blog:

Apple’s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.

The author makes a lot of good points about where Webkit lags behind other browsers, and what its strengths are. The main thrust of the argument is that Apple won’t let other browsers onto iOS without being a branded interface wrapping around WebKit and that is harmful to users and the overall Open Web as there is no choice. Further, it puts a dent into Apple’s argument that people can always make a web app if they don’t want to participate in the App Store because the tech isn’t there to fully replace what many native apps do today.

Any time a tech company like Apple is insulated from competition, consumers suffer. iOS needs to open up their app store to alternative browsers as it will force Apple to compete more than they do right now. To their credit, they’ve done the bare minimum recently and allowed a non-Safari browser to be set as default, but they need to go the additional step and allow browsers to use their own engines. Not only would this be a win for the open web, but it would also increase competition and likely force Apple to invest more in their browser engine. There’s a lot they can differentiate on, but I don’t want it to be at the expense of web technologies advancing. I also want WebKit to be the best rendering engine out there because they focus on performance and security over chasing every single API, as that’s an area they can really hang their hat on. I personally feel like Safari on both the Mac and iOS has gotten worse in the past few years from a UX perspective (I’ll save that for another post) but better from a performance perspective. However, it would appear that WebKit as a standards-supporting platform has gotten worse. I hope they can find a good balance between the two.

This assessment can be true and it can also be true that the author is looking at the situation through Google-colored glasses. Google wants to push the web as much as possible because the web is more likely to have ads than an app would, so a more robust, “app-like” web means more opportunities for them to track and target you.

Safari and the User Centric Web

Posted on

If you haven’t been keeping up with this small-scale drama, Nolan Lawson wrote an article about a week ago about how Safari is falling behind other browser vendors.  This led to a pretty large outcry from the Apple faithful (which, honestly, I typically consider myself part of) and finally a slight backtrack from the author.

I think his biggest mistake was saying “Safari” rather than “WebKit” in the title.  If you do web development for a living you know that Chrome/Blink is the best platform for building cutting-edge stuff on the web and Webkit is starting to lag behind.  There are probably tons of reasons why Google forked Webkit in 2013, but Blink has raced ahead of Webkit’s abilities – and Apple’s yearly release cycle of developer-facing features has a lot to do with that.  3 or 4 years ago it was unheard of to have to apply polyfills to account for any issues in Safari – I mean, polyfills were for IE, right? – but these days I do find a handful of bugs cropping up during our QA process that I’ve had to remedy in my personal default browser.

The rebuttals from the Apple faithful were kind of comical, trying to pit Google’s Chrome against Safari in an effort to say Safari is focused on privacy and battery/performance (it is, and that’s why I love it), but those two things don’t have to exist independent on one another. I applaud the Safari team for a lot of the new user facing features they’ve rolled out recently (some of the new features of El Capitan in particular look really nice), but I’m sure even they would admit the WebKit team and the Safari UI teams are focusing on different agendas and release cycles.  If the author had kept to talking about WebKit instead of ‘Safari’ proper, I bet a lot of the fairly uninformed Apple bloggers would have stayed on the sidelines.

All that said, I do hope that Apple picks up their slack on the rendering engine front – if they want to make Safari’s user facing changes part of their yearly OS updates, that’s fine with me but the rendering engine fixes should roll out more frequently and in greater overall volume.  I love Chrome’s rendering engine, dev tools, and their update cycle/philosophy.  But I hate the UI and battery impact with a passion.  I doubt we’ll see the ability to set new default browsers on iOS anytime soon, so I hope I can stay in the ‘Safari ecosystem’ , but that requires quicker integration of new web technologies, involvement in the web dev community, and I’m not sure Apple wants to do those things.