Live data from Hacker News

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

571–580 of 927 posts

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#571
post #563
post #483

The source clarifies that this only applies to websites run within the Safari browser.[1] PWAs added to the home screen aren't affected. > As mentioned, the seven-day cap on script-writable storage is gated on "after seven days of Safari use without user interaction on the site." That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use…

"Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer." But said timer... does nothing? Why does it exist?

I suppose it would still affect any sites you visit from within the PWA, for example through an iframe.

Also, it's simpler to have a timer that effectively does nothing than having extra logic to suppress it.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#572
post #505
post #494

Earlier quoted context omitted.

I promise you that Apple does not give a shit about the revenue from the developer program.

It's not just about the revenues of $100/year. It's also the revenue from 30% sharing of profits. And most importantly, it's the bigger revenue generated from having apps that work only on iOS, which drives users to buy iPhones and iPads.

Exactly. The app store's gross revenue was $54 billion last year. [1] Apple has a very strong incentive to make sure the only good way to deliver apps on iOS is the app store.

[1] https://www.statista.com/statistics/296226/annual-apple-app-...

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#573
post #470

Earlier quoted context omitted.

So you can think of absolutely no situation where a user would access a web app, and might want to store state info locally?

I can personally think of cases (not that PWAs have ever been anything but fragile when it comes to locally stored data), but as a user, the occasional clearing of super cookies is a bigger boon.

I don't disagree that local data for PWAs has always been fragile. I wished browsers were taking steps to make it less fragile, as opposed to more fragile. It would allow certain use cases to become valid for PWAs, thereby circumventing the need to create a 10mb native app for something that can be deployed much more easily and quickly with 30kb of Javascript.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#574
post #539

Earlier quoted context omitted.

Okay?

I basically assume my phone is nearly useless without connectivity. And if I want something to work in that sort of environment, it better be a native app.

To an end user there’s an icon on their screen, they tap it, the app opens. It didn’t matter if they downloaded from the AppStore or from a website. This is no longer the case which is why the OP is upset.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#575
post #182

Earlier quoted context omitted.

If the cookie is set by http headers, yes. If it's set with client side js, though, it's capped at 7 days (since ITP 2.1).

What if you have a cookie set by http and try to update it with js? Will it self-destruct now?

I would guess is works, but expiration is capped at today + 7 days.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#576

Earlier quoted context omitted.

> Apple restricts tracking by limiting browser storage But the argument that this will protect privacy in the first place seems really weak. Before this change in Apple's policy, an app could store my config data on my PC. After this change, they'd need to have me log in and send the config data to their servers. That seems like I've lost privacy, not gained it.

Wouldn't it be possible to retain the data with privacy by: - Asking the user client side for a password - Encrypt data as a blob using some symmetric encryption (AES) - Push encrypted blob to the server with login attached If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted fo…

It's very hard to verify that the data is indeed encrypted, whereas with local storage you can just monitor your network usage and see that no requests are going out. Hell, you could airgap your machine and have no problems with localstorage.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#577

I ported Polar ( https://getpolarized.io/ ) over to a PWA about a year ago. It's kind of a nightmare due to both Google and Apple messing things up. PWAs could be an amazing platform but both companies are really messing it up. Apple is trying to kill them by giving plausible explanations as to why they can't have PWAs. Security this, blah blah blah. There's no reason they can't have PWAs work well in Safari other th…

> There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.

Is it possible they also want you to port your app to the App Store to prevent an explosion of garbage and malware that could happen if PWAs really took off?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#578
post #232

Earlier quoted context omitted.

Read the article, it's not only about offline PWAs. All local storage is deleted after 7 days.

As for as "persistence" is concerned I really care only about offline PWAs. Why would a website need offline data after 7 days? It would improve performance, that's true but everything else should be "fresh" unless that said website wants to actually behave like an "app". Maybe the "website" should ask the client to be installed as "app" if the user wants to take advantage of persistent storage(and other "app" featur…

I made one of these. We generally expected users to be offline for at least a week. Probably using the app regularly on their respective devices (but possibly not), and syncing data again when they had a good internet connection. Uses Dexie and React, syncs with a horrible Drupal site. It's always going to be uncertain to rely on a database held at arm's length by the browser, but in practice it worked incredibly well on all manner of devices. I guess it won't anymore. (Thanks, Apple!).

This is absolutely a necessary change on some level, but I think if Apple wasn't in complete control of a web monoculture (and obviously uninterested in anything that doesn't sell more iPads), it would be possible to steer this API towards that without breaking a bunch of peoples' stuff.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#579
post #518

Earlier quoted context omitted.

It's no less of an issue for an online-based PWA. Where do you store login credentials or session tokens? In local storage. What happens to them when Apple decides to arbitrarily throw it away? The user has to log in again and again. This sounds like a seriously poorly thought out idea. Want to clear tracking data from random websites I've been to? That's great. But you don't mess with the data stored by apps I have…

But only if they don’t interact with it for a week. I wouldn’t be surprised if a web app I hadn’t used for a week required me to login.

And most native apps crash one a week, we should therefore automatically crash every app once a week.

Just because current apps are buggy doesn't mean we should enforce those bugs at a platform level.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#580
post #493

Earlier quoted context omitted.

"Web applications added to the home screen are not part of Safari and thus have their own counter of days of use."[1] From WebKit: [1] https://webkit.org/blog/10218/full-third-party-cookie-blocki... A Note On Web Applications Added to the Home Screen As mentioned, the seven-day cap on script-writable storage is gated on after seven days of Safari use without user interaction on the site.” That is the case in Safari.…

> Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. [...] We do not expect the first-party in such a web application to have its website data deleted. I don't get it. Which of these statements is correct? 1. "Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Of course, that counter doesn't do…

Neither.

The counter is per days of application use, so (2) is false. Not using the app does not affect the counter.

The counter is also per domain, and so while the first party domain for the PWA (which is likely to, of course, be loaded on each PWA launch) is effectively meaningless, if you visit other domains from within the PWA they will be subject to the counter independently.

Post reply on HN