[bg0]

I really appreciate this link. I would have never seen this otherwise. It's kind of a disappointment for us on the enterprise side. Our main offering is an offline app where people are disconnected from the internet for weeks and we use localStorage to validate who they are. It's a bit vague about how this affects apps that don't use safari. Nevertheless, we might have to start to really think about the user experience here now that this update is out.

[roywashere]

To be honest, HTML5 LocalStorage was always different on iOS when compared to other platforms. The iOS browser localstorage is stored in /caches so it is cleaned when the device goes low on disk space. I found out the hard way, had a cordova app which ran on Android and iOS (and web) and saved an account token in LocalStorage. Some iOS users kept on getting logged out, mostly users with smaller size iPhones!

Now we store the account token in iOS keyring and that works.

ref: https://stackoverflow.com/questions/32927070/complete-data-l...

[DaiPlusPlus]

How do you use the iOS Keyring from within a PWA or website in Safari?

[jeremyjh]

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

[DaiPlusPlus]

Right, but Cordova isn’t PWA.

[roywashere]

Sure! In a PWA, storing login tokens in the keyring would not be possible. So as I said, on iOS the localstorage (and cookies) would be cleared in low disk space conditions anyway. So the PWA experience was already not good!

[yohannparis]

Webkit's website says: "[..] deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site."

It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.

[vbezhenar]

User not coming to website 7 days can't be invalid use-case. Losing important data simply because someone went on vacation is unacceptable.

[diegoperini]

Not allowing important data to be downloaded for cold storage is unacceptable.

[aquadrop]

Ok, allowing, then what? I still don't want to deal with export/import as a user.

[cmsj]

You want all your important apps to migrate to a platform where their data is all tucked away in inscrutable filesystem locations that don't expire ever?

[diegoperini]

I have a few suggestions in the comment section you may or may not find agreeable.

[blurbleblurble]

With all due respect, this comes off as apologizing for Apple's disagreeable design choice.

If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful. Your suggestions might as well be aimed at browser vendors, who could conceivably offer user friendly controls for local storage (e.g. import/export without the dev panel). But as is usually the case each of the browser vendors has these little annoying ways that they cripple the browser to protect their business models. Apple is no exception to this. Look at how they've hampered the WebGPU process. Look at the history of their PWA support.

[im3w1l]

So store this data on the server.

[matsemann]

But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked

[theamk]

For your app, maybe.

But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.

[pier25]

There are many legit uses for localStorage.

Storing JWTs, game state data, etc.

[im3w1l]

It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss.

Server side, or if you need privacy, have the user export to / import from a local file.

[felixfbecker]

This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.

[Turing_Machine]

> have the user export to / import from a local file.

Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.

[SalimoS]

If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)

[matsemann]

Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.

[Touche]

Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.

[TomGullen]

Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.

[tssva]

The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.

[untog]

You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.

[bg0]

Yea, we actually don't use safari at all in our app. So this might not have an effect but it's pretty vague.

[lonelappde]

If you don't use Safari you can patch webkit to change the policy, right? Change 7 to 10000000

[tssva]

Apple only allows apps to use their webkit implementation.

[tomnipotent]

Even for other browsers. Chrome, Edge, Opera etc. on iOS all use webkit under the hood.

[chrisfinazzo]

You could...but it's a change that the Webkit project would never accept and you would be forever diddling this value every time an update came along.

Sisyphus says 'Hi!'

[duxup]

Yeah I've got a lot of users with very shaky internet and intermittent involvement with a given application (not using it for a month, more). This presents some serious challenges / impossibilities for those user's use of a web app when they're not online.

I hope they come up with some good options as this news settles. It's hard to see this as anything but even just a accidental push ('well you should always have written an app for the app store') to force folks to write a native app / participate in the app store.

[yesimahuman]

If you're using Cordova or Capacitor this is why, at Ionic, we recommend never using localStorage for storing important data. Better to use an explicit filesystem storage solution like SQLite.

[diggan]

Yeah, as far as I understand, cookies is the only storage method that will be left to use for long-term storage of user data. If I'm wrong, someone please correct me.

Edit: getting downvoted without any reasoning provided, so I assume I'm incorrect, there are more/less ways of storing data in the future for Safari users?

[tnorthcutt]

Not sure if this answers that, but: https://webkit.org/blog/8613/intelligent-tracking-prevention...

Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

[gsnedders]

Cookies expire in the same way.

[diggan]

With cookies you can set the expire time yourself, as a developer. And looking at the list of the original blogpost from webkit (https://webkit.org/blog/10218/full-third-party-cookie-blocki...) it shows the following will be affected by the 7 day cap:

Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations

Since cookies are not mentioned, I'm assuming it's NOT affected by the 7 day cap but will instead continue to work as normal (except for the fact that 3rd party cookies will stop working, which is a Good Thing)

[tyingq]

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).

[XaspR8d]

Does this mean I'll soon be setting up an dummy "cookie maker" endpoint on my server that turns XHR body data into HTTPS cookie data as a workaround? :/

[diggan]

Interesting, I did not know that. Thanks for clarifying!

[Dylan16807]

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

[cosmie]

Technically, when you update it via js you're overwriting the existing cookie with a new one. And, from my understanding, it's then subject to the same restrictions as any other cookie set client side.

So in order to have a long-lived cookie, you essentially need to treat them as read-only client side, and push any and all update/write logic to the server such that it'll return a set-cookie header with any changes you require.

[tyingq]

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

[dwaite]

Secure + HttpOnly do not expire at 7 days. These are invisible client-side.

[colinjoy]

great, sounds like we‘ll get to consent to storing cookies more frequently - everybody loves these banners. there’s even more fun to be had, thanks to GDPR dialogs with 73 nested toggles.

[nradov]

Have you considered porting to a native application?

[Touche]

I've considered just not supporting iOS.

[xvector]

IMO it is completely unacceptable to have a persistent permanent non-expiring store in the browser. The potential for abuse is too high.

[BHSPitMonkey]

Then why are first-party cookies okay? FTA:

> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

[6gvONxR4sf7o]

Unexpiring cookies shouldn't be okay either.

[vetinari]

Users are using other than macOS/iOS devices too. Most of them are not willing to pay extra for native app that runs on only one of the platforms used.

[gridlockd]

Why would users have to pay extra?

If right now you have a web app with paying users, that means you have an accounting system of paying users.

You could publish a "native" app that simply serves that web app through a web view, using those same accounts.

[vetinari]

The issue is elsewhere: you need to pay your developers to develop the second app. You would most probably need to bring in one more team, for each native platform.

Will you get new users from that? If yes, they will pay for that (in principle). If not, just some existing users would migrate? Then you just increased your cost without increasing your revenues. So you would need to gain enough new users to make it worthwhile.

* * *

In a nutshell, it is the same reason why Adobe won't port their apps to Linux. They already have all the users that need their software, and while it would be nice for some of their users to migrate, it won't bring anything to Adobe.

[gridlockd]

You don't need a dedicated developer to ship a WebView app. That's the whole selling point behind tech like Cordova. Most of your code can stay the same and most likely all of it will stay Javascript (or whatever you are transpiling to it).

Again, if you are actually affected by this issue right now, you have a web app that is more or less trivially ported to a web view app. Your user don't have to migrate, they already have accounts, they just need to download the app again, this time from the App Store.

> In a nutshell, it is the same reason why Adobe won't port their apps to Linux.

Linux is a non-market for Adobe apps. On the other hand, if you have an offline PWA right now, you most likely already have iOS users that you would probably lose if you start confronting them with this "7 days and your data is gone" bullshit.

[searchableguy]

Why is nobody mentioning that distribution of apps is behind apple's doors and they can stop you from distributing anything they don't like or want for any reason?

On android, you can side load apps. On iOS, you can't.

You have to pay 30% cut if you are doing payments.

You have to adhere to their reviews and design guidelines. Which is OK but not ok if you are a small team and your users are fine with somewhat lacking app.