Getting the whole picture on Progressive Web Apps

Published in

UX Collective

11 min readJul 6, 2018

Following a few years of steady and relatively silent growth, one of the multitude of promising web technologies has really started taking off.

Surfacing around 2015, the standards that form the notion of Progressive Web Apps (PWA) have come a long way: the principles behind them, maturing specifications but also the context have enabled them to become more and more embraced by the industry.

Buckle up for a brief history, a technical overview intertwined with a playful User Experience (UX) narrative, and the current context around this interesting piece of technology.

How did we get here?

In the past decade we’ve witnessed the web gradually expanding from the server side towards the client side — our PCs, laptops and tablets; our phones and wearables.
Alongside this expansion regarding where the web gets processed, there’s also been a significant evolution around how it gets processed. Speed increased dramatically, and with powerful client side hardware supporting the web better and better, the way we experience it has truly blossomed.

These advances in hardware and software technology were met with an equal response from our creation processes. Nowadays we are mindfully designing, prototyping and testing the experience that our capable web applications can provide, implementing ever-more complex features with ever-evolving modern tools, all with growing consideration for the ever-wider array of devices.

Notions like cross-browser support, responsive design, accessibility, progressive enhancement and graceful degradation have become almost second nature in the world of User Interface (UI) development, enabling web apps to run virtually everywhere and accommodate the far reach of the web.

Besides these advances in performance, speed and reach, a set of technologies called Hybrid Web Apps also pushed forward the degree of interactivity that you could get using a web application.

The list is longer, so for brevity I will mention the first that come to [my] mind: BlackBerry’s WebWorks development platform, the Apache Cordova/PhoneGap platform, the web apps integration from Firefox OS, and Electron — which is probably one of the most popular currently.

Hybrids are web applications that are recompiled or wrapped in a native code package, which enables them closer ties and access to a mobile OS’s capabilities, and implicitly significantly improved UX — albeit usually at the cost of renouncing some of the main strengths of the web.

Like with many products and technologies in this industry, it can take multiple attempts and remixes — often by different companies — until a concept receives long term adoption by developers and/or the public. And during these past few years, the building blocks mentioned so far have been assembling, to unlock the next level of interactive web apps.

Enter Progressive Web Apps

background: requirements, extracted from Google Dev docs; foreground: PWA community logo

Don’t let my artistic attempt at an anxiety inducing wall of requirements scare you [completely]. What these actually mean is that we finally have a centralized, mature and comprehensive specification for what an advanced, modern web experience should be like.

Considering this, let’s clarify what a PWA really is.

A progressive web app is nothing more than a web application built using any libraries and frameworks, that respects an official set of requirements and standards (specs). These specs include well established best practices that ensure a solid foundation for an optimum web experience, as well as newer more modern [for the web] features — closely resembling features from native apps — that can significantly upgrade that experience.

To illustrate these official requirements in a more playful way, I’ve coated a set of user journeys in the form of a semi-fictive UX narrative:

Chapter I: At its core, a normal web app
On a sunny Saturday, John goes out to grab a coffee at a local shop, opens his laptop’s browser and loads up one of his favourite industry-specific news sites. Scrolling through the articles, he catches a glimpse of one preview announcing the re-re-re-release of the web site’s mobile version, and encouraging readers to add it as a home screen shortcut on their phones.

Resumes scrolling, takes a sip of coffee plus a mental note to try it out sometime, and starts churning through some articles.

Chapter II: Quick to load, performant, and responsive
Although he usually only uses his laptop when catching up on these reads, after a few weeks he opens up the same website but using his phone. To his surprise the page loads surprisingly fast, considering how rich the contents were on his larger laptop screen.

The web site’s content layout and typography really embrace the smaller screen factor, and are easy to read and navigate. It has dedicated smaller screen menus and a funny button resembling a light switch, that toggles a visual mode with darker backgrounds for easier reading in night time.

Intrigued, he decides to also try the ‘save to home screen’ to see what else the re-release of the web site brought new. The web page displays a quick confirmation then performs the action in the background in a few seconds, without interrupting his flow. Barely acknowledging the confirmation, he gets distracted and slips into reading several articles for a while, then closes the phone’s browser app and resumes other activities.

Chapter III: Add to Home Screen or graduation day for a web app
Several days later John taps the web site’s shortcut on his phone. To his surprise this does not simply open up as a new tab, buried between all his currently opened browser tabs. Instead, it gets launched in a separate new app window of its own, after a blink of a splash screen, and no longer showing the typicial browser url bar and controls.

John squints slightly, as he knows that the news site did not have any native app — nor had he downloaded any app for it from the app store.

Starting to vaguely remember reading about some of this in the initial article, to double check, he minimises the app and pulls up the phone’s app switcher; which indeed displayed a new app window for the news site, separate from the browser’s window — and coincidentally, right next to it, at which point that browser app ponders..

..they grow up so fast

Chapter IV: See you later offline T-Rex gator, hello reliable start ups
One late afternoon, while standing in line at a super market — in a building with very low network connectivity — John decides to reopen that news site app.

The app’s home screen loads up, despite the low signal, and even does so as fast as the previous time, when network conditions were good. There’s a small tooltip letting him know that because of the missing network connectivity, the app’s content may be outdated; and a small button that says ‘Retry getting fresh data’. While advancing in the queue, he is able to go through two unread articles that the app had loaded the previous time he was online.

Chapter V: Offline content control
Business trip coming up. Among all other preparations, John remembers to set up some reading material for the flight, so he opens this app as well, scrolls through the latest articles and hits ‘read later’ on a bunch. He also decides to get rid of a periodic prompt from his phone by updating its operating system; and right before that, by mistake he closes all currently running apps.

During his flight he opens the app and can — nearly instantly — load up its first screen (without the app previously running in the background) and then access every saved article without any network connectivity — just as fast.
The app also remembered the darker visual theme he chose last time.

Diving deeper into some of the topics in these articles, he decides to keep track of their progress, so he taps on a button to subscribe for updates. The app notifies him that it is not able to do that without any internet connection, and that it will retry subscribing the next time the app goes online.

Chapter VI: Web apps get the ok nod from native phone notifications
After a few days, again without having the app running in the background, he starts receiving notifications on his phone announcing newly published articles on those topics he subscribed to.

Cool story bro, but..

Yes; none of this really sounds like mind-blowing rocket science, as we instantly compare it to what we know mobile native apps can already do. And yes, that is Comic Sans.

The catch is that

besides the UX upgrade that they provide, the features described during these scenarios can be gradually — ahem, progressively — added on top of the codebase of an already existing web app,
only for browsers that support them — with browsers that do not, simply rendering a normal web app minus the PWA features,
using standard web technologies,
without having to recompile the codebase for that app, or wrap it in native code (Java, Objective C, C# etc),
and having https as a mandatory PWA requirement to ensure all of those powerful features are also safe.

Saved the best for last.

That same app’s content remains deeply connected to the open web: its pages are indexed and discoverable through search engines, and update-able via the typical frictionless web distribution; users can still pin point to exact locations inside the app using URLs; all its information remains fully accessible for people using the app with assistive technologies and for the multitude of devices covering the largest user base of all platforms.

Ok, tell me more!

How do PWAs work

The fundamental building blocks for developing a PWA are a manifest file and a service worker.

The first is a json file that helps upgrade the traditional Add to Home Screen browser feature into the step that lifts a PWA from a simple browser tab into a separate app on your phone. This manifest file groups meta data about the web app, so a device can recognise and understand how to display it as a separate app in its own window, with its own title, icon, splash screen and so on.

The second and more interesting one is a javascript file that can be run by the browser in the background, with its own lifecycle — separate from the web app’s. Where this shines is in its ability to listen to, intercept and respond to network requests, even when the app is not running.

The sketch below is one example (out of many) of a caching strategy unlocked using a service worker.

Using a service worker developers are free to choose the content and implicitly how much of the app’s size they will cache and when; also, they can provide some of this control to their users as well.

From an architecture point of view, PWAs use a separated application shell + content model instead of serving them tightly coupled, where the shell is cached locally upon the very first time the user accesses the app’s url. You can think of the shell like the visual frame of your app, containing things like the top header, navigation, menus, footer, and generally the more generic things that change the least often.

After a single initial succesful load, this pattern enables the web app to always boot up, and it enables it to always do so quickly and consistently, rendering at the very least an error screen that is consistent with the rest of an app’s design language, and otherwise the full app shell plus any previously cached content that was stored as a decision of the developer, or the user.

All this regardless of network conditions.

This is paramount, as for the first time, if something is prohibiting the device to access the network, the user is never presented with the breaking experience of a browser error page.

Although this is getting more and more exciting we are just scratching the surface here, so if you’d like to dig deeper and get started on building a progressive web app, the best place to start would be [you’ve guessed it] the developer docs.

And if you get there make sure you also check out the comprehensive dual checklist of requirements. This is fully packed with helpful hints and references to tools and documentation, describing the minimum and the exemplary specification sets that a web app should meet in order to qualify as a PWA.

Platform adoption timeline

Although they’ve been around for a while already, PWAs have made it as first class app citizens on Android last year, when they also announced desktop support coming soon. Sure enough, this year they landed on Windows 10 (and on the Microsoft Store), and on Chrome OS. Apple’s iOS has also started supporting them with the latest releases of Safari from earlier this spring.

So the latest advances in platform adoption look very promising.

That said, there are still some issues here and there that may make both a developer’s and a user’s journey [pun a little intended] using a PWA a slightly bumpy ride at times.

Things like feature inconsistency across platforms, caused either by partial support or by full support implemented differently, mean that app creators need to mindfully consider the extent to which each platform supports PWA, in order to provide users with an experience that is as consistent as possible.

Impact

Out in the wild we’ve already started seeing popular native apps getting their PWA version (Instagram, Google Maps, Uber), and popular web apps being upgraded to PWAs (Twitter, Forbes, Financial Times).

And while currently — and likely for a while still — native apps still hold an edge in overall UX, they do so at a significantly lesser margin then they did a few years ago.

For people using high-end smartphones in areas with optimum network coverage PWAs may still be ever so slightly not quite there yet when held against their native version. However, this technology has already started making a significant difference for people living in areas with low or inconsistent network coverage, or using devices with limited storage capabilities (PWAs are downloaded at a fraction of their native counterpart’s size). An indicative case study straight on this topic is Instagram’s PWA upgrade, presented during last year’s Chrome Dev Summit.

You can find several more case studies also on the Google dev blogs, documenting the PWA journey of companies like Twitter, Forbes and OLX, with detailed insight around their motivations and processes using this technology.
And another one for the Starbucks PWA [by a company called Formidable] also listing increased app performance, dramatically reduced file size and increased user engagement among other metrics.

Outro

PWAs take interactive web apps several steps further, adding new dimensions — some as natural extensions on the nature of web, others borrowed from native mobile technologies.

They allow creators to both enhance the quality of the user’s experience — by finally managing to resolve some of the main shortcomings of traditional web apps, and to better shape that experience from the very first visit, to the next few and to potentially recurring visits over time.

While it is not the first time that this kind of efforts are being made to nudge web apps in this direction, the experience that these new standards provide, coupled with the fact that PWAs retain their core web features while getting those well thought-out upgrades on different fronts — and also considering their platform adoption — look very very promising and exciting.

Hope you enjoyed the read, will leave you with some stuff to try out.