I heard the term ‘progressive web app’ the first time almost a year ago and I thought this could be making big change in how mobile apps are made. I had made some native Android apps as a hobby and I had been involved in implementing a html5/native hybrid application and was familiar with the hacks and awkward deployment processes it required.
Few weeks ago I started a project to study the progressive web application development and how PWAs might change the way mobile apps are made. The work is still in progress, but the files can be viewed here.
The meaning of ‘Progressive web app’
A web app is called ‘progressive’ when it contains a set of characteristics making it mainly user friendly and platform independent:
Progressive — Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
Responsive — Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
Connectivity independent — Service workers allow work offline, or on low quality networks.
App-like — Feel like an app to the user with app-style interactions and navigation.
Fresh — Always up-to-date thanks to the service worker update process.
Safe — Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
Discoverable — Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
Re-engageable — Make re-engagement easy through features like push notifications.
Installable — Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
Linkable — Easily shared via a URL and do not require complex installation.
Source: wikipedia.org/wiki/Progressive_web_app
Compared to traditional web apps...
Many of those features could not previously be implemented to a traditional web app (= an application that is accessible by opening browser and choosing to navigate to the address of the app). A traditional web app is:
Not connectivity independent. You can’t access the app when offline and it might be slow when on a bad connection.
Not app-like. Your app runs in another app (browser) and you’re stuck with the controls the browser creates around your app.
Not re-engageable. The app only works when the browser is open with your app in it.
Not installable. You might be have been able to create a desktop / home screen shortcut to the application but that’s still basically just a link to a web page.
...to the rescue: Native mobile apps
And because of these shortcomings, to satisfy all the user needs, you might have had to implement the application or some of its features also as a native mobile application. But as a native application, the app still misses some of the progressive characteristics, it is:
Not responsive. It’s only for mobile.
Not fresh. Updates are made through app stores and some users might remain with old versions.
Not safe. Ok, this is pretty harsh. Https alone doesn’t make it safe but it’s not enforced either.
Not linkable. You can only link to the app store page of your app.
Creating your features for different mobile platforms multiplies the amount of work and increases the complexity of your system. If implemented as pure native apps, you’d have to implement the same features for for each platform with different programming languages. That’s why in many cases the most efficient way to do this was to create a web application and wrap it in a native application. Sounds and is f**ked up but there are even frameworks for it, like Cordova.
The PWA way
With the new Service Worker API and Web App Manifest standards you are able to get the features to your web application that previously required native apps. Now your app can have all the good stuff from both native and web apps in one application and you have total control of the deployment (no app stores), encrypted notifications (not readable by third party services) and your users can choose to install the application on their devices allowing connectivity independence and native app-like experience.
Sounds to good to be true?
Almost. The features are only available in the latest versions of the modern browsers but you can start implementing your progressive app today. Users with modern browsers get the good stuff immediately and others can use the same app the traditional way: through the browser window until support for these new features spread.
The share of Chrome users is already over 50% so I believe this is viable option, if you are considering a new application now. For example Twitter has already a PWA in production, try surfing to https://mobile.twitter.com/ with an up to date version of Chrome on your mobile device and you’ll get a taste of it.
Progressive Web Apps — Part II: Add offline support for a web application
Sauli Ketola is a Senior Software Architect at Nitor. Sauli is specialized in agile software development methodologies and test automation. He has wide-ranging experience in systems design and application development in the financial services sector. Occasionally, you might catch this enthusiastic hockey spectator on a run, dreaming of completing a full marathon.