Publishing apps using web technologies

[AshleyScirra]

Submitter(s)

Ashley Gullen, Scirra Ltd

Motivation

Web apps can be published to app stores such as the Apple App Store, Google Play and Microsoft Store. This often involves bundling all the resources for the web app along with a native app that displays it using a web view. There are also hybrid cases where apps mix and match native and web content, but here I am focused on the web content being the main content of the app.

In this use case I am also focusing on the webview only displaying content bundled with the app itself. It would not be used to browse to any third-party content. This is a very common model for webview-based apps, and significantly alters the considerations for security and trust: the web content can be thought of as part of the app, as opposed to untrusted remote content.

When publishing apps this way a common problem is API compatibility. This is discussed in more detail below under Analysis.

Stakeholders

Web app developers publishing with frameworks like Cordova and Capacitor rely on WebViews to essentially run the main content of the app.

A similar development style is also possible on desktop (using WKWebView on macOS and WebView2 on Windows). However I would not personally consider frameworks like Electron or NW.js as WebViews. They are more like modified builds of an entire browser (Chromium) and do not tend to exhibit the same problems faced by WebViews. I would define a WebView as something that displays web content in the context of a native app, allowing mixing both web and native content. That covers the Windows WebView2 but not Electron or NW.js.

Analysis

WebViews generally have less API compatibility compared to browsers. Here are some examples:

• The Android WebView does not fully support:
  • Web Share API
  • VirtualKeyboard API
  • getDisplayMedia
  • Web Speech API
  • Web Bluetooth API
  • safe-area-inset-* CSS properties
  • requestVideoFrameCallback
• Windows WebView2 does not fully support:
  • Web Share API (although there is some confusion in that issue about whether it is fixed)
  • User gesture restrictions are somewhat inconsistent
  • window.moveTo does not work out of the box

There are probably more examples I've missed. This presents a problem for web compatibility. Browsers may be thoroughly tested and advertise supported features, but often web content stops working correctly when moving to a WebView due to API deficiencies. It's sometimes possible to essentially polyfill them by communicating with the containing native app to fill in the gaps (as frameworks like Cordova do). However this can still break web compatibility if it's not 100% spec compliant, adds extra development complications, and is not always feasible (e.g. a native app likely can't polyfill requestVideoFrameCallback).

Apple's WKWebView actually works surprisingly well - for the APIs that are supported, they tend to just work in WKWebView too (e.g. Web Share API works in WKWebView). However several of the noted APIs that are problematic on Android are not yet supported in Safari, so this may yet become a problem.

It's also often desirable to customise WebViews to work more similarly to apps. For example if the containing app already has permission to access the file system without the user being notified, then the WebView should not have a permission prompt. (This WebView2 issue demonstrates that being a problem.) Common customisations are:

• Handle permissions differently - as noted above, but also to delegate permission requests to the app - e.g. requesting to use the camera. This is another thing that is not always web-compatible and needs additional work to support.
• Handle user gestures differently - e.g. native apps can usually play audio immediately, but browsers mute the page until user input. Once again if the native app has the capability, the WebView should automatically have the capability too.
• Handle monetisation such as IAP and ads. Ideally the Digital Goods API would be compatible in WebViews for IAP, but AFAIK it is not supported. Also AFAIK most ad services treat web browsers and native apps as completely separate, whereas WebViews are a hybrid.
• Communicate with the native app to access non-standard features - currently every platform has its own messaging API but these could be standardised (possibly related to Consideration of WebView APIs #5)

Related W3C deliverables and/or work items

I'm not sure what the solution is but perhaps the specification could mandate that features must work in WebViews too. Specifications for permissions and user gestures could have wording to cover alterations for WebView use cases. A new specification could be designed to handle app-to-webview communication.

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

In browsers everything tends to just work. I think there is a much greater focus on web compatibility across browsers than WebViews, so sometimes details specific to WebViews are neglected. A good example is the Virtual Keyboard API. The specification appears to assume use in a browser where the full window is dedicated to the browser. Since this is not necessarily the case with WebViews (although it can be), the API is simply not supported there. It does not seem like the WebView case was seriously considered, or perhaps it was deliberately omitted - either way it's now a web compatibility problem. All the problems that API solves must now be handled differently in a WebView.

Perhaps the main solution is just technical work on WebViews though - ideally everything would work out of the box in a web compatible way, and provide APIs to customise behavior if the default is not suitable for a specific app.

[rayankans]

Thanks for the detailed analysis!

Agreed that the gaps in Web Platform support for WebViews are hard to keep track of and often confusing. Consistency in the Web Platform across WebViews seems to be a recurring issue.

I'd like to add a bit more colour to the compatibility issue you brought up, that there seems to be two general categories web content embedders / webviews fall into:

• reduced web platform support + control over web content, like the Android WebView and Windows WebView2
• full web platform support + no control over web content, like installable PWAs, and Android Trusted Web Activities

Customizing/delegating permissions is also an interesting point, I wonder to what extent that can be done while keeping security & privacy in mind.

[QingAn]

Thanks for the analysis.

This is a bundle of multiple specific use cases. As mentioned by @rayankans , sub-categorizing them would be helpful.

• Support the functionalities that have been implemented by Web platform. But it is not easy to simply enable these functionalities in WebView at once, and some functionalities might not be needed in the WebView. Therefore, I suggest to further describe the detail and motivation of each desirable functionality and related use case.
• New functionalities that are specific in the context of WebView, such as customizing/delegating permissions, communication between WebView and Native. Having detailed description would be greatly helpful.

[dontcallmedom]

in terms of documenting which Web Platform features aren't available on WebViews (and more generally giving guidance to developers on dealing with WebViews), see also openwebdocs/project#111

[muodov]

For the permissions issue, automatic sync with app permissions wouldn't be sufficient, because the security model is not necessarily the same. For example, for full featured browsers like DuckDuckGo, it is important for the app to have more granular control over permissions per site. See MicrosoftEdge/WebView2Feedback#2427 as an example.

[QingAn]

For the permissions issue, automatic sync with app permissions wouldn't be sufficient, because the security model is not necessarily the same. For example, for full featured browsers like DuckDuckGo, it is important for the app to have more granular control over permissions per site. See MicrosoftEdge/WebView2Feedback#2427 as an example.

@muodov Interesting point. Suggest to discuss this in July 6th conf call

[QingAn]

@muodov As discussed, please open a new issue on the permission control.

[muodov]

See this separate issue for permissions management: #23