Through The Desktop
You can build a mobile app these days in a number of different ways. Natively (leveraging the platform SDK of Android), a cross platform approach (using an intermediate language that compiles down to native code such as React Native or Flutter), or a hybrid approach (made popular by Apache Cordova). There are pros and cons with each approach that any organisation needs to weigh up before embarking on a project in one of these approaches, however rest assured with each of them you will probably eventually have to deal with a WebView.
WebViews In The HL Mobile Apps
At HL our mobile apps are native, mostly. There are a few WebViews that we use to simplify the process of updates to the content and working with other teams.
We serve news articles in the app that we share with our web team so it makes sense that these are WebViews.
The display of communications to clients, what we call Secure Messages, is a WebView.
This is because we send an HTML formatted email to our clients which is styled by an external team in the same way that we style email messages. Rather than re-implement that logic for styling we use a WebView to render the HTML. Using WebViews in this way can simplify development even if the rest of your app is not built upon the WebView paradigm.
Understanding How WebViews Are Updated
WebViews on Android used to be bundled with OS. This had a big downside historically given that they were only updated when a new OS was released. WebView technology improved greatly in performance between Froyo (Android 2 / API 8) and Lollipop (Android 5 / API 21) however prior to Lollipop users needed to wait what felt like ages for improvements to their WebView experience. The one upside for developers, however, was that you only needed to test your app with WebViews against the newest version of the OS — which you would be doing anyway.
WebViews nowadays actually share their implementation with the currently installed version of Chrome on the device. This means that, since Lollipop, when Chrome updates you get all the brand new improvements that Chrome gets directly in your app’s WebView. Great news! Free speed improvements and new WebApis? Right? Right…..
The big downside in this is that if you use a WebView in your app you need to explicitly test your app whenever Chrome updates. Why would that be? Just like any library dependency that you use in your app you should test your app when that dependency changes. Usually this under your control as the developer but in the case of the WebView this done effectively from under your feet. Chrome updates on the following cadence. Chrome pushes a new stable version to the public every 6 weeks.
Take Away
You should test your app every six weeks, at least, for WebView regressions. The Mobile Squads at HL work to a two week release cycle where defined pieces of work are delivered quickly. Most two week sprints will be testing the app at a much higher frequency than the Chrome release cycle however it is incredibly easy to forget this subtly of WebViews and assume the dependency is a constant under your control therefore assuming that section does not need to be tested.
It is a good idea to keep on top of the upcoming changes in Chrome by monitoring the status web page at www.chromestatus.com and filtering by both deprecated / removed features and the upcoming dev / beta build. This way you should have enough time to test and make changes to your apps prior to end users updating their WebViews.
