An important advance in website development in recent years has been the development of progressive web applications, or PWA. Many customer-facing companies have adapted their websites as PWAs, while others have replaced their native apps (e.g., the ones you install via the App Store or Google Play) with PWAs. Should you? Let’s take a look.
Progressive web applications—the technology and its history
First, let’s make sure we have a definition of “web application” in mind. Web apps are the sites you use for a certain function, or set of functions, such as shopping carts and e-mail (such as Gmail, as one example).
To make a web app “progressive” means turning the usual design around. The standard approach has been to design the best possible site, plus a simpler version if it detects that the user’s browser, computer, or internet connection isn’t up to the task. (You may have occasionally seen a site with just text and hyperlinks, without any buttons or images, when something wasn’t working quite right.) With so-called “Progressive enhancement,” the simple content comes first, followed by images and functions. This simplifies design, speeds up the app, and allows more potential customers access to your service.
Google is generally credited with promoting the idea and the term in 2016, but in fact Steve Jobs and Apple took the first steps from native apps toward web apps in 2010. Meanwhile, Microsoft hopped on board with PWAs almost immediately after Google, and its Chrome-based Edge browser now fully supports them.
What characteristics define a PWA?
Experts agree that there are ten characteristics that define a progressive web app:
- It’s progressive, of course. The web app must work on any device, downloading increasingly advanced features up to the ability of the user’s device and browser to do so. All modern browsers handle PWAs very well, even if not 100% of the features are supported. By “handle,” I mean that the website should not appear misaligned or freeze when the app looks to enable a feature and finds a lack of support.
- Users can install it. The web app provides the user the option to install the app on the home screen or desktop. Because of that…
- …the icon looks like any native app icon, and in fact opens in its own window, rather than opening a browser to work inside. There will also be as few page refreshes as possible.
- A progressive web app will be used on a wide range of screen shapes and sizes, as well as in a variety of browsers. It will need to adapt the UI accordingly.
- Potential users can find the PWA. Search engines still don’t do so well at finding native apps in Apple’s App Store, Google Play, or the Microsoft Store, while the latter two do list PWAs and enable installation. At the same time, the search engine they use should note and communicate that it has found a web app, as opposed to a native app or simple website.
- The user should be able to bookmark or share the app’s URL.
- It should be easy to get back to using the app. Often, the app itself will issue notifications to nudge the user into returning—a key feature for younger users (though this is also a negative feature for older users, and can be negative for everyone if notifications are too frequent).
- It should be possible to open the app even when the device doesn’t have access to the internet, or when connected to a low-quality network. Even for applications in which this offline experience ability makes little sense, the app should at least indicate which functions will be unavailable while working offline.
- As long as there is sufficient connectivity, the PWA should refresh itself with the latest content.
- PWAs must use HTTPS to avoid man-in-the-middle attacks because of the way they’re used and built.
There are two items a PWA must include in order to have the characteristics listed above.
First, it must include a web app manifest. This is just a text file—a simple JSON file—the browser looks into for information about the app’s name, author, which icons are necessary, version, description, and a list of all the necessary resources (among other things). The manifest is what web developers use to tell the browser how much of its user interface to show: standalone (no toolbar), full-screen (for the most app-like user experience), minimal-UI (back and reload only), or browser (the complete browser UI).
The manifest will also be used when the app is installed on a user’s mobile device, particularly the URL it should start at when launched. Chrome browsers look for a manifest and will only show the “Add to Home Screen” prompt if all conditions are met.
Secondly, it must implement a service worker. This is a client-side JavaScript file that works like a gopher between the server and browser, enabling all of those background functions that make the PWA act like a native app. These include push notifications, caching important assets and files, and directing network requests and responses from the server. This last duty is what keeps the app up to date for the user, while page load times remain low.
What are the advantages of creating a PWA?
You’ll find a number of good reasons to provide potential users with a PWA instead of a native app or some other… flavor, if you will, of web app.
First, PWAs can be easier to write than a native app. This can depend on factors like how complex the layout is and how many features there are. If you already have a native app that was written in JavaScript, conversion is especially easy. But when you then consider the complexities of writing native apps for three different platforms—iOS, Android, and Windows 10—writing just one app for all can seem like a big win.
Furthermore, unlike a native app, much of the background work is server-side rather than client-side (i.e., in the browser on the user’s device), allowing the app to take up far less device memory than a native app would.
The flip side of this is the very fact that PWAs are designed with some client-side processing, rather than the server-side processing of a traditional web page. This does have implications for SEO—search bots would have less to read and understand if it weren’t for the web app manifest. But the client-side processing plus careful caching mean the app is useable offline. Back buttons—which must be implemented inside the app if using standalone or full-screen mode, since the browser’s toolbar won’t be visible—bring up a cached version of the previous screen, rather than leaving the user waiting. That’s important if the user loses signal, for instance, in an elevator, a tunnel, or a mountain valley.
Another plus is lower friction. The fewer steps the user needs to take in order to use an app, the greater the user’s engagement, and updating is automatically done on the business end as with any other website, and not by the user as with an app. “Installation” is immediate and doesn’t require a visit to an app store. This is an especially good attribute because no app store can take a cut of any subscription fees for PWAs.
Meanwhile, as noted above, PWAs are indeed listed in the app stores, giving them another avenue of discoverability. Regardless of how the user finds and installs the app, an icon will be there on the device home screen, able to show badges and notifications, and ready to use.
It’s not all roses though
There a few disadvantages of varying seriousness.
First, if your native app is a high-performance game, or indeed any large app with an extensive range of functions and capabilities, a PWA is not the right answer. PWA users come to the app with just one or a few purposes in mind—the app is a tool.
Second, support isn’t universal. Mozilla-based PC browsers, and Safari for Mac, don’t allow the user to install PWAs—that is, add an icon to the user’s home screen—so Firefox and Safari fans will have to use select Chrome-based browsers to do the installing. Plus, PWAs on iPhones and iPads won’t do push notifications (at least, as of October 1, 2021), and visitors to websites will not see any indication that the site is downloadable as an app.
Next, PWAs are as yet unable to access all of a phone’s features, such as advanced camera controls, the fingerprint reader, Bluetooth, and NFC—basically, features that your browser can’t access, though this is an area of continuing work.
Finally, web apps are unable to “talk” to Facebook, LinkedIn, or Google in order to authenticate logins. This doesn’t mean that logins can’t be done through these services, only that they will have to be done online, even if the user is logged in on their social media or Google app.
Is a progressive web application right for your business?
PWAs have already found a wide variety of applications, and for those with the time and/or inclination, this will be a fun space to watch to see what is yet to come.
At the front of your mind should be what almost all of us came face-to-face with due to the pandemic: Zoom, Teams, and Google Meet. All are available as PWAs, in standalone mode or full screen.
Social media, too, uses PWAs, such as Twitter (with its Twitter Lite app), Tinder, and Pinterest. This last marks an interesting use case, because of the large variety in screen sizes on which to show sometimes thousands of pinned items. Facebook, for its part, returned to the Windows Store after a year’s hiatus—Microsoft has replaced its native PC app with a progressive web app.
Commerce, of course, is well-represented among PWAs, from vacation planning (Trivago) to coffee (Starbucks) to discount shopping (Target and Walmart). Higher-end brands such as BMW and Lancôme have also jumped on the bandwagon.
When it comes to disruptors, Uber and Airbnb stand out. But you may not know of Kopa, once known as PadPiper, an app that seems similar to Airbnb but helps connect university students with available rental properties.
News media also makes use of PWAs, such as the Washington Post, the Financial Times, Wired, and, if you want to include it in this category, Medium. Each of these do have a subscription model, such that only subscribers can view articles (or more than a minimum number of articles per month).
There are plenty of categories left: games, messaging (Telegram), music streaming (Spotify), travel (the Swiss train company and United Airlines) and more. Of particular note are some that point to possibilities not yet fully explored, such as code.nasa.gov, which is a catalog of open source NASA code. Soundslice enables wannabe musicians to connect with other musicians to practice their instrument and get feedback; it may have been inspired by Duolingo, a language learning app. Lotto.de is the website for Germany’s lottery, naturally, and Yummly can find recipes for you according to your preferences or what ingredients you indicate you have on hand.
It’s an almost dizzying array of categories, but what they all have in common is the limited range of functions carried out by the PWA on a fairly simple app, even if there is a large amount of content available, and overwhelmingly so for individuals using a personal device.
Therefore, if your use case is for a direct-to-consumer app to deliver content, shopping, or a service, you might strongly consider a PWA. If you already have a native app, on PC, Android or iOS, there isn’t necessarily a reason to replace that app, since it may have strengths that a PWA can’t replicate—but a PWA is considerably more likely to do so than a “traditional” web app.
