Demystifying the Progressive Web App
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.
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'.
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
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 underlying principle applies in the new and upcoming technologies many consider to be the bread and butter of a PWA:
- 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.
- 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.