Hacker News new | past | comments | ask | show | jobs | submit login

I already have a comment on this subject in a thread here but I believe this should be stressed more explicitly.

Apple didn't kill offline web apps. You can always add an interaction to your app which exports the stored data into a file which then can be saved by the user. It can be done entirely on the client side as well. If anything died here, it is the implicit consent by the user for allowing unnoticed storage space consumption. Implementing an export function will automatically make your app portable, which is always appreciated I believe.

Most data on local storage is some kind of structured tree, table or blob. All can be exported with only little effort.

HTML5 games -> Prompt user with a dialog to download saves/assets after they play the game for a while.

Productivity apps -> Detect "ctrl/cmd + s" to prompt a save dialog. Add save buttons somewhere visible.

Map like apps -> Do nothing. If the user is not visiting the map for 7 days, they don't need the map data persisted either. If necessary, allow explicit save with UI buttons for people who travel often.

Apps/sites which use local storage for auth related artifacts -> Notify users if they click "Remember Me" and explain them the caveats. Allow for encrypted save if users ask for it.

Kiosks -> Use Electron or a similar tech.

I am open to counter arguments. I don't have any idea about how mobile browsers behave for the scenarios stated above.

Edit: I use draw.io since last year and the experience there is as refreshing as it can be in this SPA jungle. I use it as a good example to learn from for my own web app projects.






This might technically work, but is an absurdly user-unfriendly.

Name a modern game that required you to manually manage game state files, let alone didn’t have autosave. It’s a feature users expect, and they’re going to have a bad time. I don’t want to play a quick game on my phone and have to remember to save and where I am keeping my save files.

I’d argue a far better options would be just to treat local storage as a permission like camera or microphones.


While I agree that it’s ideal to treat localstorage as a permission, as someone who has played a lot of games over the years I can tell you that I wish I could manually manage game state files.

The current way iOS does it (either keep the game installed forever or erase all your progress when deleting it) is a huge barrier to me getting invested in iOS games at all. With “save progress to file” (and loading), I would be a lot more comfortable.

I would still want autosave though. No way do I want to go back to the era of “oh all my work for the past 6 hours is just gone?”


Downvote?

Our suggestions are not mutually exclusive options. Both can coexist if the developers are ready for the implementation burden.

The issue with the permission model is there has to be a mechanism to prevent overuse which I believe is always worked around by annoying the user with the prompt as often as possible until they concede.


I don’t even play games but I wouldn’t expect a web game to store all of its metadata in my local storage. I would expect it to store data on their own severs and only store active gameplay information locally.

My browser storage is not a game developers long term storage, its a cache.


It's not about metadata or "web games". It's about apps/games that can be used offline. For that to work, all the data needs to be stored client-side.

> My browser storage is not a game developers long term storage, its a cache.

IndexedDB is explicitly not a cache, it's long-term data storage for significant amounts of data.


Cookies can be used for storage for up to a year, but it’s commonly accepted that browsers vary in implementation of this based on user settings. So why wouldn’t user settings exist for other kinds of permanent or session storage? Google Chrome is so dominant in both browser-making and standards-making that we’ve forgotten the browser — and user — is always king when it comes to the web. If users want permanent storage they will use alternative browsers for those particular sites. And while site authors can block Safari with a prompt, it’s then up to users to change browsers. Presumably for developers these will have knobs to tweak so local storage can continue working in alternative browsers on iOS the way it always has. Presumably Safari will eventually get a config toggle for this setting if it isn’t already there. Users already don’t notice when browser history is cleared, though advanced users will configure this by following instructions on Google. Same here.

> Google Chrome is so dominant in both browser-making and standards-making that we’ve forgotten the browser — and user — is always king when it comes to the web. If users want permanent storage they will use alternative browsers for those particular sites.

No, they generally won't. There also aren't really any "alternative browsers" on iOS, they're all Webkit-based.

> So why wouldn’t user settings exist for other kinds of permanent or session storage?

Nobody is saying there shouldn't be any settings or consent in this regard. What we get here is not a setting, we get one major player deciding that there will be no way to properly implement offline web apps on their platform.


I disagree that there’s no way to implement an alternative to Safari, besides Chrome there’s also iCab and other browsers that show not only a completely different UI but also innovative new features. Even if WebKit makes it impossible to remove this restriction, a third-party browser could find a way to intercept calls and keep its own local storage, read and backup native local storage, or provide other means to local storage via proprietary JS APIs, and if that browser is Chrome, it will gain traction. Especially if Apple changes iOS to allow users to change default apps.

Why? Are you paying for it? To you, it's trivial amount of data that you can wipe if you somehow desperately need the 1mb, to them it quickly adds up to significant costs.

I find this position absurd, just like the suggestion that everyone should start programming complicated user hostile save flows.


Yes, it's their device, they literally are paying for it. What kind of question is that.

He was asking about paying for the game.

The above comment was talking about persisting save files to someone else's servers.

The article as well as my concern here is not about the browser proper but web apps like you install onto your phone and one of the major points of is that they work offline despite t

>You can always add an interaction to your app which exports the stored data into a file which then can be saved by the user.

But... why? Drag the user through some dialogue to save a file locally / manage / be responsible for that and then deal with that whole deal? That seems like very... old / unnecessary.

The fact that applications store some random things locally to me is neither surprising nor a hassle. Browsers already cache files and etc. Unless I don't know something... LocalStorage and other non cookie options seem just fine / safe.

I get the concerns about cookies and such but this seems a step beyond what is needed into the realm of unnecessary / a hassle for the user.

Maybe I'm missing some bad patterns / dark patterns using LocalStorage and etc but it seems to throw them out with the bathwater.


This is a valid argument.

Here is a fun idea that just came to me (trying to find middle ground here):

- Allow localStorage writes automatically, persist forever (choose your favorite definition for "forever").

- Allow localStorage reads automatically for 7 old.

- Prompt permission dialog if last read from localStorage is at least 7 days long.


I think that is reasonable ... maybe if the prompt is ... reasonable.

I'm kinda averse to the OMG COOKIES and other super technical warning type prompts that worry users, but really don't successfully educate them or direct them too good outcomes / choices. Granted education / good outcomes aren't easy tasks there, but what's the point of a prompt if the decision is made by an uneducated and just annoyed user?

I like the idea of empowering users, but not so sure about how we do it on the web / the best way to do it.


So i can start to manage save files on my disk? in 2020?? this is absurd.

apple should fix their safari bugs first before starting with this nonsense.


After the number of times my Firefox and Chromium profiles have been wiped clean due to browser or packaging bugs it's become clear to me that localStorage is not the end-all in terms of data persistence. It's always been a "best effort" rather than a guarantee.

Browsers offer a lot of useful functionality, but people increasingly expect them to be a replacement or substitute for an operating system, and in terms of being operating systems, they're all pretty lacking. Mozilla learned about this with Firefox OS (it was pretty cool though, RIP)


Well I've never lost anything other than the list of open tabs, and that's despite using alpha versions of firefox and chrome half the time. Cookies and localStorage aren't guaranteed but they're pretty reliable. I've had more trouble from native phone apps losing data than browsers on all platforms combined.

Not strictly disagreeing with you, but ChromeOS seems to be extremely healthy. Not familiar enough with Firefox OS to know why the disparity though.

Then that's just my ignorance - I've never used Chrome OS, though I was heartened to see they were migrating to standard PWAs instead of proprietary parts.

I worked with Firefox OS back when Mozilla was seeding dev kits to software companies. It was a great concept but really seemed marred by bad hardware and then organizational paralysis. IMO this is one of the greatest missed opportunities of the last decade - an (actually) FOSS alternative to Android and iOS. No one else making attempts in this space right now has close to the same engineering experience as Mozilla.

For Safari, Apple adding any PWA features came off as them rolling their eyes, sighing loudly and then putting out a half-assed attempt to deliver years-old standards. And rather than switch to a unified extension architecture like Chrome and Firefox (which they were very close to in previous versions), they've gutted extension support to the point where you need can only bundle very limited extensions with compiled MacOS apps distributed on the App Store.

I don't really understand what Apple is even playing at by offering features but not taking them seriously. But I just don't think the LSO expiry move is _that_ user hostile in the scheme of things.


>I don't have any idea about how mobile browsers behave for the scenarios stated above.

That's the problem, it won't work there. Apples support for PWA's is frustrating to say the least.

It's fair that you might need consent from the user before storing and keeping large amounts of data, but by removing the option you are forcing a bunch of developers to make a native app instead of a webapp which I find quite infuriating.


These are workarounds for a problem that shouldn't exist in the first place.

And for what? To save space? That's ridiculous.

> If anything died here, it is the implicit consent by the user for allowing unnoticed storage space consumption

What about explicit consent? It also dies. That's just inventing problems.


Implicit consent is lack of explicit consent so yes, apple fixed the problem by inventing another one. The thing is, this new problem of missing the explicit consent is easier to fix than going all in with the implicit approach. Not sure if Apple will follow though.

Dear lord, I hope you don't have any UX design responsibilies.

> Apple didn't kill offline web apps.

Yes, they did. For an app to work offline, you need to be able to at least cache the app itself. If that gets wiped after seven days, you can't call your app "offline capable".

> If anything died here, it is the implicit consent by the user for allowing unnoticed storage space consumption.

What about the "implicit consent" that bandwidth is being consumed?

> You can always add an interaction to your app which exports the stored data into a file which then can be saved by the user.

That would be awful. Imagine being prompted to import your data every time you launch it.

Maybe that sort of works with document-centric apps that have no persistent settings, but even then it wouldn't be possible to integrate properly into the file system in the way users would expect (file assocations).

> HTML5 games -> Prompt user with a dialog to download saves/assets after they play the game for a while.

More like constantly reminding the user that their valuable progress gets wiped after seven days, should they make the poor choice to run the app offline.

> Productivity apps -> Detect "ctrl/cmd + s" to prompt a save dialog. Add save buttons somewhere visible.

Same as above, except the data might be even more valuable.

> Apps/sites which use local storage for auth related artifacts -> Notify users if they click "Remember Me" and explain them the caveats.

"I'm sorry, we made a decision to write an app with technology that, in hindsight, we shouldn't have used. Therefore, your user experience will now be more annoying. Thanks for sticking with us while we're rewriting the app!"


Your response sound a little angry but maybe the tone is lost in the text so I will respond in good faith.

> I hope you don't have any UX design responsibilies.

I don't. We are safe. :)

> For an app to work offline, you need to be able to at least cache the app itself.

You can still do it, for a limited time. Your mission critical app will work offline if you are not planning to isolate your device from the internet forever. I know this doesn't solve the issue but I believe it is the lesser evil.

> What about the "implicit consent" that bandwidth is being consumed?

This always bugged me as well. This is unexplored territory for all browsers if I am not mistaken.

> Imagine being prompted to import your data every time you launch it.

I don't have to. I use draw.io excessively and it prompts me every single time. I actually appreciate the experience but I am a sample size of 1.

> More like constantly reminding the user that their valuable progress gets wiped after seven days, should they make the poor choice to run the app offline.

If it is valuable, maybe browser is not the best medium for it. Here, Apple's anti-consumer practice with its App Store becomes more relevant than Safari's localStorage algorithms.

> "I'm sorry, we made a decision to write an app with technology that, in hindsight, we shouldn't have used. Therefore, your user experience will now be more annoying. Thanks for choosing sticking with us while we're rewriting the app!"

"In order for 'Remember Me' to work as you expect, please visit us every once in while <3"


> If it is valuable, maybe browser is not the best medium for it.

Progressive web apps are not "the browser". It's a platform to ship apps using web technology that integrate into the operating system pretty like any other app, at least from the user's perspective. It works well enough on Android.

If you have to explain to your users all the caveats that such an app has on their platform, it just becomes pointless. If it becomes pointless on iOS, then it becomes pointless in general. You might as well go with a Web View app then.

Of course Apple has never been all that enthusiastic about PWAs, giving half-assed support at best. It was never a great platform to begin with, but now it's effectively dead in the water, at least for apps that are expected to work offline.


Doesn't make sense, just ask the permission to use the local storage to the user if that is the deal.

But that is not the deal, the deal is that they fear that more and more developers are moving to webapps instead of developing native apps that need to pass trough the App Store and thus be approved by Apple, and they don't like that.


Also you could sync data to an API and offer a login function. If the cookie expires, login and download your data again. This could be end-to-end encrypted for privacy, and having remote storage enables other clients to login and access the same data. Either way it's wise to have some kind of persistence option beyond just cookies and localStorage.

It's annoying how far Apple is behind Mozilla and Google when it comes to progressive web app functionality, but I don't think their action is as user-hostile as is being raised here.


It seems like the Storage Standard [1] could be combined with the writeable-files proposal [2] to permit the same sort of behavior for local files-on-disk webapps as mobile apps receive, where they can download large asset files and store them on disk in a persistent cache:

https://storage.spec.whatwg.org

https://wicg.github.io/native-file-system/


- Give user the option whether to enable "unlimited" storage on per-domain basis. There's already a standrad API for that.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: