> have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer.
This makes it sound very much like homescreen apps will have their data wiped after 7 days of non-use.
> We do not expect the first-party in such a web application to have its website data deleted.
And this does not. It's a very confusing word salad.
It's not 7 days of non-use, it's seven days of application use without visiting the site.
Safari is one application, the homescreen app is a separate application. Presumably, all the alt browsers or WebView apps are separate applications as well.
Since you can't use a homescreen app without visiting the site, the 7 days of not visiting the site can't happen.
This might cause trouble if the web app is simply a list of timers which the user interacts with passively (map of earth showing day/night zones), but if there is any interaction at all the timer resets.
You can't really have "seven days of application use without visiting the site".
Data isn’t deleted after 7 days for home screen web apps.
It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app.
I can't _wait_ to deploy an application where there is literally an "rm -rf" pointed at my users data, with a complex conditional blocking it. That makes it far to easy for a webview bug to nuke my users data.
This is shoddy engineering. Could you imagine a filesystem being implemented the same way? You would never include a code path in your "mount" logic the says "if ( some condition ) delete everything;" that would rightfully be viewed as a terrible idea and a disaster just waiting to happen.
Honestly, if my data really matters, I don’t want it to be stored only in a single place. I can get the argument of wanting to have federated syncing, that would give the user freedom to choose where data syncs or doesn’t. But in my opinion you either care about the data or you don’t. Any data stored locally anywhere should be considered lost until proven otherwise. Like, drop your phone in a sewer, leave it in the wash accidentally, have it stolen, or even just have a different software bug obliterate your data and it’s gone. That’s the definition of fragility.
This mechanism failing is mostly theoretical, but having ones phone break is not; I would guess those of us who have been using smartphones for 10+ years have, by and large, all experienced data loss when storing data with no backup.
To relate to your statement, can you imagine if your data on Dropbox was stored on one harddrive, in one server, in one datacenter? Servers fail constantly. You can of course do whatever you want to improve reliability but without redundancy you are very much pissing in the wind.
On the note of “localStorage is temporary,” nothing in the spec defines how long localStorage persists, just that it is not bound to the session. In fact though, Safari already deletes localStorage when disk space is running low.
I am very much an advocate for folks being able to control their own data. I personally self host a lot and use a Synology NAS as my own backup for most things. But I think Safari would be wasting time to disable the counter entirely for PWAs. It doesn’t meaningfully change the likelihood that users will lose data. I think users often do want strong durability and privacy, and an API that n apps from needing to implement many remotes would be way more impactful. I’d love to tell an arbitrary notes app, “Go backup to this Synology NAS” without it needing to specifically support Synology NASes or for example, WebDAV. Put the provider on the clientside and you have a place to implement end-to-end encryption.
(Of course, Apple has iCloud backup, but I don’t think that covers your localStorage content anyways.)
That's all well and good except when you lose your emails that your wrote on the plane and didn't get a chance to send yet.
I'm not arguing that you should _never_ synchronize the data off the phone, but where I store data on my phone should be as robust as possible. So far I have never had my phone delete an application I had installed, but my browser loses local storage, cache, cookies, all the time. It is just not a robust storage location, and this new safari behaviour makes me trust it even less.
As a result, the web is continuously behind native apps for offline or semi-offline operation. There's no reason for that other than the shoddy engineering going in to web browsers, such as this recent addition to safari.
Also I am not saying programs and browsers should not make a best effort to reliably persist data locally... just that robust local storage only really needs to be so robust, because any more robust and you might be fooled into relying on it.