While web apps (and web “native” apps using frameworks like Electron) have replaced many traditional programs on the desktop, the same is not true for mobile. Native applications are not only the norm, but the only option for most services and applications. Take for example, all the services I mentioned above. The only one with a mobile web app is Google Calendar, but it hasn’t been updated in years (the copyright date still says 2010). I remember using this exact app on my iPhone 3G.

  

Gradients are sooo 2010.

There’s a reason why native apps are the norm on mobile – until very recently, many of them simply wouldn’t well work on a mobile browser. They couldn’t use push notifications, couldn’t work offline, couldn’t access most of the APIs that native apps could, and almost always didn’t fit in with the operating system. In almost every scenario, mobile web apps were significantly worse than native versions.

The age of ‘pretend’ apps

There was a brief period when it looked like web apps would be the future of smartphones. The introduction of the iPhone at WWDC 2007 was nothing short of revolutionary (I know Apple loves to use that word, but it fits here). At the end of the presentation, then-current Apple CEO Steve Jobs proudly announced that there was no SDK or iPhone-specific development platform:

Apple wanted developers to make web apps for the iPhone, by leveraging the full power of Safari. Great idea, right? Not really. While the phone’s Safari browser was very impressive, especially compared to competing mobile browsers, web apps just weren’t ready to replace native applications. In addition, Safari didn’t offer any special device APIs that web apps could use.

Web apps just weren’t ready to replace native applications.

The “perfect” integration with iPhone services that Jobs boasted only consisted of special links that apps could use to call a phone number, create an email, start an SMS message, and perform other basic functionality. Games were limited to simple 2D graphics (because WebGL didn’t exist yet), and features like push notifications or background syncing were out of the question.One year later, the App Store was announced as part of iPhone OS 2.0, and native applications quickly took over. Android was publicly released the same year, and it included the Android Market from day one. Subsequent competing platforms (Windows PhoneBlackBerry 10 OS, etc.) all adopted the app model.

Some mobile operating systems tried a different approach: web apps would be first-class citizens, but they would be packaged and distributed like Android and iOS applications. One example of this was Firefox OS. You could only build applications using web technologies (HTML, JavaScript, and so on), and then upload them to the Firefox Marketplace for distribution. webOS (back when it was an OS for phones) was very similar, but Palm eventually allowed developers to write apps in C++.

Several tools have been built to wrap web apps into native containers.

The idea of packaging web apps as native ones wasn’t exclusive to Firefox OS and webOS. Over the years, several tools have been built to wrap web apps into native containers, such as Apache Cordova and Adobe AIR. In most cases, they use the rendering engine from the device’s browser (WebKit on iOS, Blink on Android) to display locally-running web pages. Unfortunately, many of the advantages of web apps (like developers being able to roll out updates immediately) are lost in this process.There is a key distinction between the iPhone’s early web apps and these packaged apps. Apple’s approach made it very obvious that you were running web pages, and the company tried to embrace the idea. Packaged web apps tried to fit in with their native counterparts, and usually had access to some of the platform’s native functions, but they still didn’t work very well. You could almost call them ‘pretend apps.’

After Apple opened the App Store, it seemed like web apps would never again return to mobile, at least not in a big way. Nearly a decade later, that is finally changing.

The rise of PWAs

‘Progressive Web Apps’ have become more and more widespread this past year. They are designed to be fast, work on any device, stay secure (with HTTPS), and perform well on poor network connections. Staying true to the open nature of the web, they work across browsers and operating systems. I can use the same web app on my Windows desktop, Android phone, and Chrome OS laptop.

Most of this functionality is made possible by a browser feature called ‘Service Workers.’ Simply put, web apps can use Service Workers to send push notifications, or keep a local cache. Other solutions for serving push notifications and storing data locally existed before, but Service Workers is a cross-browser standard. Firefox, Chrome, and the Samsung Internet Browser all support the feature (with Safari and Edge support coming soon).

One of the best examples of PWAs is Twitter Lite. The interface is almost identical to the native Android app, it’s fast, and it works across desktop and mobile. Once you add it to the home screen (which hides the browser UI), it’s nearly impossible to tell it apart from a native application. Some other examples include Financial TimesPokedex.org, the mobile Flipkart site, and the mobile AliExpress site.

It’s important to note that Progressive Web Apps aren’t a complete redesign/refresh of how web apps work. This isn’t a comeback, or a ‘Web 3.0.’ These use the most of the same web technologies that those awful iPhone web apps from 2007 used – CSS, JavaScript, HTML, etc. Gradual improvements to these technologies have made PWAs possible.

Replacing websites, not apps

Trying to replace mobile apps with web apps failed for Apple. Making web apps the only development option failed for Mozilla and Palm. Packaging web apps into native containers isn’t a popular option. So why are Progressive Web Apps taking off? Because they are designed to replace websites, not native apps.

PWAs are designed to replace websites, not native apps.

Think of all the services and sites you visit on your phone that you don’t use an app for. One example for me is Amazon. I don’t keep the app installed on my phone, not only because I don’t shop on my phone very often, but also because there isn’t much of an advantage over the website. The same is true for most of the news sites I read.There a few different reasons why users might install a native app for a certain website. They might visit it often, and want a dedicated home screen icon for it. The site might be slow or buggy, thus driving users to install the app in hopes of a better experience (some sites even encourage this with large install banners). However, many users will simply leave a website if the mobile experience is sub-par, much less download whatever app the site is offering.

Ever since Twitter replaced its mobile site with a PWA, the rate of pages per session went up 65%, the number of tweets sent was 75% higher, and there was a 20% decrease in bounce rates (source). Forbes’ PWA saw a 43% increase in sessions compared to the previous mobile site, and engagement was up 100%.

As Twitter, Forbes, and countless other sites have learned, a properly-written PWA eliminates the desire to download a separate app. Keeping users on your site instead of leaving to download an app means more engagement, more views, more purchases (assuming the site is a store), and a higher return rate.

For the first time ever, mobile web apps are a win for developers, site owners, and users. Developers can create great sites and web apps easier than ever before, site owners can keep users more engaged, and users don’t have to deal with slow and sub-par mobile sites.

Reaching the next billion

Progressive Web Apps have also become a major avenue for tech companies to reach “the next billion” – users in developing countries with less powerful hardware and limited internet access. They usually have to deal with limited bandwidth, slower devices, poor internet connections, and less storage space. Fortunately, PWAs can easily handle all of these situations.

Twitter designed its PWA to use very little data, by serving smaller resources (compressed images/video) and relying on a local cache. Twitter says its PWA is just 600KB in size, compared to the 20MB+ native app. Once you’ve opened the app once, subsequent launches are instant, because the entire app itself (as well as most if its data) is stored locally.

Google is also using PWAs to reach users in developing areas. Google Maps Go, a new version of Maps designed to work on low-end phones, is actually a Progressive Web App. You can open it in your browser by clicking this link. Maps Go doesn’t have all the functionality of the full Android/iOS apps, but it covers all the basics.

The future

We’re still in the early days of Progressive Web Apps, but they will undoubtedly become more important in the coming months and years. Apple and Microsoft are working on Service Worker support in their browsers, Google is continuing to push the standard, and Microsoft is integrating them into Windows 10.

The adoption of PWAs also depends on Apple’s support, at least in the United States. Will future versions of iOS allow PWAs to be installed alongside native apps, like Android does? Only time will tell.

Either way, web apps are finally becoming an alternative to native applications, and that’s something to be excited about.