Progressive Web Apps (PWAs) are websites that took the right vitamins. They are apps, written with the same languages and tools as a regular website, but which leverage new and exciting APIs to give a user an experience closer to a native application.

A lot has been said and written on the topic of PWAs, yet most of it focuses on a particular aspect without being clear on the actual overarching term. It is often thrown around as just another buzzword, a catch-all term to indicate a vague idea of a project that should be capable of native functionality using web technology and therefore on a lower budget. It's also often referred to as the polar opposite of a native application, a distinct separate entity, resulting in long discussions on the merits and pitfalls of both. Most of the time we see PWA being used as a deceptively simple description for an offline web app. And for others, it's an unachievable holy grail of web development, an elegant javascript-based application capable of tackling any and all functionality on every platform.

Today, we're going to try and untangle this term, and offer you some insights into what it is and isn't. At the end of the day, the words and acronyms we use in the tech industry are flexible and prone to shifts and changes, and you may expect to encounter this term in a variety of subtly differing contexts. However, we do believe it's important to understand what a PWA is, what makes a web app 'progressive', and in doing so get a glimpse of the potential future of web technologies.

A Progressive Web App is, in its essence, a large category of new (and sometimes even surprisingly old) technologies that allow a classic, browser-based web app to progressively enhance its capabilities based on its environment. Many applications you use on a daily basis fall under this category, and many classic web pages are blurring the line between page and app.

There are two key elements here. To progressively enhance, is to enhance gradually based on a vast array of possible environments and circumstances. In order to do so, our technology needs to be capable of changing its functionality on demand, and it needs to be capable of detecting its environment and the capabilities of that environment.

To progressively enhance, our technology needs to be able to actually support those enhancements, and we, both as developers, designers, and product owners, need to know which of these enhancements are possible, what value they provide, what segment of the target audience can leverage them, and how much effort it takes to implement them.

We'll dive a bit more deeply into both of these areas later in this post. First, however, a bit of history and context. After all, context is required if we want to progressively enhance our understanding.

A short tour of Web Apps

In order to truly grasp the concept of a Progressive Web App, it seems paramount to first understand what a Web App is. If you're currently rolling your eyes at the prospect of having someone explain this to you for the umpteenth time, feel free to skip this section. The rest of you may join me on a quaint trip of the bygone days of the World Wide Web.

A quick search on Wikipedia reveals a delightfully antiquated page. Its definition is a "Client-server computer program that the client (including the user interface and client-side logic) runs in a web browser." The example image shows Horde groupware, an early-2000s open-source project running on a PHP-based framework. A stark contrast with what most people think of these days as being an 'app'.

Most people who use (or make) apps on a daily basis have a rather clear idea of what an App is, and it definitely does not look like that. We're talking about swipes, animations, camera interaction and offline syncing here, not just rendering a few tables in HTML and slapping some rudimentary styling on it. But the fundamentals remain the same. This screenshot shows an application running in a browser (Be it Chrome, Safari, Brave, Firefox or some dusty version of Internet Explorer from ages past). The browser has received an index.html file from an HTTP compliant server, has dutifully read its contents and started firing requests for additional files. While the browser renders the contents of the HTML file, the by now received CSS file or files have instructed it in how to render that content visually. Javascript files are being loaded in the background to provide user interaction on specific elements on the page and images and icons are rendered when the client has received those files. This description is as true for that one WordPress blog you created in 2003 as it is for a 2020 PWA that checks all the boxes of PWA-hood.

So where do we draw the line between a web app and a web page/website?

We believe one of the fundamental traps here is one of semantics. On one hand, you have a 'computer program'. A term that feels slightly dated, calling to mind green or yellow text flickering on black terminals, a blocky IBM logo somewhere in sight. A 'web page', on the other hand, feels a bit newer. Yet even there, for most of us, this conjures an outdated image of slowly loading text-based pages, blue underlined hyperlinks providing your main point of interaction. When Apple announced the first iPhone in 2007, it touted Web-browsing capabilities as one of its main selling points. Yet the real revolution lays in the app store and those 500 first apps it contained in its 2008 debut. These apps and the torrent of subsequent apps released on the App and Play stores have shaped our idea of what an app is, and continue to shape the design decisions made when creating any application intended for an increasingly mobile market.

For most users, the distinction between an app and a web page is simple. An app is fast, smooth and available on the trusted app store. Its layout follows the operating system convention (Apple or Android), it has transitions between pages and it can still be opened while offline. In the user's mind, these apps offer a separate experience from the pages found in the tabs of their browser. A web app muddies this distinction. It claims to be an app and is styled mobile-friendly. Some of these have page transitions instead of the jarring sudden switch of standard web browsing. Some can be installed and appear on your home screen. Some use device capabilities and integrate with other apps, some can be partially used offline,... The distinction becomes hard to make, and the label 'web app' obviously causes many to immediately compare them to native apps. And if the web cannot perform as well in any of the many areas a native app touches, then what's the point of it all? Why spend effort into forcing a web page into something it is not and may never be? That's where the word progressive comes in.

One step at a time

Progressive enhancement is the art of leveraging new APIs, manifest files and the modern javascript ecosystem to take advantage of new browser capabilities when and if the user's device allows it. A progressive app is a mutating, flexible app. It looks and acts differently on each of the many devices on which it can run. This is not just limited to its looks. A progressive app has a set of core functionalities. Additional capabilities are 'unlocked' when the environment allows it: Does the device have an internet connection? Does the device allow geolocation? Does it use touch or a mouse pointer? How much computational load can it handle? Each of these may enable a different set of features, all in the same application.

Let's unpack that paragraph of fancy tech talk and see a few practical examples.

One very simple case in which most current websites progressively enhance their offering is CSS media queries. This technology is already a part of the W3C recommended standard since 2012, which is ancient in web development. (In case you don't know who the W3C are, imagine a sort of mysterious cloaked council of elders who occasionally draft huge and dry documents of proposals which then get slowly implemented by browsers. This implementation usually happens with a lot of infighting, drama and angry tweets.) Media queries allow a web developer to write a piece of styling, and tell the browser that that styling should only be applied if the browser is displayed in, for example, a width less then 1200px. Or larger than 750px, which is incidentally the width of the iPhone 6, 6s, 7 and 8. Or it might tell the browser to only use that styling when the page is being physically printed. (Yes, people still do that)

For many, this old piece of technology is not even worth writing about. It's a de facto standard in web development, and enables for a large part what we currently call 'mobile-first development'. We write a single website, but it looks a bit different depending on the resolution of the user's device.

The same applies to different browsers. Instead of media queries, we leverage techniques such as browser sniffing (conditionals which make sure a piece of code which would cause issues on a particular browser/version is not being executed) or polyfills (if a browser developer has not implemented a particular feature described in the W3C specification, or even just something many developers want, it sometimes gets added as a polyfill. This is a piece of javascript code executed at the very beginning of the web app which enables the desired behavior in a browser that does not support it out of the box). Again, these are old and proven techniques, used in many of the sites you visit daily.

The same underlying principle applies in the new and upcoming technologies many consider to be the bread and butter of a PWA:

1. A conditional check on the user's environment. This can include the browsers' capabilities, whether the calls to the server pass (if not, we can infer a spotty internet connection), device performance, operating system and more.
2. Compartmentalizing the application's features using modern development best practices in such a way that a feature can be disabled or enabled at runtime, or can even be split from the main codebase and loaded through a network call at a later time.

Combining these two allows a developer to change the features the app has to offer on the go. The experience of the app can differ for a user on a desktop Internet Explorer, on Safari on an iPad Pro, on a Google Pixel with Firefox, or on that same Pixel in airplane mode. The important part is to give as many users as possible the best experience possible.

The expanding audience

One of the central questions when developing any application, be it native or web-based, is how it relates to your audience. Who are your users, and what do they want. If you want to know whether a PWA could be the right fit for a product, a potential audience mapping can be very valuable. Let's look at an imaginary example:

We've divided our user base here in 5 distinct groups. The largest group at 35.3% uses android devices of poor to median quality, while 30.5% of the users have a more high-end device, purchased in the last two years at the >300€ range. 20% of our audience makes use of the most common iOS devices such as the iPhone 7, and only 14.2% views the app on desktop: 13.5 on a modern evergreen browser such as Chrome, and 0.7% on Internet Explorer 11. (Cue the wails and moans of the web developers reading this)

There are several ways to approach this. Note that all of these approaches are valid. They depend wholly on your product strategy and should be considered carefully and methodically.

The first approach is one of performance. Your product needs to be fast and shiny, and it needs to wow its audience with the latest advances in tech.

In this case, performance is more important than inclusion. The development team creates a web app leveraging all the latest and greatest features of modern browsers, accompanying two separate iOS and Android native applications written to squeeze the most out of their respective platforms. Because of this focus on performance, we lose 36% of our possible userbase.

A second approach shows us the other side of the coin. Inclusivity is more important than performance in this approach.

Now, our app reaches 100% of its potential audience. However, it is the classic herd scenario, where the entire herd can only move as fast as its slowest member. Or in this case, the app can only contain the features it's least performant users can handle. The web app in this scenario is very basic and has to take into account many of the idiosyncrasies of IE11, impacting both potential features and the most basic design choices. The slower android devices cause the native android app to lag behind as well, forcing the product to abandon its more ambitious set of features to provide a consistent and similar experience for all its users.

A similar approach of inclusivity and equality can be achieved with a hybrid app.

In this method, instead of developing separate native applications and a web application, a single team of developers creates a hybrid application. This hybrid app still builds to a separate native iOS app, a separate Android app, and a separate web app, but it utilizes the same code base. Depending on the skillset of your team and the desired features of the app, this may greatly reduce costs. (Note that this definitely is not a guarantee. In some cases, taking the hybrid road may even result in a larger cost down the road).

Our fourth and final option is the progressive one, utilizing a PWA.

With this approach, flexibility is central. The development team creates a first version of the app with its core features and chooses (in this example) to focus its resources on the iOS segment of the audience. This might be because iOS devices are particularly hostile to a few of the key technologies under the PWA umbrella, so getting these challenges out of the way at the start of the project might prove valuable.

Next, the team uses service worker technology to develop offline capabilities. These will only properly work on the more modern Android devices, but since they are 30.5% of the intended audience, it is well worth the effort. The iOS users will not notice any particular change in the app, but that's okay since their devices simply do not support this feature.

In the next stage, the team places its focus on providing a fallback version for poor quality android devices and users on legacy browsers such as IE11. This version strips away most of the fluff and extra features but focuses on getting the truly valuable features working for 36% of the audience. Finally, the last version is shipped containing some additional optimizations for the 13.5% desktop users with modern browsers, such as better keyboard support with shortcuts, fancy transitions and animations, and a redesigned interface.

In conclusion: The PWA approach is not inherently better or worse than any others, but it is particularly suited to projects which benefit from flexibility over consistency.