HACKER Q&A
📣 NosmanWert

Is it me or PWAs are pretty much dead?


It does not make business sense for Apple or Google to allow them for obvious reasons. They get money from in app purchases. If every app was a PWA they would lose a lot of revenue.

Even for businesses that are ad supported they are better of with native apps. You can block ads on a PWA very easily because it's a web app. With a mobile app good luck switching the ads off.

Now, I get the technical advantages of a PWA but it seems to me that it has failed to take off because of the business reasons above.

Is my assessment correct?


  👤 foxylad Accepted Answer ✓
PWA stands for Progressive Web App. More here: https://en.wikipedia.org/wiki/Progressive_web_application

👤 bigiain
There is a huge category of apps that are not ad supported and do not need IAP.

There's a somewhat serious blocker for some apps in that iOS doesn't do push notification to PWAs, but in my experience, those three "blockers" only apply to a quite small cross section of all the apps and app ideas I've worked on.

Some people still argue "But I need 'discoverability' in the App Stores!". In my opinion those people are stuck back in 2012-era business models, indy devs or small businesses getting prominent enough app store promotion to move the needle is more like winning the lottery than a reasonable expectations of user acquisition... And also, Google at least have let PWAs into PlayStore for a couple of years now...

I think there's perhaps a stronger argument to be made that PWAs were pretty much never "alive" in the first place, than that they're dead now...

The biggest successes I've had with PWAs with clients is to add the PWA to their website when it's pretty much already fallen out of a hybrid app build where you can demo it to them, rather than trying to convince them to take the PWA approach from the outset.

(Note: this is almost certainly an artefact of my perspective of the mobile dev market/industry, and the sort of clients my bosses and marketing teams have landed over the last few jobs... It'll look super different to people who've specialise in, say, casual gaming, or startups - my app dev world has revolved around gov and SMB mainly, not app-first digital businesses.)


👤 Daishiman
PWAs definitely exist for smaller apps, companies with smaller development budgets, and internal usage. Maintaining teams of mobile devs for apps that may have a couple hundred users is a waste of money when your perfectly capable web devs can learn to use Cordova or similar platforms.

Thing is, doing web development is _freaking_ hard. Learning the quirks of different mobile browsers, and dealing with Apple purposely slowing down Safari development to make it an unappealing platoform for web devs, makes thigs pretty difficult.

But even without those things, just making a regular SPA that can downscale well and play around with different browsers is still a huge challenge. Whenever my frontend dev friends complain about the ridiculous bugs they have to deal with I just wince. Comparatively speaking, backend development is just way more consistent and predictable.


👤 nujabe
First of all, PWAs are already allowed in the Play Store. It's also possible to publish PWAs in the App Store, although it's currently quite difficult to get it accepted through the review process.

PWAs will go as far as service workers, and they are far from dead. Which is to say, PWAs will not live or die based on whether they can be installed via app stores.


👤 postalrat
Google has pushed PWAs more than anyone. Now Microsoft is getting on board. Apple is dragging their feet for the reasons you mentioned.

But IMO there will also be room for both PWAs and native applications. I hope Apple will soon agree and help move things forward.


👤 heavyset_go
Apple refuses to implement PWA features in Safari, and they don't allow you to run other web browsers unless they are skins over Safari's WebKit.

👤 shireboy
I do not think that is correct. Both Google and Apple _do_ allow PWAs. You can use many of the offline APIs, etc. and publish a web app that can be "bookmarked" to the home screen, have icons like native apps, work offline, etc. There has been some controversy around privacy controls that affect PWAs (https://ionicframework.com/blog/is-apple-trying-to-kill-pwas...) , and of course it won't be able to access ALL native functionality. You can also publish Cordova/Capacitor/NativeScript, etc. based apps to the app stores.

While there may be some incentive for app stores to cripple PWAs, and some privacy controls and technical reasons that limit access to some native APIs from web code, I don't think it's true that Apple or Google "don't allow" PWAs.

For paid apps, I think the issue is discoverability. App Stores remain the main way people find apps, so publishing to those is often preferred for marketing, instead of saying "click 'add to homepage' to install." I do think there is a place for one or two "PWA App stores"

I also think enterprise and in-house apps make a lot of sense as PWAs. Company's internal apps don't need app stores, and can save time and money targeting both platforms with PWA apps users can install from the company intranet.


👤 Barrin92
The assessment might be correct right now but given the current climate around the world I think they're going to gain popularity. The dangers of being dependent on app stores seem to have become pretty apparent in the last few months.

👤 matthewhartmans
PWAs are still around and kicking!

I have released a few PWAs for Android: https://play.google.com/store/apps/dev?id=746767314934473577...

All the apps listed on my profile are all PWAs.

My understanding is it's still evolving and they are trying to work out ways to monetise from it.


👤 tyingq
There's a pretty good blog post that covers a lot of the issues. Safari, for example, doesn't do push notifications or background sync. https://love2dev.com/pwa/ios/

👤 joshuanapoli
One niche for PWAs is enterprise apps that require offline functionality. A PWA is easier to distribute and is less expensive to develop than a mobile app.

👤 ksec
You mean PWA as a technology is dead or as a User Product ?

Either way I think that is the wrong question to ask. Did PWA actually bought a better Developer Experience? Or did PWA bought 90% of the current best App Experience with 10% of the development time required for Native Apps?

Did the consumer really felt PWA was providing 90% of the best App Experience. Some of these may be subjective. Most often developer would come in and say it is 90%, but in fact for users that demand quality ( Steve Jobs ), it is no where near 90%.

And I think some other comment have pointed out, It wasn't even "alive" in the first place.

I think the future is QR Code Apps like What Apple demonstrated. Except it would be on the Web with PWA.


👤 ggeorgovassilis
I ported the 70s Super Star Trek to a PWA, with some artistic license for the UI.

https://github.com/ggeorgovassilis/superstartrek


👤 jamil7
Whats the endgame with PWAs in terms of capabilities? Are proponents pushing for every native API to be available? There are some fundemental differences in how things like navigation stacks work on Android vs iOS and a whole host of platform specific features and APIs on each platform that don't match up 1 to 1. Especially with regard to gestures, UI and accessibility. Maybe I'm asking the wrong questions here and the sweet spot for PWAs is covering the space that things like React Native and Flutter currently occupy rather than trying to "fit in" perfectly with the platform.

👤 impassionedrule
One of the issues I find is the lack of compatibility across the various mobile browsers.

As I'm building a PWA, I'm finding certain Web APIs that were intended for PWAs to be incompatible on Firefox/Safari, which defeats the purpose of "write it once/works everywhere on the web". For example, the Web Share Target and install prompt APIs have regressed from a W3 standard to a Chrome-specific standard.

I'm looking into Capacitor/Cordova as an alternative in the meantime.


👤 endori97
I think there some use cases for internal business apps, eg create some UI elements, open a websocket, write to database, and provide an icon on the mobile home screen. In terms of general apps, the major problems are lack of Safari support (push notifications for example) and access to the hardware/OS level stuff (like can I get the phone number of this phone without a Native App? Can I auto-focus the camera? Can I get the contacts? No, no, no you can't)

👤 disrael
https://www.uclusion.com uses PWA to be on mobile. Its true that means we don't have push notification support on Apple phones but since we have email and Slack integration having our own push notification is much less of a priority.

👤 jameswestgate
If they were a better solution all apps would already be PWA’s.

👤 pcmaffey
I’ve wondered if an app-store app could work as a sort of local server for different PWAs, handling notifications, hardware apis, etc.

👤 jasonv
Any recommended PWAs, esp for iOS?

👤 spiralganglion
For my money, the issue isn't lack of cross-browser support. It's the process by which the PWA specs were designed in the first place.

There are more than a handful of cases across the past decade where a new "web standard" didn't emerge through the usual standardization process — proposal, discussion, experimental implementations, feedback, etc. Instead, these "standards" were developed directly in one of the browsers, shipped, and then promoted as a feature that developers should begin targeting, totally bypassing the usual process, with the tacit expectation that other browsers would be forced to follow. Apple did this with and some aspects of CSS3 to help with their push away from Flash. Google did this with many the PWA APIs.

All along, as the PWA APIs have been released from the Chrome lab, there's been a certain contingent of developers who heap scorn upon the Safari team for not implementing these APIs too — as though the existence in Chrome (and, in some cases, Firefox, who tend to follow-fast as a survival instinct), plus the Chrome team dropping specs off at the W3C working groups, were cause enough for these APIs to be regarded as "standard". The error of these devs is confusing ubiquity and standard.

Most PWA features are, at current, about as standard as ActiveX was. They were designed by Google in private, to suit their own ecosystem goals. They might be good for the web, by providing an alternative to native apps — but they might also be bad for the web, by forcing browsers to serve as an app platform instead of a hypermedia user agent.

Sadly, we don't get to have that very important, very nuanced discussion. Instead, we're having the discussion Google wants us to have (quotes from this HN thread):

"Apple refuses to implement PWA features in Safari"

"There's a somewhat serious blocker for some apps in that iOS doesn't do push notification to PWAs"

"Apple purposely slowing down Safari development to make it an unappealing platoform for web devs"

"As I'm building a PWA, I'm finding certain Web APIs that were intended for PWAs to be incompatible on Firefox/Safari"

"the major problems are lack of Safari support"

Google won a dev-rel PR battle here. Apple have won similar battles with other "standards" (for instance, there's a similar split in opinion around Flash, but until recently the "Flash deserved to die" contingent have been dominant, which suits Apple just fine).

So why did PWAs fail to take off? I would argue that it's because they're a significant alteration of what the web is meant to be. They're a big step toward defining the web as a full-throated application runtime. I don't know that the rest of the web ecosystem is on board with that redefinition. At least not yet, and not merely because Google tried to will it into being. That change may come in time, perhaps under a different name, or perhaps not at all. But if it does come, I hope it does so through a process that reflects the interests of more than just Google.


👤 moxylush
PWAs are not dead. Native apps are on life support. People don't want to install apps, its inertia. People don't want to maintain two sets of code. People don't want to submit to Apple and Google for approval.