- localStorage is broken in Safari 14.1 (the latest version) on macOS [1]

- Apple added support for blob.stream() in Safari 14.1 but calling the function causes a null pointer exception and crashes the renderer process [2]

- Read this summary of Safari changes in iOS 14.5 (released a few weeks ago, and without an official changelog for nearly a week) and tell me that Apple isn't trying to kill PWAs through neglect [3]

[1]: https://twitter.com/jaffathecake/status/1389493762129375232

[2]: https://twitter.com/feross/status/1386835131780931587

[3]: https://firt.dev/ios-14.5/

Also still no push notifications. That rules out a huge swathe of apps completely and kneecaps the rest.

I have been pushing for Push notification should be part of HomeScreen WebApp and not on Safari itself. No one likes them on Website, which is a valid argument. But I dont think Safari team sees the need for it.

Not just do they not see the need for it, they actively keep it out. Push notifications are an important and valuable differentiator.

Apple does not want PWAs, they want all apps in the walled garden.

The rest is just “theatre”

They do hold back PWA's though. They could offer opt-in push notifications for example. That's the only thing I miss as a solo web developer, and the only thing the users of my websites want (functional notifications of course, not marketing).

I'm not recreating my websites in app form just to have that. But Apple sure wants me to.

As a user, I really don’t want PWAs having that ability.

If Apple allows PWA to use notifications, you as a user will have a choice to accept or deny it.

If Apple doesn't allow PWA to use notifications (current situation), then neither the developer or you as a user have a choice.

Guess which one is best for the users overall? Guess which one is best for Apple overall?

While I get the utility of push notifications and part of me likes the idea, it will get abused in the same way it was on desktop where every second website asks for permission to send you notifications or install a PWA to be able to do so.

I suspect Apple has internally discussed it and concluded that it would too likely be abused and result in a poor user experience.

Also, Apple deliberately does not like background connections for battery saving reasons which is why everyone is required to use their push service, meaning iOS maintains a single energy efficient connection instead of each app maintaining their own TCP connection which may have no regard for energy efficiency.

I acknowledge it's possible that they don't want to remove reasons for people to rather make native apps, but given the other reasons, it would not be my first guess.

So have a global switch to turn off the ability to even ask; hell: make it default disabled for all I care... solving your petty "I don't want to be bothered by pop-ups" issue isn't even remotely complicated, and that this is a continual refrain preventing the world from having fully-functional applications for software you apparently don't want to use anyway is not just ridiculous and demoralizing, it is shameful.

Just allow push notification on WebApps but not on Safari.

Exactly, if it was only available for websites added to the homescreen I would jump from happiness for at least 24 hours.

> it will get abused in the same way it was on desktop where every second website asks for permission to send you notifications

I really wish Google would crack down on this between the Googlebot and Chrome. There's zero valid reason for a website to send a notification request without user action to initiate it. The Googlebot could record any unsolicited notification requests and negatively impact the ranking of those sites, it's a decent indicator of scammy sites to begin with. Not to mention blacklisting those sites from making a notification request to Chrome.

Chrome could also just watch for notification requests no differently than how popups are blocked already. I'm sick of the hordes of websites constantly spamming those requests. What's sad is that I'll frequently see other users actually accepting those requests and getting a barrage of ads that they don't understand how to stop. This isn't rocket science to fix.

Browsers should again be user agents and just let me set a default. 'dont bother me with notification requests. ever.' is perfectly valid and implementable setting.

Of course, I agree! But your comment is assuming the platform offers notifications in the first place. Apple has decided here that you should not even have a choice.

I agree! Apple seems to be forgetting that support does not equal a horrible user experience: they can simply set it to this default by default.

I don't want a choice to accept or deny it. I am utterly fatigued of choice. I want no push notifications and no reminders that push notifications exist.

Then you could buy a Nokia 3310i. Problem solved.

Or I can buy an iPhone. Problem already solved.

But a lot of applications ask to send notifications on iOS, doesn't solve the problem as that person seems to not wanting to even be asked about it anywhere.

You're correct, even iOS is not good enough. If an app asks and it's not a messaging app, I usually uninstall it.

I'd compromise on "Install" vs. "Install with Notifications" as two options when buying/downloading an app. But having to do any of the developer's administrative bullshit when I'm trying to use the app is disrepecting my time.

Otherwise I don't want to see that shit until I go into a "Settings -> Notification" menu and explicitly enable it. And never in a web browser.

I hear you. But I think you're in the wrong thread, we were specifically discussing how Apple is making PWAs different from normal apps _just because_.

Frame your argument differently than "you as a user have a choice" if you want to make that point.

The model of "user choice" has contributed more to the modern hostile computing environments of the past decade than maybe anything else. Users don't want choices, they want tools to help do what they want, not what mediatech/adtech/social garbage app firms think they should want. Mostly, users want their computers to shut the fuck up and get out of the way.

Then don't use it and deny the notification permission like you can for normal apps. But if the users wants that ability they should have the option to enable it.

I've made a messaging web application for my work, and notifications are important for a messaging app. Luckily it's a small business and everyone who needs to access it has an Android

It’s really not too difficult to build webview based wrapper app around your website. I’ve done it many times, and then you can have notifications or any other native features you might need.

It's not an issue of it being technically hard - it defeats the whole point of using a PWA. Your users now need to download the app from the App Store and you're subject to App Store review policies.

It’s not hard, but it shouldn’t have to be a thing. I hate apps that are nothing more than a skin around the actual website.

It's not hard to build, no. The hard thing is having to pay $100 per year to Apple and submit yourself to Apple's rules in their app store.

> the author's conclusion is more or less "no, Apple isn't trying to kill the web;

Allow non-Safari browsers (not just re-skins!) on iOS and I'll believe the author.

Their rationale for not allowing other browser engines is that allowing JIT (writable AND executable memory pages, in general) would make the hell break loose.

This is an insult to their OS team. macOS appears to be working just fine.

Well, if there is an RCE vulnerability, that would allow the user to run arbitrary code on their own device with the same permissions that the browser process has, which is clearly unacceptable in the iOS world.

I don't see how that could be acceptable in macOS world.

On macOS you as the user already have complete and unrestricted access to your computer. You don't jailbreak your mac because it already comes with root and an unlocked bootloader. Mac apps also have much more access to the underlying system than iOS apps do, and this helps with better sandboxing, I presume.

This was a good argument in the past, because there were very few ios exploits and apple was proactive in hunting them down, to prevent jailbreaking. Not sure if it is a valid argument today.

JIT is already allowed on iOS since 14.2 though.

For externally-loaded or user-supplied code as well?

This is very relevant insight, thank you!

Apple investing in its own development stack has become "Apple is actively crippling PWAs" for a lot of people.

Apple recently suggested [1] to Australian authorities that Apple can't possibly have a monopoly on app distribution since they have no restrictions against PWAs which "have the look, feel and functionality of a native app". But they fail to mention that they control exactly what functionality is actually available to PWAs. And right now it's A LOT less than what is available to native apps.

Also, most users are not aware that third-party iOS browsers like Chrome, Brave, and Firefox are actually just light UI "skins" on top of the Safari browser engine, Webkit. Apple refuses to allow third party browser engines on iOS.

So this means that it's not possible for users to just switch to another browser in order to use more powerful web apps. They're literally prevented from doing so by Apple's policy to ban browser competition on iOS.

[1]: https://www.accc.gov.au/system/files/Apple%20Pty%20Limited%2...

> Also, most users are not aware that third-party iOS browsers like Chrome, Brave, and Firefox are actually just light UI "skins" on top of the Safari browser engine, Webkit. Apple refuses to allow third party browser engines on iOS.

IME even a lot of developers are unaware of this fact.

An added annoyance flowing from this is that Apple does not allow remote debugging for webviews, so any reasonable debugging flow for those browsers is blocked. Great fun when you have a bug in iOS Chrome only.

You can remote debug webviews (from Safari on a Mac), but only web views in apps signed with a development provisioning profile (1). So to debug web content in iOS Chrome you would have to build and install Chromium for iOS yourself, rather than use the Chrome App Store version.

(1) https://webkit.org/web-inspector/enabling-web-inspector/

This statement both misunderstands skins and browser rendering engines (and javascript/jit).

Apple does not prevent or refuse third party browser engines.

Can you elaborate?

My understanding is that third party engines are allowed. They just can’t JIT the JavaScript unless they use the builtin Safari one. So, if you want to have the same performance of the builtin Safari browser, you really need to be nothing more than a skin around it.

This is false too. "Nothing more than a skin" suggests you can't make a full-featured browser, with your own code, that you're just replacing the Safari UI. This is simply not true.

I literally said that they are allowed. They just can’t JIT the JavaScript, so performance suffers compared to Safari. So, if you don’t care about JS performance, then yes, you can make your own full browser with your own rendering code.

Poor company worth $2 trillion and with $275 billion in revenue / $57 billion in profit can't bring its support for PWAs up to par with other OSes.