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

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

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

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?

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

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.

I strongly oppose Apple's anti-consumer practices in their App Store policy, PWA policy (non-existent) and similar places. I just believe this (localStorage policy) is not one of those cases.

Agreeing with Apple's disagreeable design choices isn't an apology, it's an honest opinion. If these choices are disagreeable, which I believe they are, they must be also agreeable by definition.

There's one simple thing that Apple could do. Do not delete local data if user bookmarked page from that website (or pinned it to home screen for mobile devices). Now bookmarked website treated like an "app" with slightly less restrictions and some random website data will be eventually purged (although I believe that 7 days should be extended to few months).

This is a great idea. Long forgotten bookmarks now has a purpose. I wish someone pitched this to all browsers out there.

> If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful.

Not if the features allow for increased web tracking.

I don't think that web tracking must be fought at expense of user UI. It's fine to fight web tracking by introducing measures that don't break honest websites. It's not fine to fight web tracking or anything by crippling user experience with honest websites.

> Not if the features decrease the need for the App Store

Fixed it for you. It's all about profit.

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

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.

There are many legit uses for localStorage.

Storing JWTs, game state data, etc.

I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.

Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins).

This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).

It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.

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.

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.

The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent.

If browsers asked approval before using localstorage, we wouldn’t have this decision.

Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy.

This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.

Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.

The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/.

Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.

Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.

Not sure about pinning, but bookmarking should not grant any extra rights. Even the useful websites should not be able to track me forever.

Look, we already have lots of website prompts, like camera and location. The best thing, privacy-wise, would be an explicit prompt: "this website wants to store information, possibly including tracking identifiers, forever. Allow?"

This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.

I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely.

Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over.

I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.

I really liked the web when it was just documents.

> you didn't build an app, you built a web page

"Progressive web apps use modern web APIs"

The word application is there twice. I don't have to like it.

> they are just web pages that exist in a web browser for the lifetime of the tab they're in

Evidently not. My opinion doesn't matter.

> They shouldn't expect to have any persistent storage

2016 "With Chrome 52, we're introducing the ability to make storage persistent"

> ...a clear lifecycle of installation and deletion that the user has complete control over.

I've never asked for 7 days

> it will never be as good as native apps

I don't develop anything for walled gardens. I cant wait for my linux phone.

> it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

This already happened. Again, I don't have to like it.

> I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle

But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless?

I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound.

This is how it should work!

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

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)

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.

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.

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.

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.

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.

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

Apple only allows apps to use their webkit implementation.

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

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!'