Google announces Chromium WebView
my response to a big change in Android KitKat
In this post, I discuss Google’s announcement, its impact on hybrid-app developers and possible future improvements. This is a cross-posting of an entry I made on my employer’s blog earlier.
Google’s latest Android confectionary has been announced: 4.4 KitKat. One of the changes I’ve been most anxious for is the much needed update to the WebView. Officially, developers have been clamoring for this (at least) since February 2012, but the old WebView had been a problem since Android’s debut in 2007.
WebView? Hybrid apps?
Without getting into the nitty-gritty,
WebView is a native component available when building native apps for Android. On iOS there is a similar
Native apps that use WebView components are often referrred to as “hybrid apps”. They mix and match native code and web code to (hopefully) offer the best of both worlds to end-users.
great for performance-sensitive functionality e.g. maths, games, transcoding
great for platform-specific functionality e.g. inter-app communication, app store presence, in-app purchases, sensors, cameras
platform vendors (e.g. Apple, Google, Microsoft) work hard to regularly release new native functionality with each platform update
developers have to learn each target platform individually, although some concepts are portable
code written is platform-specific, so Android code will not run on iOS, etc
great for displaying content already available in this format, and there’s loads of this already on the Web
standards take years to develop, so a new native feature might take years before it is available with pure web technology
while they mostly agree on behaviour, different browser engine vendors (e.g. Apple, Google, Microsoft, Mozilla) have different bugs and quirks
Previous versions of Android include a version of WebKit (the web engine used by Safari and Mobile Safari) that has not been updated since 2011. In addition to stagnating over the last two years, it has long been the subject of much lamentation. There are (at the time of writing) 370 reported issues for “webview” and 244 reported issues for “webkit” (with some overlap).
Some of the problems include:
missing or incomplete support for many newer standard web technologies e.g. Canvas, Web Forms 2.0, Web Workers, IndexedDB, Web Sockets, CSS Level 3
missing or incomplete support for older standards e.g. XPath and XSLT in Android 2.x, SVG and GIF in older Androids
several unexpected rendering and behavioural glitches e.g.
selectelements in Android 2.x,
poor performance e.g. CSS Animations, touch responsiveness, touch scrolling
limited Java API for app developers e.g. unable to override lower-level behaviour as with UIWebView on iOS
difficult and painful to debug
many users are stuck with old copies much as they were with old versions of Internet Explorer
Chromium WebView in KitKat
After five years of near-silence on the matter, Google finally provided an answer with Android 4.4: Chromium WebView. This is based on Google’s excellent Chrome browser, version 30 to be specific. This promises to drastically simplify debugging and improve web feature support and performance. It is possible that the majority of the issues reported against the previous implementation have been addressed.
Google provided an overview of the new WebView, and I’ll discuss some of the details I take issue with.
“Chrome for Android is separate from WebView”
There are other issues here, but for now I’ll just point out that there is a minor waste of persistent storage space. Not a big deal when new devices have 16GB and 32GB of space, but this could be an issue for the low-end devices that KitKat is supposedly targeting.
“Chrome for Android supports a few features which aren’t enabled in the WebView”
The listed features not provided by WebView (but available in pure Chromium if you compile it yourself) are WebGL, WebRTC, WebAudio, Fullscreen API and Form Validation. This list is not exhaustive, so there may be more.
form HTML can use this in Chrome for Android and other modern browsers.
“WebView will continue to be tied to releases of the Android platform for the time being”
And here’s the major consequence of keeping Chrome for Android separate from WebView: updates. Android OEMs produce many devices at different price points (at the behest of carriers) and historically fail to keep all but the top-of-the-line devices up to date. That means the majority of Android devices sold wind up running stale versions of Android forever.
Android 2.3 “Gingerbread” was obsoleted in October 2011 by 4.0 “Ice Cream Sandwich” and still represents a at least 28.5% of the user base. Hybrid app developers will likely still have to support devices running the old WebView, perhaps for the next 3-5 years if this rate doesn’t improve.
This is a very different scenario to the update frequency that Firefox and Chrome web developers are accustomed to: these browsers are automatically updated almost monthly.
One positive consequence of this model is that the open source version of Android accurately represents what is shipping on new devices. This is good for the open source community, and for app developers curious about how the platform functions.
It remains to be seen what Google means by “… for the time being”.
Play Services: the alternative
It’s still possible that Google may change the way they distribute Chromium WebView in future. If they were to exploit the Play Services bundle for this, they could update every device with the Play Store (the majority of Android devices outside of China) regardless of Android operating system version.
As a new API, it would not necessarily be beholden to the same behaviour as the old WebView, so it could also be an opportunity to provide new features (like the ability to override low-level behaviours, network access, etc).
Once available, Chrome for Android could be adjusted to use it instead of providing its own copy, allowing for nearly perfect consistency between web apps in the browser and web code in hybrid apps.
For apps tailored to use it, hybrid app developers could immediately benefit from updates without waiting the usual 3-5 years as with Android OS updates. Google would be able to innovate at the pace usually associated with web browsers without needing to wait for manufacturer support and carrier approval.
A negative consequence of this model is more thoroughly explored by Ars Technica. APIs that are part of Google Play Services cannot be relied upon with devices running Amazon’s fork of Android, or those devices running in China. These also diminish the value of open source Android within the community.
“it brings … remote debugging of web content using the Chrome DevTools”
Web code in a hybrid app is likely to have the same or similar logic regardless of the version of Android that the app is installed upon. Thus, developers may be able to use their KitKat devices (or the emulator) to diagnose logic issues present when the app runs on JellyBean and older. So this does improve our diagnosis capabilities for what may be a decent range of bugs.
This also marks debug parity between Android’s WebView and iOS’ UIWebView. Diagnosing bugs just got a heck of a lot easier.
Google’s lofty goal of replacing those Gingerbread devices with KitKats may yet manifest, that remains to be seen. I’m sure my fingers aren’t the only ones crossed in that regard.
In the meantime, Google has provided us with a “glass half full” update: it doesn’t solve all of our problems, but it breaks 2 years of stagnation and provides remedial relief to a large portion of frustrated Android app developers.