Progressive Web Apps and the Future of Mobile Apps
In the last 10–15 years I’ve seen most of my desktop applications go from native to web-based (SaaS). Spotify replaced Winamp, Facebook Messenger and Slack replaced ICQ and Skype. My entire Microsoft Office was replaced by Google’s suite of online tools a long time ago.
While many native desktop applications have been replaced by web apps or web apps encapsulated in a native shell (such as Electron), the situation is different in the mobile world, where the native app rules. Not only are mobile native apps more prevalent, but often they are the only option. While you can now finally access Instagram via web, for the longest time the native application was your only way to interact with it.
There is a simple reason for this: until very recently the mobile web browser simply could not support the functionalities needed to provide the same level of experience as a native app. For starters, you couldn’t even start the application without an internet connection. This is usually not a problem on desktops, but often a problem on mobile devices which at times have intermittent connections.
Even if you had a solid internet connection, you still couldn’t receive push notifications, or access some of the APIs. In almost every situation, a mobile web app was a sad, less functional version of the native app.
For a short while, web apps almost became the norm for smartphones, or at least it looked like they would be. When the very first iPhone was introduced, Steve Jobs proudly announced that there would not be an SDK for iPhone development.
Instead, Apple’s touted Safari, the native web browser, and urged developers to make web apps. Browser wars have been waged since the early days of the Internet, so it’s easy to see how in 2007 Apple wanted to make Safari the most powerful web browser. While it was arguably very impressive compared to other mobile browsers of the time, it still didn’t have the juice to make web apps a replacement for native applications.
Safari didn’t offer any specific device APIs for web apps to leverage. The “integration” that was made available consisted of special links (URL schemes like ‘mailto’) that web apps could use to perform simple tasks, such as draft an email, compose a text message or invoke the phone dialer. You could forget about making anything but the most simplest of games, since graphics processing was limited to what Safari could handle.
A year later, Apple rolled out the App Store and native applications became the standard. When Android was made public, it already included the Android Market, and all the other platforms that followed had their own version of an app store. It seemed like the fate of web apps was sealed in the mobile world. However, almost a decade later, there are signs of a potential change.
Apple obviously failed at pushing web apps as a substitute for native apps, and so did others, such as Mozilla and Palm. So why are we hearing all this buzz around Progressive Web Apps? The answer is actually very simple. It’s because PWAs are intended to replace websites, not native apps, and that’s something they seem to do very well!
Consider for a moment all the services you use, or sites you visit via your mobile browser instead of a dedicated app. Often these are news sites, but can also be online stores, social networks, etc. Personally, while I use Yelp, I don’t have their app installed. Same goes for Amazon or Dunkin’ Donuts (btw, DD’s Android app weighs in at whopping 66MB — why?)
While I don’t necessarily tend to install apps that I can access via a web page, there are some solid arguments to why a person might choose to do so. Maybe the website is a person’s favorite and they want a dedicated home screen shortcut for it. Perhaps the app offers access to a community that’s formed around the service. The site might also be rendering terribly in their browser so they install the app in hopes of a better experience. The reality, however, is that if a user has a bad mobile web experience, the chance of them downloading the app is very low.
The Argument for PWAs
So why should anyone then make a Progressive Web App? Let’s take a look at Twitter’s PWA — which in my opinion is one of the best examples of a well executed PWA. When Twitter introduced their PWA — Twitter Lite — they saw an increase in pages per session by 65%, the number of tweets sent was 75% higher, and there was a 20% decrease in bounce rates. Similarly, Forbes’ PWA saw a 43% increase in sessions compared to their mobile site, and engagement was up 100%.
When comparing mobile web with native apps, looking at statistics you’ll see that the mobile web is good at reach, while native apps are good at activity and time spent. So, if our goal with building native apps is to increase user engagement, then it would seem that Twitter and Forbes accomplished that with just their PWA.
On average, 25% of native apps are abandoned after the first-time use, and only 34% of native apps are opened 11 times or more. If you think about how much money you will spend on building one of these apps, and how much more money you will spend on getting people to download it, is it worth it?
Companies like Twitter have realized that a well-executed PWA eliminates the need to create a mobile app in certain situations. Unless your app is dependent on deep level resources, such as Apples ARKit, or Google’s Visual Core chip, or native graphics API, then building a PWA might be a quicker and cheaper way to get to market, but still reap the same benefits in terms of increased user engagement, better return rates, and customer conversions. In fact, you might see additional increases in all those segments, resulting from users who otherwise wouldn’t download the native app anyway.
Growing User Base
One other benefit that PWAs can provide is the ability to reach more uses in developing countries. The smaller footprint of a PWA compared to a native app, allows users with less powerful hardware and limited internet access to interact with your app. These users often struggle with limited storage space and slow internet speeds — two situations where PWAs really shine.
Twitter focused on building their PWA to use as little data as possible, and clocks in at only 600kB according to Twitter. They serve smaller resources and rely on local cache to store the app resources, meaning that after the initial launch, all following launches are instant.
Twitter isn’t the only company that’s leveraging PWAs to grow their user base in developing countries. Google’s Maps Go is a PWA, specifically designed for low-end devices. It doesn’t have all the bells and whistles of the regular Maps app, but it has enough to cover the basics, and is only 167kB large.
We are still a long way from PWAs being the norm, rather than the exception. Currently they are mostly available for Android devices, but both Apple and Microsoft are working on integrating Service Worker support in their browsers (Service Workers help cache new content and synchronize local changes to a remote server, which keeps PWAs as up-to-date as a typical website, while staying as responsive as a native app.) Google has made it possible to install PWAs on Chromebooks, and Microsoft is pushing to do the same in Windows 10.
However, a big part to making PWAs mainstream is going to depend on Apple’s level of commitment. In fact, Apple added support for the basic set of technologies behind the idea of PWAs in iOS 11.3. Hopefully soon we’ll see the same level of support on iOS devices as we see on Android today. However, apps and the app store are a major source of revenue for Apple, which takes a good cut for any sales that take place within a native app. There is a good chance that Apple will see PWAs as a threat and and only provide limited support. We can only hope that won’t be the case, because the future and the value that Progressive Web Apps offer is very exciting, especially when paired with new technologies like WebAssembly or Houdini.