BlogApplication ServicesSoftware DevelopmentDigital
Blog • • 9 minute read

The What and Why of Progressive Web Apps

Progressive web apps (PWAs) were supposed to be a silver bullet for cross-platform web development. That idea may still be viable, but it has been and will continue to be quite the bumpy journey.

In this blog

Progressive web apps (PWAs) are a bit mysterious to many outside of the web development space. Are they an alternative to developing native applications like React Native? What makes them progressive? Have I ever downloaded one from an app store without knowing it? In truth, PWAs are less of a standard and more of a methodology or concept.

The ideas behind PWAs are simple enough: create web apps that feel like native applications by being capable (i.e. can perform many of the same functions we use every day such as reading and writing files), reliable (the main resources the app needs are downloaded and stored on the device instead of fetched from the server every time it starts up, and the app is written to handle being offline in some capacity), and installable (they run separately from the browser, can be launched from a desktop or home screen, can be set to handle certain files and more).

A good comparison is the idea of responsive design, where a website's look and feel adapts to the screen size and input method (touch vs. mouse and keyboard). The main adaptation PWAs advocate for is online access by focusing on caching necessary resources and gracefully handling not being able to talk to a server, such as letting the user continue to browse what they have already downloaded or even presenting a mini-game to pass the time. This also plays into the idea of being progressive, where the application should always have a backup plan for features not being available to the user, like location data, Bluetooth or notifications.

A big upside to PWAs is that you can usually upgrade a traditional website to a PWA with a reasonable amount of effort. True, you will miss out on things like creating a native look for mobile platforms as well as not being able to implement certain features, such as push notifications on iOS, but you will gain valuable real estate on the user's screen and be a simple tap or click away regardless of if they are using the browser.

 Examples of PWAs in the real world

PWAs are more than just a nice idea and there exist several real-world examples, albeit alongside native applications serving the same purpose in many cases.

  • Twitter Lite (much smaller install size, less data over the wire than browser version)
  • Tinder
  • Starbucks (much smaller install size, no internet access required)
  • Pinterest (much smaller install size, 44 percent increase in ad revenue)
  • Google Maps
  • Google Stadia (allowed for release on iOS as would normally violate App Store policy)
  • Uber (greatly increased ride requests from desktop)
  • Microsoft Outlook

Clearly, these are some big-name companies creating PWAs. It's important to note, though, that this is usually with the intent of increasing options for users, not for replacing a native experience overall. There are still a few reasons PWAs are not all that common yet, and new reasons as to why they might never gain a respectable market share and may only ever act as an additional choice for a small set of users.

 Unstable API

Because PWAs are not formalized, it can be hard to guarantee any sort of standard behavior. For example, in Android 8 (late 2017), there were a whole slew of changes including a new installation process, changes to how icons worked which got fixed after WebAPK was added to the stable release of Chrome but also had new features appear such as Picture in Picture (often used for the floating video player), as well as the ability to emulate Chrome in Android Studio for better testing. A bigger issue for developers is that the criteria to be considered a PWA keeps getting stricter, meaning older PWAs have to be kept up to date even if it's only a small change every once in a while.

In early 2018, Apple added support for PWAs in iOS 11.3, although technically they've always been supported on iOS, just not anywhere nearly as feature-rich. However, Apple limited local data storage to just 50 Mb (plenty for text, probably a little stingy for multimedia), the app's files (source code or other cached resources) was removed if it went unused for a while, and lacked support for many other natively available features such as Bluetooth, Touch/Face ID or even running in the background. Additionally, the article linked at the start of this paragraph walks through a myriad of inconsistent or buggy behavior you would encounter when writing a PWA for iOS. The installation process on iOS is also lagging behind that of Android, as it does not support beforeinstallprompt which allows developers to customize the installation prompt and even let a user choose between installing a native app or the PWA.

There's also the issue of the messy and confusing compatibility of the manifest.json which works as one of the main signals to the browser that the website should be treated as a PWA. To make matters even more confusing, setting an icon for the app on iOS happens through an HTML link with rel="apple-touch-icon" instead of through the manifest, which has an icons property.

While most of these issues can be solved or ignored without much repercussion, there are bigger problems to consider when contemplating using a PWA as your only approach to all platforms.

 Cross-platform but not cross-browser

PWAs probably sound like a dream come true to many web developers: being able to add a small amount of code to convert an existing website into a native app on virtually every platform sounds great! It also sounds appealing from a business side, as you would get a native feeling application without needing to write it for iOS, Android, Windows, Mac and Linux separately, saving lots of time.

However, because PWAs are not a formalized standard, the browser vendors who need to implement the features to make this viable often disagree, creating a fragmented developer experience. In fact, Firefox has essentially stopped work on supporting PWAs for the stated reason that there was a low interest level from users and the amount of work needed could not be justified. Safari also does not support PWAs, making Chromium-based browsers the only current viable desktop option. While Google Chrome and other alternatives still mean PWAs can be cross-platform, forcing users into a particular subset of browsers means missing out on those user bases, especially on macOS and Linux where Safari and Firefox are more dominant.

 Feature disparity

There are several reasons to choose to make a web application in general, the main reasons being that virtually everyone has access to a browser and browsers are generally a strong sandboxed environment to work with. The biggest drawback to this is that browsers have to choose what features websites should have permission to use, like the file system, GPUs, camera and microphones, Bluetooth or any of the other many features that can easily be hooked into with native applications but run the risk of being exploited by bad actors.

While most commercial applications such as online shopping shouldn't need much more than some extra on-device storage and maybe access to the camera, other use-cases such as games or lifestyle apps might make use of features such as Bluetooth, NFC or even augmented reality.

And this is where the story of being cross-platform and cross-browser really starts to fall apart. Apple has stated that they won't implement 16 Web APIs for security reasons, specifically concerns about fingerprinting (the ability to identify a device by finding as much unique information about it based on many factors, including what APIs are available). This is a big blow to cross-platform PWAs ever truly being able to replace native applications, as most of these APIs will be available to native applications on iOS. Though many of these APIs would be for more fringe use-cases, an API that many businesses see a great return on implementing but effectively cannot through a PWA is push notifications. While Apple hasn't explicitly stated that this API will never be implemented, it's a big gap when it comes to making a PWA feel native on iOS.

 Silver linings

It's not all doom and gloom for PWAs though. The central APIs and core needs are becoming much more standard, even on iOS. And PWAs may become a saving grace for Apple as they battle legal trouble concerning the question of the App Store functioning as an effective monopoly. In fact, Tim Cook cited web apps as a means to create programs for iOS that were not controlled by Apple in the 2020 tech anti-trust hearings.

Alternative browsers on iOS are also becoming a better option as they can now run web pages with more features available with App-Bound Domains, basically increasing the level of trust Apple allows, although they will still be running Webkit and do not currently have the ability to install PWAs.

On the Android side, TWAs (trusted web activities) were introduced (basically PWAs that are specially packaged to be distributed through the Google Play Store), which should act as a huge boost towards end-users starting to think of PWAs as much more similar to native applications. A smaller, but almost as meaningful change is the changing of the phrasing "add to the home screen" to "install" as well as providing the ability to customize the installation experience in more than one way, which also helps teach users to think of PWAs as applications rather than as just websites.

It's also worth noting again that it can take very little effort to convert an existing website into a PWA, especially relative to the amount of work needed to create a new native or web app from scratch. Even if it might not be the best experience for all users, it can still be a better experience for many users and increase the reach and engagement of a platform as a whole.