Back to blog home

How to get started with progressive web apps

Progressive web apps (or PWAs) provide your users with an app-like experience, without the hassle of an app. Here I explore the brand benefits of PWAs and how to start using them.

Progressive web apps in a nutshell

The main idea of progressive web apps is to engage your users faster and for longer – especially when there is no connection available. With PWAs you can reach more users beyond the confines of the app store and provide smoother, more consistent experiences across web and native apps.

Ionic (for whom Inviqa is a Trusted Partner) has a great definition:

Progressive web apps (PWAs) use modern web capabilities to deliver an app-like user experience by bringing features we expect from native apps into the mobile browser experience. They use standards-based technologies and run in a secure container accessible to anyone on the web.


It’s worth noting that not all existing applications need to be turned into a progressive web app. The types of applications that will benefit most from the transformation are those featuring fresh content that’s regularly updated, such as weather and news applications. PWA rocks has some great examples of how this new technology is being successfully applied.

The DNA of a progressive web app

A progressive web app has the following characteristics, according to Google:

  • Progressive: It works for every user, regardless of browser choice, because it's built with progressive enhancement as a core tenet.
  • Responsive: It fits any form factor: desktop, mobile, tablet, or whatever is next.
  • Connectivity independent: It’s enhanced with service workers to work offline, or on low-quality networks.
  • App-like: It feels like an app, because the app shell model separates the application functionality from application content.
  • Fresh: It’s always up-to-date, thanks to the service worker update process.
  • Safe: It’s served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
  • Discoverable: It’s identifiable as an ‘application’ thanks to W3C manifest and service worker registration scope, allowing search engines to find it.
  • Re-engageable: It makes re-engagement easy through features like push notifications.
  • Installable: It allows users to add apps they find most useful to their home screen without the hassle of an app store.
  • Linkable: It’s easily to share the application via URL, and doesn’t involve complex installation.


A progressive web app consists of a UI (or so-called ‘app shell’) and the content itself. The app shell is basically the minimal UI required for the PWA to run. It should load fast and cache instantaneously.

That means that the shell files will load once over the network before being saved to the local device. So everytime the user re-opens the app, the UI will load straight from the device. 

How to implement a progressive web app

So how do you get started? Thankfully, implementing a progressive web app is not that different from creating a web page. It requires mobile-optimised HTML and CSS, and you’ll need to supply a manifest file (allowing your users to add the app to their home screen and see a splash screen), cross-device icons, and offline support (aka ‘service workers’). 

Wondering what a manifest file is? This is just a JSON file that lists all the properties your web creation will require as an app on the home screen of a user’s phone.

Here’s an example set of data that you can put in your manifest:

	“name”: “InviqaProgressiveWebApp”,
	“short_name”: “InviqaPWA”,
	“start_url”: “.”,
	“display” : “standalone”,
	“theme_color”: “cornflowerBlue”,
	“background_color”: “white”,
	“icons”: [{
		“src”: “images/image48.png”,
		“sizes”: “48x48”,
		“type”: “image/png”
	}, {
		“src”: “images/image72.png”,
		“sizes”: “72x72”,
		“type”: “image/png”

Things like start_url will make sure that your app launches from the specified URL (if given a relative URL, the base of the URL will be the manifest). Standalone display will ‘get rid’ of the  browser elements like the URL bar, and the background-color will help the transition when the app is loading (as the main UI style will be taken from your CSS).

In the manifest file you’ll also find the icon element (for adding an icon to the user’s home screen), which, together with the app name and background_color, creates your app’s splash screen. When you’re finished with your manifest, place a link tag to it in the head of your document.

Check-out this progressive web app skeleton here if you’re looking for an example of a bare-bones PWA.

Now let’s have an in-depth look at one of the major components of a progressive web app: service workers. 

Understanding service workers

The caching we can do with a PWA is possible thanks to service workers – scripts that your browser runs in the background, separate from the web page, to ensure your features will not require a web page or user interaction.

Today, service workers already supply push notifications and background syncing. Hopefully, in the future, service workers will cover features like periodic sync or geofencing.

Thankfully for developers, service workers are there simply to enhance the behaviour of an app, rather than being a must-feature, so backwards compatibility is not a big issue. However, if you do need to make sure your content is available offline, there are ways of using old technologies to ensure you cover as much ground as possible (AppCache is one of these).

Remember that service workers are much better at dealing with offline caching than App Cache, but AppCache will allow you to cover most of the browser compatibility if the service workers are not supported.  

Service worker support

App Cache support

How to implement a service worker

If you want to make your progressive web app work offline, you first need to check if the browser supports it. Then, register the service worker in the ‘if’ statement as follows:

if (‘serviceWorker’ in navigator) {

After registering the service worker, an install event will trigger when the user visits the page for the first time. This will allow you to cache all the assets needed for the app. 

First of all, open the cache using and provide a cache name, which allows you to version files and to separate data from the shell. This makes it easy to update either the data or shell without affecting the other.

Then we can call upon the cache.addAll() which takes a list of URLs, then fetches them from the server and adds the response to the cache. Since this function is atomic, if any of the files fail, the entire step fails. 

var cacheName = ‘yourCacheName’;
var filesToCache = [

self.addEventListener(‘install’, function(e) {
	e.waitUntil( {
			Return cache.addAll(filesToCache);

After installing the service worker, it’s worth doing some work with it! We can add an eventListener for activate event, as it will be fired when the service worker starts up. It’s worth making sure that the worker updates its cache whenever any of the files in the filesToCache change. 

To make this happen, the cacheName variable needs to be incremented at the top of the service worker script, as below:

self.addEventListener(‘activate’, function(e) {
		caches.keys().then(function(keyList) {
			Return Promise.all( {
				if (key !== cacheName) {
					Return caches.delete(key);

Now you’re able to intercept any requests made by your progressive web app, and to handle them inside your service worker. This means your work will be offline-capable, and that you can ensure your users will be able to engage with your work without being online. 

If you are looking for some great pre-written ‘recipes’ for common service workers cases, head to Mozilla’s website which has vast amounts of reusable code. Happy PWA-ing!

My favourite PWA: ProgressiveWebFlap!

Related reading


Need help with your mobile strategy? Contact our consultants today!