Hacker News Reader

Comment by lmm | Hacker News Reader

> This wouldn't be much of an issue, of course, if Chrome would just run on iOS like it does on any other OS, so Google can implement PWAs themselves.

You do understand that the reason it doesn't is because Apple won't let it, not that Google don't want to?

View on HN

Of course, Apple is sabotaging Chrome and has been for years, and that's a much bigger problem than PWAs. The Safari team shouldn't need to implement PWAs against their will, Apple should instead let Google bring out a browser that does PWAs and then let the users decide if they want to use PWAs or not.

Google does something quite similar, though; Chrome can install applications into Android's app drawer, but that requires privileges other browsers can't attain, needing to resort to things like widgets instead. Firefox doesn't care about PWAs and Apple doesn't care about any platform but their own, so it's not as obvious a problem, but Android is full of "you must be the manufacturer or Google to compete" permissions. Android is just a lot better at fair competition than iOS, to the point you'd barely notice.

This is a fantasy. No customer wants PWAs. They exist to make developers' lives easier, not consumers' lives.

Developer efficiencies can be translated to customer wins.

Then allowing Apple the efficiency of not implementing yet another way to build a GUI also is a customer win.

Apple already implement everything needed. They just decided that they can clear client-side storage for PWAs whenever they like (deleting user data), making them useless for anything that needs to store data and isn't synced to the cloud.

The goalposts move every time Apple resolves some bug that PWA advocates promise is the one issue holding them back from taking over the world with crappy web apps.

Apple hasn’t resolved any of the main issues.

Install and discoverability is still hidden. Push is gated behind install. Safari’s scroll bugs haven’t been fixed despite us extensively documenting them, emailing to Safari’s leadership and raising them every year as the number one bug.

The number one thing we’ve asked for is third party browser engines on iOS.

What goalposts do you think have moved?

Nope, it's been push notifications and persistent storage for a decade.

I would also add: - Install Prompts / Discoverability - Bugs (like https://github.com/web-platform-tests/interop/issues/84) which likely would only get fixed if Safari has heavy competition on iOS (it's a funding issue)

Certainly in theory, almost never in practice. The enterprise slop shop that chooses web technologies because the consultants are cheaper is not trying to make anything lasting or delightful.

The consumer doesn't care which method is used to serve an application. PWAs could easily be presented to the end user like a native App.

The problem is rather that PWAs would prove a viable path for universal cross-platform applications, taking away the gatekeeper role the OS-vendors have.

Paradoxically PWA-support is also part of the "we're no gatekeeper" narrative, so it's in the OS-vendor interest to keep it maintained as a hampered alternative to native apps.

> The consumer doesn't care which method is used to serve an application. PWAs could easily be presented to the end user like a native App.

No it can't. The web will never support what's necessary for parity with native apps. Imagine trying to implement Liquid Glass in CSS.

First, you're mixing up capabilities of PWA vs native apps (no one stated they're equal) and how an OS presents Apps differently from PWAs (which was my point).

Second (even though it's completely beside the point), especially Liquid Glass could be implemented in PWA, because it's a rendering effect the OS could put on top of appropriately tagged elements of the application. And voila, the same webapp could render in Liquid Glass in IOS26 and in less-gaudy Liquid Glass in IOS28, and meanwhile in no Liquid Glass at all on devices that don't have it...

PWAs are the primary way for small busineses to have internal private apps for running staff services on local devices. Apples App Store has way too many hoops to jump through and has far too high a wait time to publish for businesses to move fast and update internal apps with bugfixes and new services etc.

Android accomplishes this by allowing devices to connect to private app stores and repos, which enable companies to issue their own apps on their own terms. As Apple plays hard ball on this front, the only way is to use a PWA.

Custom apps published for internal use by companies with fewer than 100 employees who aren't eligible for enterprise app distribution sounds like a niche of a niche use case, so it's pretty consistent with my view that they're more developer catnip and not a serious technology.

Thats a lot of assumptions to back up your own point.

Your point was PWAs are necessary for small businesses to distribute apps. I just spelled out what that meant, since businesses with >100 employees can just use enterprise app distribution on iOS.

I would personally say that the barrier to entry for Apple enterprise app distribution is very very high, and requires so many hoops to be jumped through that it would take a much larger company than 100 staff to warrant that

https://support.apple.com/en-gb/guide/deployment/depce7cefc4...

Reply on news.ycombinator.com