If there is evidence of the veracity of this claim, this topic deserves a whole lot more attention. Especially considering Apple's stance on 3rd party mobile web browser engines - Apple forbids them, although EU regulation may force this to change.
I searched a bit and found no smoking gun, the closest hit was:
https://old.reddit.com/r/Safari/comments/185cra6/safari_nuki...
But it seems more likely caused by legitimate bugs than any intentional campaign.
Have I been nerdsniped here by a nutter? :-s
I would absolutely make this claim.
This isn't even a PWA thing. We had a really simple series of boring web forms that suffered from this. The first iteration of this had the server swap an initial tokenized link for a cookie when clicked.
After some feedback from our customers, we discovered that iOS users were having a lot of trouble getting all the way through the desired workflow. We were able to replicate this on our iOS devices but it seemed completely arbitrary.
After abandoning cookies in favor of maintaining a tokenized URL, we found we were getting 100% success rate for iOS end users.
My theory is there is a malicious bit of code in iOS Safari that is applying some insane cookie policy over "unpopular" domains.
You essentially have to build your app from zero with these limitations in mind if you want any chance at getting around them.
This is a large part of why I am not a fan of frameworks and other popular design patterns. Having total control over how state is managed and communicated is really important if you don't want to get trapped in various tar pits.
> Warning! The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
https://html.spec.whatwg.org/multipage/webstorage.html#intro...
https://webkit.org/tracking-prevention/#intelligent-tracking... "Home Screen Web Application Domain Exempt From ITP". This is 100% bullshit though.
My personal belief is that Apple is purposefully nuking PWAs from orbit in a non-deterministic and "buggy" way because they are a threat to the app store business model, and I suspect if they frustrate enough developers, people will stay away from PWAs.
Cross-platform webapps should be table stakes for adopting any platform.
This is true even if you use Google's own tool to wrap your PWA and put it in the Play Store, and even if you use the so-called "persistent storage API" to have users request their data not be deleted - still get random data loss, and it makes it very hard to maintain a 4+ star rating when there are a bunch of 1 star reviews about users losing all their data.
I realize I'm a bit of an edge case. But also, ideally we could make PWAs that operate with similar data guarantees as native apps. That's kind of the idea of PWAs, that web apps should be able to mostly be the equivalent of native apps.
And it almost works, except for the data loss issue. Kind of sad. Cause there are so many other advantages of a PWA... like being able to target all platforms with one PWA is incredible. Having no gatekeepers to "approve" my app updates is incredible. But the cost is sometimes users lose all their data :)
But on the plus side, random deletions also happen on Android!