How Does a PWA Work? (and Other Questions You Were Afraid to Ask)

Progressive Web Apps are just websites that took all the right vitamins.

Google web.dev

Progressive Web Apps (PWAs) are websites that use modern web technologies to deliver experiences closer to those delivered by native iOS and Android apps.  They combine the last decade’s browser and web construction advances (responsive web design, JavaScript engines, service workers and web storage) to create a whole greater than the sum of their parts””a capable substitute to native applications.

In this article, we’ll dive into some of the common technical questions we get around PWAs, including how they work, when they’re a good option, and how to build a solid PWA strategy. 

How Does a PWA Work?

At its core a PWA is a website that can be installed on your device (phone, tablet, PC or Mac), app icon/shortcut and all. A PWA will pull updates in the background each time a user runs it.  As you update your web application, not only will visitors to the app site gain access to new features, but so will PWA users””all without explicitly performing any kind of update.

When a user interacts with the PWA, the PWA can check the capabilities of their device and load more data in the background. This opens up scenarios of preparation for coming interactions, resulting in the appearance of a more capable application. PWAs can also offer app-like increased functionality traditionally unavailable to websites, such as offline usage, notifications when new data is available, and various other conveniences. This progressive unfurling of functionality based on the user’s device works on the same code base and in parallel with users of your website in a browser.

Why a Progressive Web Application?

User experience research shows that while users turn to native apps because they provide a cleaner and smoother experience (as compared to websites), mobile websites are their first port of call for exploring a topic and for seeking specific information when on the go.  While certain modern app features like ability to work offline and subscribe to notifications have not traditionally been present for websites, their findability via search engines contributes to their preferences for information retrieval.

One factor driving the affinity for native apps by mobile users is that native apps are de facto created mobile-first from the start.  While “mobile-first” has been a design mentality for websites in many circles for a few years, it is not universally practiced.  Thus we arrived at the “there’s an app for that” reality: native apps delivered what mobile websites couldn’t – the ability to work offline and an experience optimized to the mobile form factor.

On the pro-web end of things, we encounter the inherent friction of native app distribution to end users.  While distributing software to end users via a centralized app store is convenient for developers, it imposes work on users.  Store providers impose a review period on new releases, users can be running any of your past versions (tech support goes way up there) and in the worst case the app store may even reject an app entirely.  Finally we encounter friction on the part of creators for both initial development and updates for several versions of native apps for different operating systems and form factors.

From the dawn of the web, this process has been greatly simplified: instead of downloading and installing, you typed in a URL or clicked on a link.  When you had a new version of your app, new content or altered layout you published your website and your users got it right away (and only one version ran at a time!).  This was the vision of proper software-on-demand that in some ways the advent of native apps regressed on.

Thus the industry came together (Apple begrudgingly so) to find a way to marry the immediacy and low entry barrier of the web with the form and functionality of native apps.  The “why” of PWAs became:

• To provide a user experience on par with native mobile applications
• To increase speed and cost of development as compared to by-device native development
• Provide connectivity flexibility: work offline or on low-quality networks
• Eliminate app installation friction, avoid app stores’ “walled garden”
• Eliminate version release and support headaches
• Create re-use across desktop, phone, tablet and other form factors
• Improve upon typical website re-engagement
• Provide more timely user information with service workers and new web APIs like the Web Push and Notifications APIs

What makes for a good PWA?

In my experience, native apps have less features than the same company’s website/web app but carry them out extraordinarily effectively: they’re very streamlined and tailored towards the user’s “job to be done“.  Also, it’s there on prime real estate: the user’s phone screen.  To be competitive to this experience and meet user’s conditioned expectations, a PWA needs to be:

• Discoverable – a PWA is available on the web as well as in app stores
• Installable – the PWA displays alongside all the other apps (start menu, icon on homescreen)
• Responsive – an interface catered to the environment, offering smooth and immediate interaction
• Network independent – functions both offline, online and on flaky connections
• Fresh – updates happen automatically with no concerted installation process
• Safe – data delivered over secure channels
• Linkable – accessed via a simple delivery mechanism, such as a link (including deep links into specific sections of the app)

When it comes to PWA construction, “FIRE” is a convenient acronym to keep in mind:

• Fast
  The first contact with a PWA interface is an immediate, responsive and enjoyable experience
• Installable
  The PWA installs like any other native app, showing on your desktop or homescreen rather than requiring a browser
• Reliable
  The PWA is available and responsive every time the user opens it, on par with any other piece of installed software
• Engaging
  The PWA follows the best practices for high-quality UX and works irrespective of network state or device capability – there is never an empty screen telling the user to go online or upgrade

Are PWAs supported?

Many of the piece-parts that make PWAs possible have been in existence and enjoyed some amount of browser support for years, especially from Google Chrome.  Certain key browser supports to make them a viable wide-band solution to rival native apps.  Apple’s Safari browser’s notable lack of support for Service Workers and Web App Manifests effectively put the iPhone and iPad ecosystem out of reach for a PWA.  Thus for years prior to 2018, the PWA was nullified as a viable alternative to developing platform-targeted iOS and Android apps.

Thankfully, that is behind us and now, for the vast majority of users, PWAs are a highly viable and supported option: all told, as of April 2022 PWAs are supported for about 95% of worldwide users.  The following details break down the browsers and OS versions that, as of August 2020, fully support PWAs:

• Windows
  • Edge 17 (legacy Edge)
  • Edge 83+ (Chromium Edge)
• MacOS
  • Safari 11.1+
• Both Windows & MacOS
  • Chrome 45+
  • Firefox 44+
• iOS
  • Safari 11.3+
• Android 5+ (Lollipop)
  • Android Chrome
  • Samsung Browser

For IE11 and other ancient browsers (even Microsoft is abandoning IE11) the PWA will work in a typical website fashion – only PWA features of offline support and web notifications will not work. That is a failure mode I can live with.

Microsoft is abandoning IE11

What makes for a solid PWA strategy?

First the good news: the first step in any PWA strategy is to build a modern website that follows a host of best practices:

• Responsive web design principles (ensure high fidelity layout for mobile, tablet and desktop)
• Highly performant (you want the first experience to be fast and smooth)
• Be as small as possible (eventually this will be installed on a user’s device)
• A high level of accessibility (Google Lighthouse is a good tool to gauge 508 compliance and overall performance)

A key mental framing to keep in mind is that for likely the first time in your team’s careers, their users will be using installed software outside the confines of a browser. The moment you remove a browser’s UI (and attendant UX features), users will assume a superior level of functionality, so be ready to not only deliver on that expectation but also avoid the crutches a browser’s chrome provides for you. A key side effect of how a PWA works is that there are no back buttons, refresh button and other niceties that browsers provide.

Here are few fundamental considerations for a PWA that diverge a bit from a typical “best practices” web application:

• Think About UI Two Ways
  Mock screens with and without the browser UI to help uncover any potential layout issues.  And remember that some users will be using your PWA as a web app in a browser (not all users will be using it in installed mode).
• Plan for Different Connectivity States
  Remember to design for different connectivity states: online, offline, flaky network, content loading and content failing to load.  One of the more complex design patterns is sync’ing state and content after loss of network connectivity.
• App Icon and Start Screens
  Not only should the app icon and starting state screen be attractive and on-brand but also consider each different OS and provide an icon for each (nope, they aren’t all the same size and shape).
• Asking Installation Permission
  Think about when you will want your app to prompt the user to add the PWA to their home screen/desktop.  Asking too soon is definitely pushy and bound to failure but asking too late and they might not bother.  My general advice is to wait until the user has done enough in the app to be bought in but not so long that they’ve just bookmarked it.
• Asking for location data
  Don’t just ask for permission to access the user’s location as soon as they open the app – wait to ask for permission until their is a purpose-contextual reason to ask for this level of information and provide value for doing so.

Finally, before going overboard with every feature now possible with a PWA, decide what “jobs to be done” a user is looking to accomplish.  A well-designed PWA (and any digital product) should make it easier for users to complete their goals.  Some framing considerations:

• Have a clear and memorable value proposition in a prominent position – make sure the user knows what they can do
• Make procedures as smooth as possible; users tend to have little patience completing forms and finalizing the checkout process, particularly on phones and tablets
• Be careful with push notifications – they can increase engagement but carry more impact if delivered at the right time (in other words, not as soon as they hit your home page)

Some fine points

There are a few fine points mentioning before I show you some highly successful PWAs.  The following are tactical points to be aware of as you start your PWA journey:

PWA Branding and Device Icon

• Add To Home Screen
  • Android Chrome will prompt the user to add the web app to their home screen
  • iOS Safari doesn’t prompt, but we can add our own prompt
• Branding
  • We add client-branded images for app icons and the loading/splash screen to give the app a native feel (Android has more options, iOS is more limited)

PWAs and Push Notifications

• Web notifications are only operable while the user is online
• We can send web notifications to users on supported desktop browsers
• PWAs can send native push notifications to Android devices with the PWA installed as an app
• PWAs cannot send native push notifications to iOS devices or while the app is not being used
  • To overcome the iOS limitation, we can send our own designed notifications while they are using the app
  • Finally, as a full solution option, we can create our own notification service using Web Sockets or a service like Google Firebase

PWA Offline Use Considerations

Questions that need to be answered answered before implementing a PWA:

• Do we need to store any data offline?
  • If users are primarily searching, we may not want to store data offline
  • Data looks to change often, if not daily, so keeping data current is a concern
• Do users have good WiFi or LTE connections?
• How will the app work with authentication and security/logging in?

Resources around offline support (provided this is a key feature for your app):

• Navigator.oneLine API
  • Built-in browser support for detecting of a user is online or offline
• Local Forage
  • Helper library for browser compatibility for storing data offline in browsers best supported database
• Workbox
  • Google-backed JavaScript libraries for adding offline support to web apps

PWAs aren’t just for smartphones

The vast majority of literature and general coverage about PWAs concerns their use on smartphones.  A key point to keep in mind is that PWAs are also extremely powerful on the desktop as installable software for your users””the cross-platform benefit is key to how a PWA works. While having an app icon on your users’ smartphone is extremely powerful, so is having a shortcut in their Mac or Windows taskbar!

Examples

While the possibilities of PWAs are still new, several leading organizations have begun to innovate and notch some highly successful outcomes.  The following are three major PWA accomplishments that have hit my radar:

• 3-4x faster load times
• 50% increase in mobile users
• 4x increase in conversion rate to sales site

• 84% decrease in load time
• 17% increase in conversions
• PWA mobile traffic now greater than desktop

• 50% increase in mobile sessions
• 150% greater engagement from PWA installers
• Covers 55 countries

Will a PWA work for your organization? 

If you’re still operating under the weight of a monolithic legacy system, a PWA can provide a way to enable new functionality as part of an incremental strategy. For example, Mercury client Gulf Winds was able to implement a PWA to enable quick wins and integrate with their existing system. While a more robust digital transformation is still on the roadmap, we were able to serve Gulf Winds’ most pressing needs and drive immediate results in part with the “low-hanging fruit” of a progressive web application.