Progressive Web Apps (PWA) are web apps enriched via modern web standards with features considered typical for native apps. In addition to HTML5 APIs such as geolocation and webcam access, these include offline functionality and, for mobile devices, a prominent icon on the home screen. PWAs achieve feature parity with native iOS, Android, or Windows apps in many areas and, as web apps, circumvent many disadvantages of the aforementioned platforms. They escape the walled gardens of app stores and the classic web technologies HTML, CSS, and JavaScript now offer a respectable development ecosystem with a large variety of tools and frameworks. PWAs have another big advantage: In principle, only one app needs to be developed that works on all platforms, since web browsers exist for every operating system. Instead of maintaining a separate app for each platform to be supported (each of these apps is usually written in a different programming language and comes with completely different paradigms and patterns), there is now only one web app to serve them all – an extremely tempting offer, at least on paper. However, this offer comes with some downsides that decision-makers and developers should be aware of before deciding if they are for or against PWAs.

Whether a Progressive Web App is the right choice must be thoroughly discussed for each individual case, each company, each business model, and each product. The web platform offers a lot with the bundled power of HTML APIs and PWA offline support. Nevertheless, the PWA model with all its freedoms and restrictions does not necessarily fit every use or business case – even if it really delivers what it promises. That doesn’t always have to be the case either.

One app to rule them all?

In principle, since it is entirely a web page, a Progressive Web App can work on any major operating system and replace the native apps that exist there. The number and range of platforms a company or app must support can be quite substantial. In everyday developer parlance, the buzzword “native app” usually refers to Android and iOS, two not entirely dissimilar app platforms. But in the B2B sector, Windows and the web itself also play a major role. The development effort understandably increases sharply with the number of systems that need support, and bundling this effort on a platform that works on all systems, such as the web, is tempting, but not always realistic. Not every app concept is equally suitable for every platform, because users’ expectations and habits differ depending on the platform, and not every feature can be implemented meaningfully on every platform. Different operating systems come with specific usage patterns. An Android or iOS app will, in most cases, run on a handheld device with a touchscreen of finite dimensions, whereas a Windows app will usually be launched on a full-blown PC with a comparatively huge screen. There is a vast difference between the top and the lower end of the performance and dimension range. User interfaces are correspondingly different, and apps usually serve different use cases. A progressive web app that claims to replace a number of native apps must cover all the use cases that the native apps cover. Put another way: A PWA cannot simply replace native apps of all kinds. At most, it can unify these apps within itself. Unless the native apps in question each have the exact same feature set, the resulting progressive web app will end up being more complex than one of the native apps because it will have to serve additional use cases (the total set of all features of all native apps).

As long as the differences between various apps that must be unified are limited to layout and appearance, this is not a problem. Like web apps, PWAs can rely on the established techniques of Responsive Design and provide a user interface for all conceivable form factors. There are hardly any hard technical challenges left in this area, however, the effort required for a UX design that takes all form factors equally into account is not trivial. But it remains to be said that a user interface that adapts to all circumstances is the smallest problem a PWA can have. Beyond the visuals, however, it’s important to remember that not every piece of content has a place on every platform and the form factors that come with it. A complex dashboard for real-time data analysis with countless checkboxes and sophisticated charts probably has limited raison d’être on a mobile device. A smartphone touchscreen may not offer the dimensions or the input options for using such a dashboard, and the Internet connection that might not be continuously available during mobile use does not help with real-time data transfer. Nevertheless, including the dashboard in a progressive web app that is also designed for mobile devices and disabling it on anything that isn’t a full PC is a stopgap solution at best. Even disabled features consume a certain amount of memory and other resources – resources that tend to be scarce on mobile devices compared to laptops or desktops. Whether the features of a Windows app, an iOS app, and an Android app can be united under a common PWA banner must be thoroughly scrutinized in each individual case. Depending on the range of features that must be replaced, it may be worthwhile to bundle only some of the old apps in a PWA, or even to maintain several PWAs for different use cases. The decisive factor here is cost-effectiveness. In the end, if two mobile apps plus a Windows program and a classic web application become two PWAs, the switch could be worthwhile – provided, that the development of the two PWAs is easier and more economical than maintaining the existing apps. That is not automatic; web development is not child’s play.

GAIN INSIGHTS INTO THE DO'S & DON'TS

Angular Tips & Tricks

Learn more

The web technology trade-off

For Progressive Web Apps, there is only one technology platform that developers need to deal with: the classic web technologies HTML, CSS, and JavaScript. Implemented consistently in all browsers today, web technology offers stable standards, sophisticated tools in numerous flavors, and more frameworks and libraries than a person can try in a lifetime. It’s not all perfect, but there are worse fates than being a web developer in 2021. Still, PWA development is not a no-brainer. The web platform is not really a single, stable platform; strictly speaking, each browser forms its own platform. Each of these browsers strives (at least as a rule) to support all web standards equally, but each browser is still its own little world. This fact becomes most obvious when looking at Table 1, which compares support for various core PWA technologies in widely-used browsers.

Table 1: Comparison of support for PWA technologies in different browsers

As you can see, not all browsers are created equal and Safari on iOS, in particular, is lagging behind the competition. This is not only true for PWA-specific technologies, but also for the APIs and features that make up the added value of an app – geolocation, offline databases, camera access, and much more. While the aforementioned interfaces work flawlessly in just about any browser, it’s more difficult with voice recognition APIs and virtual/augmented reality features. The web has so far mainly produced technical specifications for these features, which have long been established on modern smartphones, but there can be no talk of broad support. It is not unfair to note that the web platform is permanently lagging behind other platforms and, above all, the innovative mobile operating systems, regardless of the specific technology in question. This is in the nature of things: While Apple can simply invent a new feature for its iPhones and roll it out unilaterally, web standards have to be discussed and implemented independently by a multitude of browser manufacturers. The slight feature lag is part of the price that users of web technologies pay for cross-platform compatibility.

Even if a feature is supported on all browsers, dealing with subtle differences between browsers can become quite challenging. One example is homescreen icons. For the Add to Homescreen feature, which allows a PWA to be installed locally like a native app, the web standards require a Progressive Web App to provide a list of icons. This list contains graphics in various formats and sizes, from which the browser-operating system combination that the PWA attempts to install picks a suitable graphic. This way, the web developer is spared from having to specify an icon for every conceivable browser-OS combination in the world, and the responsibility for solving this problem is passed to the browser programmers, who only have to solve this problem once each for their respective projects. Constant reinvention of the wheel is stopped and web apps don’t have to include a special rule for every Android subversion – that’s the idea, anyway. In practice, it turns out that individual platforms have differences that go beyond browsers and the sphere of influence of the web developer. For example, a circular icon is nothing special for Android but does not occur (at least, not currently) on Apple’s mobile devices. For iOS, all icons must be stored in square form, and the operating system itself ensures that the square contains the rounded corners typical of the platform. As a web developer, you may want to make something special for iOS in this case and selectively provide square icons. But, you definitely don’t want to get into the situation of having to define an icon for every browser-operating system combination this side of the Andromeda galaxy. Such quandaries are typical of the one-size-fits-all approach of Progressive Web Apps and can sometimes be solved satisfactorily with creative tricks, but just as often end in some form of compromise. While the icon problem can be solved quite easily (put round icons in the PWA manifest, write square Apple icons as Apple touch icons in the HTML), there are often painful decisions to be made around push notifications (not available on iOS) and background sync (only exists in Chrome), which can result in the abandonment of certain features or extensive workarounds.

So instead of one platform to rule them all, the web is more of a collection of various similar platforms that can be used to rule most of them. A progressive web app is always a compromise to some degree, and this compromise often involves all sorts of creative workarounds or painful decisions. Web app development is never easy, but this disadvantage is offset by the fundamental PWA advantage of cross-platform support. In addition, web browsers place a high value on backward compatibility – once you’ve developed a standards-based web app, it can function and make money for a very long time without any maintenance. Provided web development itself is not an insurmountable hurdle, all relevant browsers support all relevant APIs in principle, and various native features can be conceptually united in a single Progressive Web App. Only one important question remains before starting PWA development: Was was the App Store of the past really that bad?

No platform for all use cases

In the hit parade of the most repressive regimes on the planet, App Stores rank right behind North Korea. They are completely non-transparent, charge horrendous fees, take new app versions into custody on the basis of old user ratings, and use far too extensive rubber-stamp regulations to determine which content is permissible and which is not. Unlike in the northern part of the Korean peninsula, however, App Stores offer quite a bit of infrastructure that isn’t available in this form for progressive web apps. App Stores essentially function as stores in all sense of the word: they have a shop window, surveillance cameras, and a cash register. Selling an app or monetizing it via in-app purchases is part of the normal service package of native platforms, and so is analytics. Web developers have been credited with reinventing the wheel every day since before yesterday, and to some extent, this reputation is due to the fact that web developers are forced to implement infrastructure (such as payment) themselves, from scratch for every project. For other problem areas, such as analytics, web developers “only” have to choose a service provider (and its business practices, which are completely unobjectionable from a data protection point of view) and integrate its functions. But even such supposedly small stuff involves a certain amount of effort. For some App Stores functions, there is no 1:1 substitute – instead of being allowed to spread out in a reasonably egalitarian storefront, web apps have to compete with the dark arts of search engine optimization. Of course, existence in the App Store is no pleasure, but freedom on the web is something web apps have to work hard for.

App Stores have another advantage over the web as a software source: users are familiar with them, they enjoy a leap of faith, and everyone knows how to use them. Not least through Apple’s marketing campaign under the banner “There is an app for that”, it has been drilled into people’s heads that App Stores are the primary source for software. Accordingly, users are reasonably proficient in using them and don’t get a headache when it comes to conducting financial transactions. A web app’s payment form, implemented from scratch for every project as mentioned above, has a much bigger hurdle to overcome. As we will see, even if there is nothing to pay at all, the normal installation process of Progressive Web Apps is so unfamiliar to potential users that PWA developers have some work to do to keep bounce rates in check. There’s no denying that the various App Stores from Apple, Google, and others are problematic from a developer’s point of view. They exploit their monopoly position with a vengeance, and some real competition would do them a world of good. But the facts are clear: The established platforms offer at least a little standard infrastructure. The web doesn’t. A PWA is free of gatekeepers, but this freedom has to be laboriously fought for – from SEO to integrating payment providers. Unless that scares you off, you have every chance of escaping the app dictators and existing in freedom.

A whole new user experience

Progressive Web Apps are not only new to web developers, but also to the rest of the population. For the average consumer, apps have so far come from the app stores of their respective platforms and the concept of PWAs is almost completely unknown. While it is a feature of PWAs that they “sneak in” on the user’s device, how well this will work for people hardened by the web of 2021 is a big question. In its natural state, a PWA nests on a browser or operating system in several steps. The first time it is called up, the service worker installs itself and establishes offline support, which usually goes unnoticed. To actually reach the user, a PWA needs a homescreen icon, which must be confirmed by the user. This can happen in three ways:

• The user uses the function provided by their browser to create an icon on their own initiative.
• The browser offers users who interact intensively with a PWA the option to create an icon via an automatically popping up dialog.
• Web apps can disable the automatic dialog and display a self-designed install button in its place, which the user can use to request the initially disabled dialog again.

All three options have significant drawbacks, but the third option seems to be the most likely to work in the wild. The first option is practically never used – the average person has never heard of Progressive Web Apps and has no motivation to create a home screen icon for a website, beyond all questions about technical competence. Mobile browsers on Android in particular offer the function prominently, but users are very well-trained to ignore unexpected UI elements. This is not only true for new Add to Homescreen buttons in the browser UI – but every reasonably active Internet user also knows pop-up dialogs too well. Unsolicited, half-assed websites of all kinds demand permission for notifications and annoy users with newsletter forms, while more serious websites tend to annoy users with cookie dialogs. In each case, the training effect is the same: Humanity is conditioned to click away unsolicited permission dialogs unread and as quickly as possible. Accordingly, PWAs report subterranean onboarding rates with the automatically popping up Add to Homescreen dialogs.

In order to be accepted by users, permissions dialogs must be requested – a user who presses the Activate Updates button will allow and respond positively to the Notification Permissions question. This is exactly how it has to work with Progressive Web Apps. PWA authors need to make the effort to stop the automatic Add to Homescreen dialog and put a custom UI in front of it. With a dedicated button embedded in the web app, the user can request the Add to Homescreen dialog again and then – not being surprised and distracted by something more important – not reflexively click it away. This contradicts the time-honored insight that more and more users cancel a transaction with each additional step. But if the transaction was not ordered at all, the cancellation rate is almost 100 percent even at the first step. A self-built installation dialog is not witchcraft, but it is another infrastructure element that has to be built for a PWA beyond the actual app. In all of this, it is important to remember that we can change and evolve, even if that does not seem to be the trend now. We cannot rule out that PWAs will become widely accepted and users will soon welcome the automatic Add to Homescreen dialog or prefer it to non-standard UIs, but that is clearly not the case at the moment. Companies, especially Google, aren’t pushing the PWA concept with the same fervor that Apple pushed the App Store, but there is still time for that to change.

Should my next project be a Progressive Web App?

Despite all the aforementioned hurdles and quirks, PWAs have plenty of features that make the web as an app platform look very attractive. Many of the promises of HTML5 only become redeemable through PWA features such as offline support and homescreen icons, and many web app ideas only become useful as PWAs. The trade-off compared to native apps is clear: PWA development is a challenge that can be risky, but if everything goes well, a PWA can replace several native apps and be worthwhile in the end. A checklist for new PWA projects must consider the aspects discussed in this article and lead to clear statements about the various requirements and pitfalls around PWAs. The three following points are especially important:

1. First, analyze what you already have. Just because PWAs exist doesn’t mean existing native apps are suddenly obsolete and need to be replaced. Consider PWAs when you’re getting a new project on track or the current native apps are causing significant effort and pain.
2. Check browser support for important features. Above all, make sure that the features you need are not only available in all browsers relevant to you, but actually do what you need them to do. If that’s not the case, check for established workarounds or library-level solutions – they’re sometimes better than any standard.
3. Consider your users. Without the App Store showcase, can users find your app? Will a PWA be accepted and trusted by users? You will have an easier time with a tech-savvy user base than with the public.

Beyond sheer feasibility, there’s one economic question to answer above all: Is it worth it to develop a Progressive Web App? Web development, especially for PWAs, is not a walk in the park. Theoretically, native apps for different platforms can be replaced by a single PWA, but that also requires the app to be developed first, which can be tricky for companies without a well-staffed web development department. With modern tools and frameworks, web development isn’t quite the obscure magic that it was a few years ago, but it can’t be done without expertise and experience. Additionally, at the end of the day, the PWA must bring something to the table. For web apps, there aren’t established App Stores to find and sell PWAs, and well-supported web standards for in-app purchases are nowhere in sight. Like so many things, monetizing a PWA also needs to be programmed in – it isn’t magic, but it needs to be planned for. The bottom line is whether a particular problem can be solved better and more efficiently as a PWA or as a native app(s).

Definitive findings on this question are still rare due to the novelty of the technology. Especially compared to other areas, I recommend that companies interested in PWAs simply try out the envisaged app concepts in a prototype project. If you hold back a bit on framework fine-tuning and transpiler wizardry, HTML, CSS, and JavaScript allows you to hack together tech demonstrators quickly. A PWA prototype, built quick and dirty, is the best way to tell whether browser features deliver what they promise and whether users can and will work with the PWA model. Build the most necessary user interface with Bootstrap and JavaScript spaghetti code, steal service worker sample code from Stack Overflow, take API samples from MDN and throw it to a halfway representative of your target audience. This reveals misdirections and bull’s-eyes with a high degree of accuracy at a reasonable cost and, together with the checklist, provides the definitive answer to the question of whether the web is the right platform for your next project. Progressive Web Apps are not a panacea, but it’s hard to know in advance which cases the concept is good for, and which are not. Therefore, PWA ideas should be given a chance as a prototype, unless they are completely outlandish. If this prototype leads to the conclusion that the technology is no good or the users don’t play along, you know that you can leave PWAs for good reasons. But if the prototype works and is also well-received by its target group, you have the chance to develop a Progressive Web App, to rule them all and bind them.