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 s…
Private client-side-only PWAs are hard, but now Apple made them impossible
231–240 of 927 posts
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#232Offline Web Apps were already weak(i.e. CORS restrictions). Now they are even more useless with this storage limitation. You can't really blame Apple.. after all, Google claimed that offline web apps are nothing more than websites so that's what we have... I don't mind if Safari deletes offline data stored by websites every week so why would I complain about "offline apps" ? My point is that Offline Web Apps (i.e. PW…
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#233I’m guessing that Apple will start hindering web apps because the new mouse support in iPadOS is going to be such a boon to web apps. Because of sandboxing, web apps are the only cross-platform apps that can run in their full versions on iPadOS. I wrote a quick summary of the situation[0]. Therefore, since native apps are more of a platform differentiator than web apps, moving forward we can expect Apple to start sys…
If this were true, how would you explain the recent improvements to Safari on the iPad that make it as capable as desktop Safari. Until last year Google Docs did not work in Safari on the iPad. Now it works very well indeed. The same is true of most web apps.
So now that web apps have the advantage, at least when a keyboard and mouse are attached to the iPad, Apple is going to be seeking to tip the scales back in native apps favor.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#234Earlier quoted context omitted.
So it's not about what's best for the user but what's best for Apple? I wouldn't call that "understandable". All this is doing is contributing to webkit monoculture.
There's some irony that Apple forcing the use of Safari on iOS is creating a monoculture when, were the restriction lifted, everyone would be using Chrome.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#235Earlier quoted context omitted.
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.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#236It does seem that Apple intends to cripple web technologies in order to move developers to their native platform but this will likely do more damage to privacy than anything. All of the alternatives to local storage for simple mobile apps typically involve moving data to a third parties like Firebase, AWS, etc.
Simple apps that didn't need a server and could just keep data or user-preferences locally would now need to either create their own data service or pay for a BaaS which means moving your data out of your control.
This behavior leads to companies like Under Armour to house data they shouldn't have and puts everyone (150M people) at risk.[0]
[0] https://www.wired.com/story/under-armour-myfitnesspal-hack-p...
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#237I don't understand why the title was changed - the focus of the article isn't just on the fact that WebKit is changing how it handles local storage, but also a criticism of Apple's motivations for this decision.
edit: 17 minutes after posting this comment critical of moderation, I am unable to submit a new story. Coincidence?
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#238Our company has started shaming iOS. We tell users that because of a commercial policy aiming to increase their revenue from their App Store, iPhones and Ipads "do not support the Web 2.0 technology enabling powerful experiences for web sites and web applications, while Android and Windows devices have been supporting this technology since 201x". We briefly explain in one sentence that it would not be the best use of…
Sounds extremely condescending and off-putting. I'd be annoyed if a company said this to me. There is a lot to love about Apple products outside of a few safari restrictions. They're not perfect but better than a lot of alternatives.
Why isn't our product taking off?!
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#239What we really need is a way for users to store their own data that has the simplicity of local storage but the convenience of storing data in the cloud. It does seem that Apple intends to cripple web technologies in order to move developers to their native platform but this will likely do more damage to privacy than anything. All of the alternatives to local storage for simple mobile apps typically involve moving da…
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#240I 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 s…
> 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!"