I found this most disconcerting. It was already a complete annoyance that IOS would remove app data (localStorage, etc.) if the device memory was low and the app was not very active. Now in 7 days the data is gone. This means you’ll have to reload the app data from the server when you find all the data has been removed. But how do you get to the server securely, now that your secure key storage was erased (assuming you stored the userid/password/authentication on the device). The user will have to reenter these if they don’t use the app at least once a week.
The story also eludes to making the web app a desktop shortcut, which, for the moment, evades the 7 day rule, but is under some other deletion rule not mentioned in the article. Assuming this option works, then it will be my choice on Apple devices to TELL the user about how stupid I think Apple is with this particular decision and that if they don’t want to reenter their userid password every week, to please say yes to making this app a shortcut.
Finally, a better solution to the problem Apple was trying to fix: If you look at any device you’ll see tons of localstorage that is really ad tracking data. If Apple gave us a way to indicate what type of data, and how long we would like the data to persist, it would provide a much better way of managing memory, rather than deciding all 3rd party vendor data is bad. Police the apps. Let the users do the policing.
Android doesn’t handle the lack of memory well and the devices do freeze up when full. An Apple device won’t be subject to this lack of memory and will always perform. Of course, you now know the costs to get such performance, or lack thereof.
We’re watching this situation closely, of course. A lot is still unknown. If you want to see some more discussion, check out this thread:
Are PWAs affected?
" As mentioned, the seven-day cap on script-writable storage is gated on “after seven days of Safari use without user interaction on the site.” That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted. If your web application does experience website data deletion, please let us know since we would consider it a serious bug. It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.
Just so anyone following this knows, this extends to Cordova and Phonegap Build apps as well.
Mind you, I’m all for ending tracking. I’m all for disallowing 3rd party cookies. However this solution doesn’t even address the real problems which are all those facebook, twitter and other scripts embedded in these sites that you never see. Plus, every time you use google, facebook, twitter etc as a shortcut to logon to a website, google, facebook, twitter etc get your data. Apple’s solution, while a step in the right direction, doesn’t solve the problem… it just creates new problems.
I can just imagine someone trying to send a life saving alert and getting hit with a login screen. [insert eye roll here] A few months ago I rewrote all my SQLite code to innoDB and now I have to back port to the SQLite plugin.