5 ms·

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 al

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.

donatj 7y ago
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.
- joeblau 7y ago
  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.
  - donatj 7y ago
    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
  - gridlockd 7y ago
    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.
    - lstamour 7y ago
      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.
      - deleted 7y ago
        [deleted]
      - gridlockd 7y ago
        > 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.
- diegoperini 7y ago
  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.
- joshspankit 7y ago
  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?”
  - joshspankit 7y ago
    Downvote?
snemvalts 7y ago
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.
- henriquez 7y ago
  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)
  - davvolun 7y ago
    Not strictly disagreeing with you, but ChromeOS seems to be extremely healthy. Not familiar enough with Firefox OS to know why the disparity though.
    - henriquez 7y ago
      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.
henriquez 7y ago
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.
kristiandupont 7y ago
>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.
duxup 7y ago
>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.
- diegoperini 7y ago
  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.
  - duxup 7y ago
    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.
pier25 7y ago
These are workarounds for a problem that shouldn't exist in the first place.
alerighi 7y ago
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.
megous 7y ago
- Give user the option whether to enable "unlimited" storage on per-domain basis. There's already a standrad API for that.
aquadrop 7y ago
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.
- diegoperini 7y ago
  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.
floatingatoll 7y ago
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://storage.spec.whatwg.org https://wicg.github.io/native-file-system/ https://wicg.github.io/native-file-system/
gridlockd 7y ago
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!"
- diegoperini 7y ago
  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"

donatj 7y ago

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.

joeblau 7y ago
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.
- donatj 7y ago
  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
- gridlockd 7y ago
  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.
  - lstamour 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - gridlockd 7y ago
      > 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.
diegoperini 7y ago
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.
joshspankit 7y ago
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?”
- joshspankit 7y ago
  Downvote?

snemvalts 7y ago

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.

henriquez 7y ago
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)
- davvolun 7y ago
  Not strictly disagreeing with you, but ChromeOS seems to be extremely healthy. Not familiar enough with Firefox OS to know why the disparity though.
  - henriquez 7y ago
    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.

henriquez 7y ago

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.

kristiandupont 7y ago

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

duxup 7y ago

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

diegoperini 7y ago
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.
- duxup 7y ago
  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.

pier25 7y ago

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

alerighi 7y ago

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.

megous 7y ago

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

aquadrop 7y ago

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.

diegoperini 7y ago
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.

floatingatoll 7y ago

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://storage.spec.whatwg.org https://wicg.github.io/native-file-system/ https://wicg.github.io/native-file-system/

gridlockd 7y ago

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

diegoperini 7y ago
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"