In this blog post, I’ll go through the concept of Progressive Web App. I will share my thoughts about the best parts, development challenges and how PWAs are going to challenge native apps. I will also briefly discuss the current browser and device support.

Introduction to PWAs

Most people in tech have certainly heard of Progressive Web Apps and how they are supposed to be an alternative to native applications. PWA’s are basically standard websites that behave like native apps. They can be installed on the start screen of the mobile phone and they allow apps to send notifications. They also work offline, if needed.

For the benefit of the native applications, they are undoubtedly faster because no web browser is needed to run them. In addition, they are better placed to access the phone’s interfaces, such as messages and contacts. But perhaps most importantly, they have the ability to access phone’s installed applications, which is necessary for cross-app interactions.

Luckily, browsers already have quite good coverage of “native” APIs such as the camera and the gallery, the GPS signal and, for example, the orientation and acceleration sensors of the device. Browser support is constantly improved and new functionalities (including e.g. Payment Request API) are developed by the browser vendors.

There is a relatively large amount of PWA related technical specification and examples on the web. However, monitoring the topic is complicated because the Service Worker specification is still in progress, even though its first version has already been released. In addition, device and browser support is constantly evolving, and to make things worse, Google (the concept conductor since 2015) has repeatedly changed the definition of PWA. It is quite difficult to build a clear overall vision of the subject.

To me, these are the key features of a PWA app:

• App manifest (determines the application’s colors, logo, and its startup properties)
• HTTPS support (required)
• Offline support for all sections of the site
  • General offline page at minimum.
  • For SPA applications, it is a good idea to ensure that all pages have their own unique address and that the application can initialize its state based on the URL.
• Improve your site’s page load speed with the help of cache strategies
  • the first page load should be fast.
  • On subsequent page loads, at least the static parts of the site should load almost immediately.
    • Cache-first cache strategy would be a good candidate

Note: No PWA feature should prevent the application’s core functionality on any browser/device.

Motivation

PWA engages users and increases website speed and sales. Successful example cases can be checked from PWA Stats. Most sites have achieved multiple benefits at the same time:

• Boosted conversions
• Reduced download times
• Increased time spent on site
• Added advertising revenue

App installation

The installation prompt of PWA is usually shown immediately on first visit or after the user has used the application for a while. Personally, I would prompt for the installation only after I feel the user is already somewhat willing to continue using the application. Otherwise, it might annoy the user in the worst case.

Based on current research data, installation of PWA seems to be the most effective way to engage users as users seem to avoid using the app stores on average.

Page speed and engagement

You can fine-tune your websites page speed with various caching strategies offered by Service Workers. Service worker acts as a proxy or man-in-the-middle between the browser and the server. For example, the PWA can provide a previous version of the app from the cache, followed by a replacement version fetched in the background.

With Service Workers and a variety of different caching strategies, the developers for the first time have very good control over delivering and caching resources.

With PWAs user, engagement can be boosted to a whole another level. For example, a new product arrival in a webshop catalog could trigger an automatic notification to users’ phone.

Progressive enhancement

Converting a website into a PWA should be started with the most important features for your app audiences. For example, users who browse the web in unstable network conditions can benefit most of the offline features and aggressive caching strategies. For a traditional blog site, the best benefit may come from sending notifications of published articles.

Not all browsers support the finer aspects of PWA applications, so it’s a good idea to start with the best-supported features. Personally, I would start by making an App Manifest file, turning the site into HTTPS mode and registering the Service Worker with the only task of providing an offline fallback page for all sections of the site.

App notifications

App notifications are one of the most exciting PWA features. When used in a controlled manner, the benefits are obvious in most applications. Notifications work even if the browser isn’t active because Service Workers are designed to run in the background.

PWA application needs to ask the user for permission to display and send notifications for both desktop and mobile devices. Different browsers implement the prompt process in different ways, but there are some general guidelines to follow such as:

• Send notifications only about relevant issues – do not spam
• Make the subscription options visible for the user
• Offer the user a clear instruction to disable and re-enable notifications
• Do not ask for permission for the notifications until the user has used the app for a while

If you ask the user permission for notifications too early, they might deny the request and the decision can be final depending on the browser.

Browsers and device support

At the time of writing, Service Workers browser support is globally about 85 percent. The best support is offered by Google’s Chrome browser and Android phones in general. For example, Chrome is still the only browser (from version 49 onwards) that supports the Background Sync feature. In other browsers, the feature is still under specification or development.

Google has a strong representation in the Service Worker W3C specification, which advocates that Chrome will continue to adopt the latest features among the first.

Latest versions of iOS are supported by Service Workers as Apple seems to increase its momentum in PWA compatibility. Maximiliano Firtman has a good article about the latest supported features on iOS including its differences to Android.

App stores

So far, PWA applications are discoverable only in the Microsoft Store. You can manually add your PWA application to the Microsoft Store, but if the app meets certain Microsoft-defined criteria, the Bing search engine can automatically add it. Apple Store and Google Play do not support PWAs currently.

To be discoverable, the PWA application must contain an App Manifest file with general information about the application at a minimum.

Wrap-up

For the time being, native apps win in the overall comparison of features, but the native apps also have their own problems related to increased development and delivery costs. As soon as the support for the various Browser APIs is generally better, I can see PWA as a strong challenger for native applications in a fast-paced and hectic business field.

In the meantime, we can already adopt most PWA features on a pretty wide scale without too much overhead to the development work.

Pros:

• One codebase for all devices and browsers
• One unified standard to do things (e.g. Notifications API)
• Existing websites can easily be converted to PWA
• No need to learn platform-specific programming languages
• Easily installable to home screen
• Progressive development, features can be added as needed

Cons:

• The Service Worker and browser API specs are still work in progress
• Browser support for different features is still just mediocre
• No access to phone applications
• Limited support for phone interfaces
• Slower compared to native application
• Not available in application stores