About webview，what is it？

What is a WebView?
Every hybrid mobile app developer has that moment. You know the one I’m talking about, when someone asks you, “So what kind of mobile apps do you develop?” Depending on context, a follow-up question might be, “Well, are you developing these apps natively?” meaning, using native languages like Swift, Objective-C, and Java. Bravely, you might respond, “Nope. My apps are all hybrid mobile” …and get ready for the blank stare. Taking a deep breath, you launch into an explanation about what a hybrid mobile app is, and how it presents its content in a WebView. Prepare now for the mother of all questions: “Well, what’s that?”

Lucy
‘Splain this! – image source

This article is an attempt on my part to save you some hand-wringing moments the next time you get cornered into a discussion of development architecture. Let’s tackle this question, “What is a WebView?”. We’ll start by defining what WebViews are, why we care about them, how they allow developers to use web technologies to build mobile apps, and then take a look at the types of WebViews.
WebViews. Why do we even?

Honestly, it seems weird – this idea that we build a mobile app using web technologies and present the whole thing in a WebView. It feels a bit like smashing a whole site into an iframe.

webviews

But the key to the weirdness is that developers can reuse the web technologies they know and love to spin up a mobile app. This is conducive to code reuse – the philosophy of write once, run anywhere.

You build with web technologies, add a bridge to native technologies via tools like Cordova, and just like that, you have a mobile app fit for the app marketplaces! In fact, WebViews can even drive desktop apps using tools like Electron.

It seems so simple. A mini web browser, e.g. a WebView, runs your app, but you can make use of native APIs.

If you have web skills but want to reach a platform on which you have little experience—iOS, Android, Windows, OS X, or Linux—using a WebView is often a compelling option. And it doesn’t have to be slow and clunky! Done right, hybrid mobile apps can often perform quite well. The Untappd app is a great example of a well-built hybrid mobile app.

untappd

Untappd, a great example of a hybrid mobile app, uses plugins to enhance its slick, native feel.
Anatomy of a WebView

In his article on hybrid mobile apps, John Bristowe identifies a WebView as a “chromeless browser window that’s typically configured to run fullscreen.” The basic architecture can be understood in this infographic, comparing native, hybrid, and web apps:

hybrid native web
courtesy of myShadesOfGray

Web View, WebView, UIWebView, WKWebView, WTFView?

There are many different names for what is essentially a minimal browser that delivers web content. In this article, I will use the term WebView to cover the chromeless browser window referenced above. There are several different types of WebViews available for different platforms which I discuss below.

If a WebView, then, is not much more than an iframe or a tab in a browser, how is it leveraged by mobile apps to support native capabilities like the ability to take a picture using the device’s camera?

This question can be answered by looking at the frameworks that utilize WebViews to present content. The best-known framework, Apache Cordova, embeds HTML5 code inside a WebView and then provides a “foreign function interface” (FFI), or a “native bridge”, to access the native resources on the device. Thus, a developer using a Cordova-friendly framework such as Kendo UI Mobile could write a few lines of code to leverage a native camera in a cross-platform-friendly fashion:

function capturePhoto() {
// Take picture using device camera and retrieve image as base64-encoded string
navigator.camera.getPicture(onPhotoDataSuccess, onFail, { quality: 50,
destinationType: destinationType.DATA_URL });
}

If you were to invoke this method on a button click, the camera would open on either an iOS or Android device, based on how the framework forms a bridge between the WebView with which the user interacts, and the FFI bridge itself that allows code to be interpreted by a native system.

Fun Fact: Cordova has been described as having evolved from a hack that enabled a Foreign Function Interface to an embedded WebView on iOS.

Although all hybrid mobile app frameworks by definition rely on standard implementations of WebViews for the app presentation tier, there are many differences in the types of WebViews available to us, depending on the framework we choose to use. Let’s take a look at some of these.
The Need for Speed

Building a mobile app using layers of technology above the native API inevitably involves some sacrifice of performance. A clever developer can often minimize this performance hit, but frameworks like to promise more.

For example, Trigger.io boasts a super-fast native bridge (“5x faster than PhoneGap!”). Cocoon.js goes farther, offering a faster experience based on both the use of Canvas+ (which allows avoidance of using WebView at all) and WebView+, a faster implementation of the native WebView.

Ludei, the makers of Cocoon.js, deplore the use of the native WebView:

The system webview is a native component provided by the operating system to be able to load web content. Webviews are a great tool provided by both desktop and mobile operating systems…but they have some problems.

Specifically, Ludei says, the problems are performance and fragmentation – so they decided to roll their own.

As a native element, the WebView is tied to the native OS, so maintaining a performant ecosystem that can take advantage of hardware speed increases as well as advances in WebView technologies while also taking into account the limitations of older devices and fragmented ecosystems (I’m looking at you, Android) is a big challenge.

As the mobile device ecosystem has evolved, so has the WebView. Let’s take a look at how the WebView has changed over the past few years based on its use across the ever-changing mobile landscape.
Types of WebViews

For the purpose of this article, I’d like to concentrate on the interesting history of both the iOS and Android WebView, which have evolved considerably recently, before discussing the brave new world of the desktop WebView.
The iOS WebViews: UIWebView and WKWebView

Since Apple made the decision not to have mobile apps run in Safari’s mobile browser, UIWebView was leveraged instead. This has had far-reaching implications for hybrid mobile apps on iOS.

As Mattt Thompson noted:

UIWebView is massive and clunky and leaks memory. It lags behind Mobile Safari, which has the benefit of the Nitro JavaScript engine.

The lack of the speedier JavaScript engine helped spur the perception of apps running in this environment as glitchy, laggy, and slower than their native counterparts.

With the introduction of iOS 8, however, developers celebrated the arrival of WKWebView.

WKWebView is the centerpiece of the modern WebKit API introduced in iOS 8 & OS X Yosemite. It replaces UIWebView in UIKit and WebView in AppKit, offering a consistent API across the two platforms. – NSHipster

Along with several performance enhancements, including 60fps scrolling and built-in gesture support, WKWebView includes the same JavaScript engine as Safari, a huge improvement over the slower UIWebView.

Why no Nitro?

While it seems like Apple was deliberately plotting to slow down UIWebView and the web apps that run in it, John Gruber noted in 2011 that Apple was primarily interested in maintaining the security of apps running on its systems. Nitro uses JIT (Just-In-Time) compilation, but since “JIT requires the ability to mark memory pages in RAM as executable”, Apple, as a security measure, does not allow this. WKWebView makes use of improved inter-application communication APIs. WKWebView now allows third-party plugins to run JavaScript on separate sandboxed processes outside the application. This ability eases Apple’s security concerns regarding third parties using JIT compilation.

A handy comparison table of the UIWebView and WKWebView components is available here in which you can see the increase in capability of WKWebView over UIWebView.

The WKWebView Cordova plugin for iOS apps in Telerik’s curated plugin marketplace offers a handy drop-in way for your iOS apps to consistently use WKWebView in a hybrid mobile app, irrespective of the device on which the user interacts with the app. This plugin promises to solve backward compatibility issues, although there are several caveats about the compatibility of this plugin with others.
The Android WebViews

On Android devices, unsurprisingly (given the vast array of devices that run Android OS), the situation is more fragmented than on iOS. TJ VanToll gives a good explanation of the situation on Android.

Whereas earlier versions of the Android OS relied on the WebKit rendering engine to power its WebView, as of Android 4.4, various versions of Chromium are implemented. Typically, with each consecutive update of Android’s OS, a new version of Chromium would also be included, thereby giving access to the new rendering engine’s capability. This clearly causes issues in backward compatibility for developers who must support earlier versions of Android.

To combat this particular problem, as of Android 5.0, the concept of the ‘auto-updating’ WebView has been introduced. Instead of the WebView version and capabilities depending on Android OS’s update cycle, the Android 5.0 WebView is a “system-level .apk” available in Google Play that can update itself in the background.

So cool to see the Android System WebView updating outside of an Android release. pic.twitter.com/qBogbej96T

— TJ VanToll (@tjvantoll) March 12, 2015

Of course, having access to the auto-updating WebView hinges up on Android users’ adoption of Android 5.0. It remains to be seen how quickly this can occur.
The Special Case of Crosswalk

Like Android’s auto-updating system, Intel’s Crosswalk project aims to bridge the gaps between old devices using old OSs and clunky WebViews and their newer counterparts. Crosswalk “enables you to deploy a web application with its own dedicated runtime”, so you are not dependent on a third-party or platform-dependent WebView. Rather, you are in the driver’s seat, and control the WebView in use by your app.

tokyo crosswalks
Cross with care! Image courtesy of Candy Chang

The Crosswalk project itself is tied to Blink, Chromium’s rendering engine, and its updates follow the release cycle of Blink. While its use is particularly helpful for Android versions 4.0 and above, it can also be used for iOS, Linux desktop, and Tizen. On Android, Crosswalk uses Chromium and on iOS it relies on WKWebView, but cross-platform developers can relax, as they can use a unified API to support most use cases. A Cordova plugin for Crosswalk uses the Chromium 45 browser rendering engine uniformly for quick implementation into your hybrid mobile project targeting Android devices.
Other WebViews

Up to this point, I have restricted my discussion of WebViews to those of most interest to hybrid mobile app developers. However, WebViews are everywhere! Let’s take a quick look at some work on WebViews that aim to replace the old in-app browsers, and then check out what’s going on on the desktop.
Other Mobile WebViews

On occasion, there’s a need to an in-app browser option to open from within a mobile app, and both Apple and Google have a few options for developers:

Safari View Controllers
In its quest to stop developers from creating fragmentation by developing custom mini-browsers to run in-app browser content on iOS, Apple has introduced the Safari View Controller in iOS9, which is a “sandboxed” version of Safari. It gives the developer a standardized environment in which to present content, while offering the user a consistent experience and several convenient security helpers that allow users, for example, to log in to a View Controller and stay logged in when visiting a related site in mobile Safari by means of shared cookies and shared login credentials. These snack-sized app views allow for a consistent in-app deep-linking experience for the iOS user.

view controllers
Safari View Controllers, image courtesy of MacRumors

Chrome Custom Tabs
The Android counterpart to Safari View Controllers is Chrome Custom Tabs. It allows developers to create a custom browser experience within the parameters of Android’s developer guidelines. They are available to all devices that can run Chrome 45 on Android 4.1+ (Jellybean). Many goodies are included in this custom WebView, including “pre-warming” of the browser in the background “while avoiding stealing resources from the application,” shared cookies and permissions, and one-tap return to the app. In addition, it allows Android developers to serve content in a faster manner to users who are navigating on devices that do not have auto-updating WebViews instead of falling back on an older, slower WebView.

chrome custom tab
An example of a Chrome Custom Tab. Note the minimal browser chrome
WebViews on the Desktop

You can find WebViews on the desktop as well, and you might not even realize that you’re using one. Slack is a great example of one of these. The user experience is both speedy and well-contained:

slack
The productivity phenomenon that is Slack. Image courtesy of MetaLab

NW.js
An interesting project created at the Intel Open Source Technology Center (thanks, Intel!) is NW.js, previously known as Node-webkit, which is an app runtime based on Chromium. It allows the developer to call Node.js modules directly from the DOM. Desktop applications are written using this library and are presented as a chromeless browser standalone, easily packaged and distributed with all the firepower of Node.js. A great use case for this library would be HTML5 desktop games.
Electron
Perhaps better-known than NW.js, Github’s Electron is another framework to help you build desktop apps. The project was originally called Atom Shell as it was the basis for GitHub’s desktop Atom editor. Companies such as Slack, Particle, and Microsoft have used Electron to build great desktop apps such as Visual Studio Code and the Slack client. A good discussion of the differences between NW.js and Electron can be found here

WebViews. Know them, love them