What if I told you 14% of the usage your Web content is getting is through a “browser” you probably didn’t think of when you designed your content?

To put that figure in perspective, the global usage share of iOS Safari is around 11%. Can a Web content strategy ignore that kind of usage?

I live and breathe Web every day, and I am responsible for ensuring W3C technologies are positioned as well as possible for widespread adoption by developers. Yet I had not realized until a few months ago that the cumulative usage of WebViews – since that’s what I’m referring to here as a source of that usage – had become such a key mechanism to use content on the Web.

What are WebViews and why are they used?

The reach of the Web Platform via Web browsers is humbling: using technologies standardized in W3C and elsewhere, Web developers can reach more than 4 billions of end-users through a single click or tap on a link.

These technologies have proven to be such a useful lingua franca for digital services that Web technologies are also extensively used outside of browsers, and in particular, through software components that can be used to render Web technology-based content, referred to as WebViews.

WebViews are used pervasively, both on mobile and desktop platforms, for a variety of reasons, among which sit prominently re-using part of the Web infrastructure in a native ecosystem (e.g. for advertising, authentication, payment), providing a platform to integrate apps or contents from third-party providers (e.g. MiniApps, embedded games on various platforms), or rendering traditional Web content directly within a native app (so called in-app browsers).

More Web, more ♥, right?

At first glance, that additional reach of Web technologies is a great opportunity for these open standards, designed for all.

But when I started looking more into it, the picture quickly became less rosy: Web technologies used in a browser come with a set of explicit and implicit expectations about how they will be interpreted. Once you move out of that framework, some assumptions no longer hold, bringing uncertainty about how Web content gets rendered and executed. For instance, WebViews don’t typically implement the same set of features as the default browser on the said platform, and any Web API that prompts users for permissions will fail in a WebView if the native app developer doesn’t specifically handle these situations.

The name WebView encompasses a wide variety of components that all come with their own specificities and restrictions, well beyond the usual cross-browser interoperability issues Web developers already know they need to mitigate. Android WebView, iOS’ UIWebView and WKWebView, Windows’ WebView2 combine and contrast with other ways of rendering Web content in native apps on these platforms (Android Custom Tab and Trusted Web Activity, iOS SFView and ASWebAuth), and their behavior depend on how the developer of their embedding app chooses to use them.

Upon exploring this landscape, it felt to me that not only most Web developers don’t really have a working knowledge of that complex landscape, but that most of us developing standards targeting Web browsers do not really account for these rapidly growing consumers of our technologies.

Can we fix it?

Working with André Bandarra, from Google, I organized and ran a couple of unconference sessions during TPAC 2021, W3C’s Annual Conference held last October – you can find the records of these sessions (October 19, October 20), and you may in particular find useful the slides I presented to introduce the problem space.

Overall, it was clear that this topic was a blind spot in our current approach to bringing value to developers and end-users through our standards, and would benefit from more direct attention.

Working with Qing An from Alibaba (co-chair of the MiniApps Working Group) and Peter Beverloo  who is the Technical Lead of the relevant work in this space at Google, I am happy to announce that we have just launched a WebView Community Group which aims, as set in its proposed charter, to identify, understand and reduce the issues arising from the use of WebViews.

Given the complexity of the landscape, the group will initially focus on collecting WebView usage scenarios and the challenges they pose, to get a better sense of the right mechanisms to address these challenges – which would be developed in a second phase of work.

If you are interested in bringing insights on the topic, this WebView Community Group, as all W3C Community Groups, is free and open to all to join and will likely need all the constructive contributions it can get to achieve its goals!

One thought on “Making WebViews work for the Web”

1. ethang says:
   March 17, 2022 at 2:27 pm

   Thank you. I’ve run into a lot of issues around this. Such as making a video share web app available on a desktop app. Without access to permissions API, the solution I saw to this was to disable browser security on chromium, which just automatically connects to media devices instead of requesting access. This does not sit well with me at all.

   Being able to use web apps on desktop through webviews means more control over the browser window as needed. But there are just way too many sacrifices to make that work right now.

   I have been looking at .NET Maui to build multiplatform desktop AND web for one code base. It is meant to build everything to WebAssembly for the web. I think initial load on that would be way too slow but WebAssembly seems like the only out for these sorts of problems right now.

   Reply