Why haven’t PWAs killed native Apps Yet?

Kevin Basset is the Founder at Progressier, a software toolkit used by 5,000+ apps to emancipate themselves from the app stores.

On paper, PWAs are the perfect alternative to native apps: only one code base to manage, instant updates that require no approval, and no commissions to pay on in-app purchases. What’s not to like?

Although Progressive Web Apps have gone a long way since their inception, they’re not quite at the point where they can act as a perfect replacement for native apps.

So… what is still missing in 2022? Why haven’t they become the default format for apps just yet?

The PWA identity problem

I’ve written about this specific topic in more details, but PWAs still suffer from their reputation of being second-rate apps — or worse, in some cases, of not being apps at all.

In 2022, the default behavior is still to go look for apps on either Google Play or the App Store. Funnily enough, installing an app directly from a website is both faster and more convenient. But users still aren’t accustomed to this without dedicated prompts and promotion elements.

At the core of the problem is the question of trust. Downloading an app from a third party means that the third party in question (Google or Apple) attests that the app is safe to download.

But here is the thing: PWAs don’t need Google and Apple‘s approval… because they’re already guaranteed to be secure — by design. A PWA can’t read your phone’s contacts, send SMS on your behalf, or access any of your phone’s features that could expose your private information.

The value proposition of an “app store” is twofold: logistics (installing your app on the user’s device) and promotion (getting more people to discover your app). Arguably, app stores no longer do such a great job at the latter. And the logistic of installing PWAs is embedded within the browser itself.

In 2022, the whole app store paradigm is redundant.

iOS push notifications

After many years of seemingly hopeless wait, Apple has finally announced that push notifications will be coming to iOS in 2023. This is great news. Until now, you could send notifications to your Android/Windows/macOS users, but not to your iOS users.

For many developers, this meant that it wasn’t possible to rely on push notifications completely to deliver important information to their users. Web push notifications were a nice added bonus — not a crucial part of a product‘s workflows.

Provided that Apple implements web push notifications the right way (as in, following the W3 specs), this is about to change. You’ll be able to notify users on both Android and iOS with very little effort — and without having to list your apps on Google Play and the App Store.

That being said, web developers have abused the Web Push API so much (e.g. news websites requesting access on your first visit) that people have grown to detest these prompts. As a result, in some cases, Chrome (and other browsers) auto-blocks push notification requests — making it harder for developers with legitimate use cases to request access to this feature.

One of the top items on my personal wishlist would be for PWAs to be granted a higher authority than a regular website, once installed (but not quite as much as a native app). Getting people to install your PWA is evidence that they sort of trust it — they haven’t just stumbled upon your site.

A few examples of what higher authority could translate into:

• Installed PWAs could automatically be granted access to the Push API.
• Restrict access to the Push API to installed PWAs. Regular websites wouldn’t be allowed to request access at all. Goodbye BS spam.
• Bundle requests to multiple browser APIs within the installation prompt. For example, when installed, a PWA could request to get automatic access to the Push API, the Geolocation API, or the Microphone API — with toggles for users to granularly allow or disallow each individually.
• Or more modestly, Chrome could simply not auto-block push notifications when requested from within a PWA.

Native install prompt on iOS

Installing a PWA on iOS requires showing users custom instructions
Installing an app on iOS currently requires opening the Share panel and clicking on the Add to Home Screen button. This mostly does the job, but it isn’t as straightforward as installing a native iOS app.

If Safari implemented support for the beforeInstallPrompt event, the experience would be streamlined. Or at the very least, Apple could change the wording of Add to Home Screen to Install the app — Android has done exactly that a few years ago.

Although the current flow is an okay-ish workaround, it does have some unintended consequences that are detrimental to the experience for both users and developers.

For example, it’s impossible to distinguish between actual Safari (which has an Add to Home Screen button) and a SFSafariViewController view (which does not). For the record, the latter is used by a number of in-app browsers, e.g. the Twitter iOS app.

As a result, you have no choice but show your custom instructions… even when the option isn’t there. A tad confusing for users who may not be into that sort of technical nitpicking, aka 99.99% of users.

Similarly, I’m looking forward to the day when PWA developers no longer need to generate 25+ individual splash screen image files just to support every iPhone and iPad.

Better post-install manifest updates

PWAs would also become a lot more competitive if the developer was able to update the key details of the manifest (icon, name, splash screens, etc) after installation.

Google has a whole article about this, but I’ll give you the TL;DR: none of the properties you actually want to change can be changed. So once it’s installed, you can’t update how it looks on the user’s home screen.

Or at least, that was the case until very recently.

Luckily, there’s been some interesting developments in that area. Now, desktop Chrome supports changing the name of an app after it’s been installed. It even comes with a nice — albeit confusing — anti-phishing prompt so users can approve the change or uninstall the app.

Better scope management

If there’s one area where PWAs really shine is programmatic app creation.

One of my customers at Progressier is a company that commercializes software for photographers. Photographers use that software to create unique wedding galleries for their own customers.

With Progressier, each of these galleries is a unique app with its own name (the name of the newlyweds) and icon (a photo of the couple). With 10,000s of such galleries, this would simply be impossible to manage any other way.

It doesn’t come without a few bottlenecks and gotchas, however.

While it’s generally preferable to host each PWA on their own subdomain (e.g. pwa1.example.com and pwa2.example.com), it’s often not possible. In this case, the second best option is to host each in its own directory (e.g. example.com/pwa1/ and example.com/pwa2/).

Managing scopes is very counter-intuitive because of what I like to call the trailing slash problem. In a nutshell, example.com/pwa1/ is a valid scope while example.com/pwa1 (notice the missing trailing slash) is not.

If you use the latter, browsers will instead consider the scope to be example.com/ (the root domain) — the problem is that there is no error message or warning. It just silently fails.

I wish browsers would be a tiny bit smarter and would automatically handle trailing slashes in the scope field. They could just auto-correct example.com/pwa1 to example.com/pwa1/. I don’t see any use cases where the former is not an error where the dev actually meant the latter.

Scopes could also be improved on iOS. Opening a link that's within the scope of a PWA from a third-party app on Android opens the installed PWA. However, on iOS, it opens Safari instead.

Desktop screenshots

The Richer Installation UI has definitely helped bridge the gap between native apps and PWAs. By including screenshots in the installation prompt, developers can show their app in action — and it looks and feels like a standard app store interface.

At Progressier, I went a bit further by providing a free tool for designing these screenshots in addition to integrating the tool into the product itself. So if you’re a Progressier customer, you can design, manage, edit, localize, and upload your screenshots within one interface. Kinda like Photoshop meets Google Play.

The screenshots property of the app manifest doesn’t currently do anything on desktop — but there is an active proposal to also display these screenshots on desktop Chrome. You can already test this by using the --enable-features=DesktopPWAsDetailedInstallDialog command line flag.

What about native features?

Should PWAs ever be able to access your contacts? view your calendar? send SMS/MMS? set alarms? Personally, I would argue that they shouldn’t — ever.

The fact that PWAs are limited in their scope is the very reason why they are secure. Bypassing the browser limitations would set a dangerous precedent that would create an artificial need for a third-party approver (i.e. an app store) or a service like PWABuilder, hence invalidating the whole concept.

Of course, some apps do need access to these features. And for those, native is — and hopefully always will be — the only way to go.

But for the vast majority of apps that do not need access to these features, PWAs can not only be a great alternative —they’re increasingly becoming the best option.

When you consider the fact that more apps get built with Bubble, Softr, and other no-code platforms every day, it looks like this is the direction we’re headed.

And personally, I think this is awesome news for developers, users, and the web, as a whole.

Kevin Basset is the Founder at Progressier, a software toolkit used by 5,000+ apps to emancipate themselves from the app stores.