Progressive Web Apps By Example: Part 1

With better iOS support in 2019, it is likely the time to do a deeper dive into Progressive Web Apps.

TL;DR: I got through writing four articles on PWAs to discover a major problem with PWAs on iOS 12.2 that make it them a no-go for me in 2019. See the last section in the article Progressive Web Apps By Example: Part 4.

So What is a Progressive Web Application?

Seems that I have heard the term Progressive Web Apps for some time now and at the same time I never fully understood what they were. As Google has been the principle proponent of them, let use look their definition:

Progressive Web Apps are user experiences that have the reach of the web, and are:

Reliable — Load instantly and never show the downasaur, even in uncertain network conditions.
Fast — Respond quickly to user interactions with silky smooth animations and no janky scrolling.
Engaging — Feel like a natural app on the device, with an immersive user experience.
This new level of quality allows Progressive Web Apps to earn a place on the user’s home screen.

— Google — Progressive Web Apps

note: When using Google Chrome and your internet connectivity dies, you’ll see a little tyrannosaurus. This is called the ‘downasaur’.

In a nutshell, it an abstract and aspirational definition of a web technology that is intended to displace native applications on mobile devices.

Service Workers and Reliability

Often confused with Progressive Web Apps, service workers are:

A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don’t need a web page or user interaction. Today, they already include features like push notifications and background sync. In the future, service workers might support other things like periodic sync or geofencing.

— Google — Service Workers

Towards the effort to provide a reliable web experience, service workers can be used to help deliver an offline-capable web application. In particular, they can be used to cache the application code and resources (e.g., images) for offline use.

The good news is that both Android, for a long time, and iOS as of last year (11.3), fully supports service workers.

If you are interested in diving into the details of writing service workers, the article Service Workers: an introduction is a good start. At the same time, if you are using Create React App, it is provided as part of the solution; just needs to be enabled.

Create React App Service Worker Implementation

Per the Create React App documentation, enabling service worker amounts to changing one line in src/index.js, doing a production build, and serving it up via HTTPS (or locally via HTTP).

To illustrate a service worker in action, we can simply execute the following command from the build folder:

npx http-server -c-1

Observations:

• npx is a command that will download and run a npm package on the fly
• http-server is a npm package that provides a simple HTTP server
• The -c-1 option sets the cache header to disable regular browser caching. This seems important as we don’t want the browser to cache the files used to determine if the application has changed

When one loads the application, there is no obvious indicator that anything special is happening until one looks at the console output (using Chrome and Chrome Developer Tools):

On the initial load, we can see that the browser is indeed loading the application code and resources from the server, e.g., look at the HTML (localhost) entry.

When we reload the browser, however, we see that the application code and resources are being served from the service worker. At the same time, the service-worker code itself is still loading from the server (so the solution can tell if there are changes that need to downloaded).

Chrome Developer Tools, provides a mechanism to inspect / manipulate service workers:

In order to provide for a more confident test, we can publish this application to GitHub pages and observe its behavior while served from there; see How to Deploy Your React Application to GitHub Pages for details.

In this case, I have published a simple example to:

https://larkintuckerllc.github.io/hello-cra-pwa/

We can see that this application behaves pretty much the same as it did when it was served locally.

Observations:

• The console messages appear to be only supplied when serving files from localhost
• GitHub Pages sets the cache headers for 600 seconds (or 10 minutes); at the same time it appears that the service-worker.js file is not cached by the browser; looks like we may not need to worry about setting the server’s caching headers
• The ultimate test is to load the page on a device, e.g., iOS, and then disable the network, e.g., airplane mode, and observe that the page can still be loaded

Finally, we can use Google Chrome Developer Tool > Audits > Progressive Web App feature to check how well the application adheres to the principles of being a Progressive Web Application:

Observations:

• The features related to Fast and reliable all pass; so the service worker feature is indeed working
• We will explore the Installable and PWA Optimized features in a later article

Next Steps

While we observed the basics of service workers in action, there are a number of additional things to consider regarding them; we will explore those in the next article Progressive Web Apps By Example: Part 2.