The State of Chrome on Mobile

Follow Arekibo

When attending Beyond Tellerrand in Dusseldorf, one of the speakers was Peter-Paul Koch (lovingly known as PPK). He spoke about the state of Chrome on Mobile, or as he called it “Chromia” (a derived plural of Chromium). It really was a fascinating talk in that it very quickly became clear as to why sites can look SO broken on Android devices. (PPK writes extensively about this on his blog). This blog post is a “distillation” if you will, of his data.

First off, this will appear to be quite a technical post, but bear with me. Chrome has a habit of displaying design and site implementations differently across various different Android devices and users aren’t always aware why. In case you didn’t know, the default web browser on Android has always been a variation on Google Chrome, and only recently actually became a stand alone browser by the same name within the Android infrastructure. It is this disparity of browsers that results in your website being displayed so differently.

Secondly, why no iOS? Well, the reality is that iOS uses Safari WebKit as it’s browser and any webviews (an app which opens a webpage within it) use that version of Safari WebKit view. Even Chrome uses the same Safari WebKit view, it just allows users to tie into and access Google Services, but it’s all still the same browser and web page rendering engine. So how a site renders in Safari on an iOS device, is the same as it renders when it is opened within the Facebook App, which is the same as how it is rendered when it is opened in Google Chrome. This makes perfectly logical and logistical sense.

But then there’s Android.

Android doesn’t play by any of these rules.

In the beginning, there was Android and Android used its own version of web browser called, intuitively enough “Android Browser.” This was a scaled back version of Chrome, based on WebKit (so, close to what iOS was doing at the time, but not very). Android also allowed App developers to chose the webview themselves (i.e. choose which version of the Android Browser to render their content in). This, in part, has become part of the major problem of the Android OS fracturing. The frustrating part of this is that even though the Android Browser evolved, developers could continue to use older versions of webviews. The development process or producing an Android App is in part to blame, as developers can lazily choose a specific version (rather than a range of versions) of webview for their app, which stays with the app until updated. So no matter whether the actual browser updated with an Android update, the webview of the app stayed the same.

Once Google introduced Chrome as a standalone browser on Android 4.0, the devices had two versions of WebKit, the built in Android Browser and the Chrome App. This meant that most apps developed at the time, continued to use the built-in browser webview. Even as Chrome replaced Android Browser and became the default web browser on these devices, the webview continued to use the older WebKit. This continues today.

This all sounds very confusing, so what does it mean in numbers?

On a pre-Android 4.0 device, the embedded Android Browser (WebKit) version is 533.1 or 534.13 (on Android 3.2.1). This is roughly the equivalent of Chrome 18. On Android 4.0 and up, the webview version of WebKit ranges from Chrome 27 up to Chrome 40 (depending on the OS). But an app such as the Facebook App, might use a webview of Chrome 27*.

So this means, on the latest device, your Chrome browser is using version 40, but your Facebook App is using version 27.

Additionally, brands like HTC, Samsung, Sony and LG, who make a “skinned” version of Android, pick and choose the elements they will include in their Android releases, so there is no guarantee that their webview version is up to date with the latest version of Android.

Google are as sick of this as everyone else. So from webview 37, they have vowed to ensure that the webview in apps is updated in line with the webview of the native browser. However, it’s a wish, not a requirement and so other brands will continue to do what they like. It will take many iterations of Android before the webview standardises and comes in line, parallel with the browser. Google would love to be in Apple’s single webview version world, but they started off badly and brought this upon themselves.

And that’s why your site stats say so many different versions of Android are accessing your site.

Many thanks to Peter-Paul Koch for such an (enlightening and informing talk), please do check out his (very in-depth source material). Also thanks to (Jim Bergman for the data on versions of WebKit on different Android OS versions).

*Actual details are hard to find out, so this is a best guess.