There’s been a lot of excitement in our industry recently about progressive web apps, these shiny new websites that can transform themselves into native-like mobile apps. It's probably more excitement than should be allowed given current browser support, but it's definitely an interesting approach to engaging with users on their mobile phones, and it has a lot of potential.
What makes a web app progressive?
A progressive web app (PWA) is a website that, after a certain amount of user interaction, can be used like a native mobile app. That includes supporting certain features that we normally only know from native apps.
For example, a PWA can be accessed from the phone’s home screen, just like any other native app. After having visited the app a few times, users will be presented with a prompt to add the app to their device. If the user agrees, the app installs itself alongside all the native apps.
Users can tap the icon on their home screen to open the app in full-screen mode. It uses the device's browser like any website would, but the users won’t see any of the browser’s UI. They are completely immersed in the app, just like in a native app. Any navigation will be done inside the app, without the help of browser back buttons or the like.
The fact that the app has its own icon also means that it exists in an OS’s task switcher as a standalone app, rather than being displayed as the web browser.
Once the progressive web app is installed, it can also send push notifications—even if the user does not have the app open.
And finally, it solves a problem that the internet has had ever since its inception: that you need to be online to use it! A progressive web app can work offline.
How is it all done?
The main two technologies that are working together to make a web application progressive are the web app manifest and service worker.
Web app manifest
The manifest is what communicates to the browser that it is dealing with a progressive web app. It’s a JSON object that lets us define a number of settings like the icon image, the default orientation of the application (portrait or landscape), the app’s homepage, and the scope of the progressive web app.
The scope is important because it informs the browser which individual pages should be grouped together as the app. Normally, a browser won’t be able to identify the relationship of individual web pages; but if a scope is defined, it understands where the boundaries of the app are. As soon as the user clicks outside those boundaries, they’re leaving the app and the user experience will change to browsing a standard website.
Several properties from the web app manifest object are combined to automatically generate a splash screen, which is displayed when the app is loaded after opening it from the home screen.
Service worker
Service worker is the second ingredient needed for a progressive web app. It is a script that is run by the browser, independent of any JavaScript code that deals with the DOM. It runs in the background once it is downloaded and installed in a browser.
One of the main features of service workers is that they can intercept network requests. Normally, when a request is made from the client code, it is sent directly to the network and will receive a response from there. However, when using a service worker script, the request will be dealt with by the script.
Service workers also have the ability to manage caches. Therefore, we could implement a network strategy whereby certain client requests will receive a response from the service worker’s cache, and certain requests will be sent out to the network.
Let’s imagine we have a simple blog website. We could cache static assets like stylesheets, a logo or banner image, and client JavaScript code, and return this information without having to wait for a network response. However, for any of the blog content, we could programme the service worker so that it always gets the freshest content from the server, rather than serving a cached response.
That way, we could greatly improve the user experience on a patchy mobile data connection, or serve content to a user who is offline. The service worker technology allows us to have granular control over caching, and can manage a number of different caches at different life cycles of the script. It can also refresh content in the background. Once it is installed, the user doesn’t need to have the browser open for the script to be active. So users can be presented with fresh content when they open the app—even if they are offline.
A service worker lifecycle usually has three stages:
- The install stage, during which it is common to cache assets like stylesheets, client-side JavaScript, and so on.
- When the install stage was successful, the activation step happens, during which any obsolete caches are deleted.
- Then, the service worker is idle until it needs to deal with a request from the client code.
The service worker is also what enables us to send push notifications with the help of the Firebase Cloud Messaging (FCM) platform. The fact that the service worker script runs independently of any user activity means push notifications can be sent at any time.
Browser support
It seems that with any new and exciting front-end technology, the lack of browser support usually puts a bit of a damper on the excitement. Currently, progressive web apps only work in Chrome and Opera for Android. Firefox for Android has the necessary features in beta, and in MS Edge they are under development. Unfortunately, Apple device users will have to wait a bit longer because WebKit, the layout engine used by Apple, has not yet started developing the features necessary to support PWAs. To keep up-to-date with the latest developments in browser support, this is a useful overview of the current state of preparedness for service workers in different browsers.
Pros and cons
There are a number of advantages that PWAs have over native mobile apps. Firstly, the exclusion of app stores will help the user engage with the content a lot quicker and in a much more convenient way. No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.
Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.
A PWA should also progressively enhance the user experience, meaning the content can be accessed on any kind of device. Also, the user experience gets progressively better the more modern the user’s device is.
However, with great power comes great responsibility. The service worker API is complex, and that old saying doesn’t identify caching as one of the hardest things in computer science for no reason. If not used carefully, this new technology can introduce a lot of complexity in an application, which can make the code hard to manage, and introduce bugs that will ultimately affect the user experience.
What’s next?
At the moment, the technology isn't quite ready to replace our good old app store apps. However the technology is heavily advocated by Google. Also, the vast number of apps currently using non-native technology with a mobile framework wrapper like Ionic or PhoneGap shows that there is an appetite for app technologies that don't involve Swift or Java. Those facts suggest that adoption of this technology will grow a lot.
A big hurdle will be to bring Apple on board to include service worker support in WebKit browsers. Allowing PWAs would mean that Apple will have to give up part of their control over what people install on their devices. But the size of the market share for Android devices still means that there is a huge number of users who can access progressive web apps. iPhone users will have to make do with the website versions of the apps for now.
