Define different types of webviews

[NiklasMerz]

Use case name

Define different types of webviews

Submitter(s)

Niklas Merz

Motivation

As we discuss more and more use cases it might be helpful to define and name the different uses of webviews. Webviews can be used in many different ways and some of them are vastly different in terms of privacy and security implications. It could be a good idea to separate them into different categories to discuss them better.

Stakeholders

Browser vendors
App developers

Analysis

We can already see these different categories of webviews with the APIs available on the two big mobile platforms. Android offers a powerful webview API and Chrome Custom Tabs. iOS has WKWebView for a rich webview API and SFSafariViewController for a more browser-like experience embedded in native apps.

The webview APIs offer powerful features for example injecting JavaScript or other interactions with the pages loaded into the webview. These features require the designers of the webview APIs and app developers to think a lot about the security and privacy implications of their design choices. Webviews that allow the user to navigate the web freely need to be much more secure and restricted than webviews that just allow code under control of the app developer.
Webviews are used a lot to build the UI or core features of apps. These apps could benefit from more control over the native parts of the app or vice versa the native code might want to have more control over the web content.
The distinction between browser-like webviews and full webviews embedded into apps is the most obvious one but there are many more like we see with ePub and mini apps.

If there are different types of webviews with different use cases and feature sets app developers could benefit from more freedom or security and privacy. Browser vendors could roll out powerful features for developers of apps built around webviews but still keep the browsers and browser-like webviews secure.

Related W3C deliverables and/or work items

How is the issue solved in the Browser, and what’s more is needed?

Webviews and browsers currently always have the same features and restrictions. Different webview implementations share different APIs to interact with the webview content.

[QingAn]

As discussed in 2022-07-06 meeting, it would be helpful to elaborate the detailed different features of WebViews @NiklasMerz

[NiklasMerz]

Name	Platforms	Description	Features	Limitations	UX flexibility	Usage Example	State shared
Android Webview	Android	Default WebView implementation on Android	Rich API with JS and CSS interaction, Tie WebView and native APIs together	Features equal to current Chrime but some Web APIs are not supported	Allows you to mix native content with the WebView and to resize it	Hybrid Frameworks (Cordova, Capacitor)
Custom Tabs	Android	API for opening browser-like WebViews on Android	Browser navigation and conveniance features like password fill	App has no access to Web content	Covers the entire application with some minimal top bar customization	Link preview in social media apps
SFSafariViewController	iOS, iPadOS	API for opening browser-like WebViews on iOS	Browser navigation and conveniance features like password fill	App has no access to Web content	Covers the entire application with some minimal top bar customization	Link preview in social media apps
UIWebView (deprecated)	iOS, iPadOS, macOS	Soon-to-be-removed WebView API of iOS	Rich API with JS and CSS interaction, Tie WebView and native APIs together	Some current Web standards not implemented. Performance and security wise inferior to WKWebView, deprecated	Allows you to mix native content with the WebView and to resize it	Hybrid Frameworks (Cordova, Capacitor)
WKWebView	iOS, iPadOS, macOS	Default WebView implementation on iOS	Rich API with JS and CSS interaction, Tie WebView and native APIs together	Features similar to current Safari but some Web APIs are not supported	Allows you to mix native content with the WebView and to resize it	Hybrid Frameworks (Cordova, Capacitor)
WebView2	Windows	Default WebView implementation on Windows	Rich API with JS and CSS interaction

This is the first draft of WebViews from my memory and experience with mobile platforms.

Feel free to add more information and WebViews

Gist with raw markdown

[muodov]

There is also WebView2 by Microsoft that deserves a separate row in this table.

[rayankans]

Thanks for the table @NiklasMerz !

I think it would benefit from adding a UX flexibility column, since that is also a major consideration when choosing an appropriate embedding technology. For example, Android WebView allows you to mix native content with the WebView and to resize it, whereas Custom Tabs cover the entire application with some minimal top bar customization.

I would also rename Chrome Custom Tabs to Custom Tabs, since Chrome just provides an implementation of the Android API.

[muodov]

Would it be useful to add some examples of apps using each of those technologies? It could turn out vague, but might also reveal some clear use-case areas

[dontcallmedom]

see also https://www.w3.org/2021/Talks/dhm-tpac-webviews/?full#8 and https://www.w3.org/2021/Talks/dhm-tpac-webviews/?full#9 for another perspective on this

[NiklasMerz]

I slightly updated the table above. The slides from @dontcallmedom are already perfect in comparing the actual WebViews available today.

Is the table really needed? We could make the table a file in the repo and accept PRs to update it. Doing this in comments is quite cumbersome. What do you think?

The main thing I was thinking about when I filed this use case is that we could try to find names and definitions for different types of WebViews. I had Android WebView and WKWebView as "full-fledged WebViews" and Custom Tabs and SFSafariViewcontrollers as "WebViews for a browser-like experience in apps" in mind. The names are not really good for these different categories. Also there might be more types or the lines between types are actually blurry.

If I think this further I think it would be great to have standards for different kinds of WebViews with each of their own use cases. This could mean WebView providers could build more specific APIs to better suit these use cases. For example the browser like APIs can be really secure and optimized for general web content. The more generic WebView could focus more on developer flexibility and tailor the security and UX more around use cases for app developers using web technologies differently than "normal web content".

[aluhrs13]

The slides from @dontcallmedom are already perfect in comparing the actual WebViews available today.

@NiklasMerz - As a Windows/Desktop representative here I disagree 😂 (no offense @dontcallmedom). I'm happy to add some details on Windows WebViews, notably - WebView2, WebBrowser, WebView, CEF, and Electron. I like the idea of checking in a comparison table and I can go put a PR out to add some Windows context.

If I think this further I think it would be great to have standards for different kinds of WebViews with each of their own use cases.

Definitely agree. In my head there's three fairly distinct buckets with some overlap between each:

1. Full App - The Cordova, Capacitor, or Electron style hybrid app. The vast majority of UI and the app is in a WebView.
2. Partial App Content - Some native apps will use a WebView in a small number of places to have reduce code re-use. For example, I could have a native app on every platform with my main functionality native, but the app's settings are basically the same on each platform, so I use a WebView for that page.
3. Generic Content - User clicks a link to some content and I want to host it in my app. The Custom Tabs or SFSafariViewController case.

[aluhrs13]

@slightlyoff wrote a good post and did a talk on the use of WebViews for generic content that users would likely prefer to be handled in their default browser. In the vein of this issue, it'd be valuable for us to have a stance on the right way to approach the use of WebViews.

Are we open to adding discouraged use-cases like using a "normal" WebView for browser-like experiences? Custom Tabs or launching the user's preferred browser being the correct technology for that, potentially evolving into standards proposals to enforce that for top-level third-party content.

[chasephillips]

Thanks for your work here, @NiklasMerz and others. FYI, as part of my team's work, I wrote Survey of web embedding technologies.

My intent with that doc was to provide a broad perspective on what systems are available or where web content is embedded using those systems in ways exposed to devs or users. That led to my looking beyond just webviews towards web embedding technologies in general, which we found useful. Feel free to reuse or include elements from that doc in the markdown here.

[QingAn]

Brief discussion in 2022-08-09 meeting
Android WebView, WKWebView, WebView2: full-fledged WebViews
Custom Tabs and SFSafariViewcontrollers: WebViews for a browser-like experience in apps