Mobile App vs Progressive Web: Final Battle in War of the Apps

I love how technology rolls out like one Blitzkrieg of innovation after the other. Yet, each next apparent knock-out is just another bell-ring for another round, and victory is always just a Pyrrhus victory. I give you the next whipping boy candidate: mobile apps! Are we on the brink of the Return of the Browser? IE, IE, why have you forsaken me?

To some, it may seem like a complete impossibility for mobile apps to disappear out of our lives because mobile apps are as much bread and butter to our daily lives as the smartphone and the mobile device itself. But I love technology for this enormous speed of its rise and fall. Edward Gibbon once gained eternal fame by writing the “Decline and Fall of the Roman Empire,” but imagine how many Edward Gibbonses we would have in our capricious times of tech innovation and disruption. This technology samsara is a little like the permanent revolution of Trotsky, or as Mao would phrase it so treacherously: letting a hundred flowers bloom and a hundred schools of thought contend.

There is no question the browser has been crucial to the existence of the Internet. Equally, mobile apps have been intertwined with the use of smartphones. There is, however, a hidden but perhaps fundamental clash of the titans between the browser and mobile apps, as irreconcilable of a conflict as that between relativity and quantum mechanics.

Look at the following numbers from ComScore Inc.’s Mobile Metrix 2017 to illustrate this internal conflict on mobile:

You can see that users engage dramatically less in the browser than in a mobile app. You also see at the same time that more than three times as many people use the browser than a mobile app to access their top 1,000 destinations. Mobile apps seem to be used less likely by people, but the browser on the other hand seems to be dramatically less engaging.

So, at least the question should be asked: how can we add the same user experience and engagement of a mobile app to the browser? Second, we should ask: how can we increase the number of people who use mobile apps? And third, we should ask: are the two styles of user experience maybe just essentially different solutions for different problems?

I’ll answer the last question first. Even if mobile apps and browsers are different solutions to different problems, perhaps they don’t need to be. Many great solutions share this childishly simple insight: we think something is the case only because it has always been the case, but it is possibly not necessarily the case. Habit and pre-existing knowledge can be real Mayan veils.

So, what is the possible panacea for this universal ache? Progressive web apps.

When I first stumbled upon PWA recently, I was originally developing an Ionic2 application with Angular2, TypeScript and Apache Cordova. I was looking for a satisfying caching solution to comply with an OfflineFirst strategy. That inevitably led me to the following Web APIs like the Service Worker API, Cache API, Fetch API, and IndexedDB, as well as PouchDB. I had hit on Progressive Web Apps or PWA.

PWA follows largely design principles from Responsive Web Design (RWD) and Mobile First, which to many developers now hopefully will feel is common sense. In my case, these design principles are implemented already to some degree simply by using Ionic2 and implicitly Angular2. In addition, PWA embraces OfflineFirst principles, which is a more vague set of high level design principles for mobile, what user-centric is to Design Thinking.

PWA uses a web app manifest to configure the PWA. If you use Ionic2 like I do, this is not new, as it includes already a manifest.json file in the ‘~/src’ directory.

{
 “name”: “Ionic”,
 “short_name”: “Ionic”,
 “start_url”: “index.html”,
 “display”: “standalone”,
 “icons”: [{
 “src”: “assets/imgs/logo.png”,
 “sizes”: “512x512”,
 “type”: “image/png”
 }],
 “background_color”: “#4e8ef7”,
 “theme_color”: “#4e8ef7”
}

The most interesting line in the manifest here is the ‘display’ property in ‘“display” : “standalone”’. The ‘standalone’ value hides the browser UI and gives your browser application or web site that feeling and impression that you are really using a mobile app.

Another nice feature of Ionic2, is that it supports the Web APIs that you need to create an OfflineFirst based application. In the ‘index.html’ file, simply uncomment the following lines to implement the Service Worker API.

<!—- un-comment this code to enable service worker
 <script>
 if (‘serviceWorker’ in navigator) {
 navigator.serviceWorker.register(‘service-worker.js’)
 .then(() => console.log(‘service worker installed’))
 .catch(err => console.error(‘Error’, err));
 }
 </script> 
-->

The ‘service-worker.js’ script uses the ‘sw-toolbox’ library, which is a set of helpers to create Service Workers specifically for the Cache API and Fetch API. Workbox.js is a rethink of sw-toolbox, but is not yet by default included in Ionic2.

Let’s take a quick look at the mobile Twitter app example. The Twitter mobile app is a 24.7MB of download on my Android smartphone, and after installation it used 106MB of internal storage on my phone.

Twitter recently launched a Progressive Web App (PWA) called Twitter Lite. Compared to the mobile app version, Twitter Lite is less than 1 MB of download. In PWAs, updates to the app happen automatically, of course.

Below are two screenshots of my Twitter profile page, one is of the mobile app that takes 106MB of internal storage on my phone, the other is of the PWA that takes less than 1MB and is essentially a browser bookmark.

Below are two more screenshots, this time of my Twitter feed. One shows the mobile app, the other is of the PWA. I deliberately do not explain which is the PWA and which is the mobile app, but guess.

The differences are hard to find, and it is hard to tell which is which. This makes a great case for a bold fourth question: why mobile apps at all? Why bother with Android and Objective C? Why Swift? Why waste so much effort to create a Swift runtime so that you can share code with the Swift mobile code? Why J2ObjC? Why Xamarin? Why all those competing efforts to outcompete the competitor? Why, when you have PWAs? Pride aside, why? But I am a fool, an idiot, and I know one thing, that I know nothing, and I am probably wrong. ;-)