Private client-side-only PWAs are hard, but now Apple made them impossible | Hacker News Reader

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

963 pointssoapdog896 comments

The source clarifies that this only applies to websites run within the Safari browser.[1] PWAs added to the home screen aren't 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.

[1] https://webkit.org/blog/10218/full-third-party-cookie-blocki...

That's a relief. We've built our business on our PWA, which also has an offline mode. It would be annoying if we had to adjust it for (yet another) Safari quirk.

Except that by "Safari quirk" you mean "the way that all common browsers are heading".

Safari is the first here. Firefox is certain to be right behind them. Google, probably not, but I bet Edge does the same thing before too long.

I hope not. Apple has had substandard support for modern web technologies in Safari for a long time, to the point where it is often referred to in the industry as the new IE. We've had enough of browsers breaking things that used to work in the name of false progress. Time for the grown-ups to take a careful look and see this for what it is.

Here’s my take on what it is: the most battery-efficient browser. I’ll take 30 more minutes on my laptop before some nebulous modern web standard.

How does something like allowing data to be stored by a web app that isn't even being used for more than a week cause your laptop to lose 30 minutes of battery life?

It doesn't as the two have no connections whatsoever. The point was that Safari is the most battery efficient browser overall on MacOS, so they're willing to put up with sub-standard support for web standards if their battery lasts longer.

I'm sure it will be a great comfort of them to not be able to use their computer for useful things for a bit longer before they have to plug it in. :-)

Would you also take gradually losing access to other modern web standards apps rely on as time goes on until the only realistic option we have for building, deploying, and consuming apps are the walled gardens controlled by 2 corporations who have arbitrary rules on who can and can't participate, freely stifling innovation/competition as their interests dictate, and taking a more and more outrageous cut of all economic activity on the platform?

That's where this is going.

> "first they came for localStorage and I did nothing"

As an end user, I love it. I regret that it's making some things harder for legitimate developers, but love that it's making it harder for the assholes who keep trying to ruin the web.

You realize that custom, new, cutting-edge APIs (can you imagine the web without xhr?) was what made IE into the IE we talk about. Some they got right, some they got wrong, some were way too tied into IE’s parent’s ecosystem (sound familiar, AMP?). It’s once it stopped getting updated that it became a problem, as no one else had or planned to have some of its stuff, resulting in it being an oddball. Chrome fits the first half of that profile far more than any other browser these days, it’s just that WHATWG being a “living standard” has enabled it to “standardize” any new idea that comes along (other browsers do this too, but not nearly as much as Chrome).

The point is that slowness to adopt new standards wasn’t exactly what made IE into the the IE we all hated; it was going off on tangents without consulting anybody too often that left it out on an island with custom versions of so many things. Fortunately it doesn’t seem like Google is going to lose interest on Chrome anytime soon.

It's not only custom cutting-edge APIs, there's a lot of common stuff which is broken in Safari, that's also why it's referred as the new IE. I personally had issues with forms, clicks, svgs, selects... It's really broken in many ways.

Chrome is the new IE in the embrace-and-extend sense (the early IE that won the browser war).

Safari is the new IE in the stagnating, not supporting new functionality, not fixing long-standing bugs sense (that same early IE several years later).

Neither of these is a good thing or to be encouraged.

Please don't get me started on the oxymoron that is "living standards". I think that idea is responsible for a great deal of what has gone wrong with the web ecosystem in recent years.

Google is planning on implementing part of this in 2022[1]. Not sure what they are going to do about the browser storage though.

[1] - https://www.theverge.com/2020/1/14/21064698/google-third-par...

That article mentions third party cookies. Nothing about nerfing localStorage.

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

What exactly does that mean? So you use the app for seven (perhaps non-consecutive) days, and now all third parties that haven't been, uh, interacted with, get their data wiped - but not the the first party, because that has been interacted with, by virtue of the PWA being launched in the first place?

I guess that solves the problem?

Thank you for the clarification.

I don't think that's actually what it clarifies. Or at the very least it's very confusing.

> have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer.

This makes it sound very much like homescreen apps will have their data wiped after 7 days of non-use.

> We do not expect the first-party in such a web application to have its website data deleted.

And this does not. It's a very confusing word salad.

Yes, it's confusing.

It's not 7 days of non-use, it's seven days of application use without visiting the site.

Safari is one application, the homescreen app is a separate application. Presumably, all the alt browsers or WebView apps are separate applications as well.

Since you can't use a homescreen app without visiting the site, the 7 days of not visiting the site can't happen.

Ah OK that makes sense. They should really copy and paste what you just said into their post!

But .. if you don't use Safari for seven days, what happens?

From their description, nothing. Seven days of use without visiting triggers deletion. Failing to satisfy either of those conditions (either by disuse of Safari, or by visiting the site within seven days) doesn't.

So this is a requirement that all webapps phone home, moreover that they have a home to phone?

No, this is all internal to the browser, no requirement to send a remote request.

It’s a requirement that some time within the next seven days of app usage, the user interacts with the web app.

This might cause trouble if the web app is simply a list of timers which the user interacts with passively (map of earth showing day/night zones), but if there is any interaction at all the timer resets.

I'm not getting the semantics clear but wonder whether having the icon on the homescreen counts as "visiting" or whether suspending the app first day and reopening it the next day counts app-subjectively as "continuing day one" or "reopening immediately"

will it be "7 days of non-use" for regular websites that use localStorage?

You can't really have "seven days of application use without visiting the site".

For "regular websites" (visited through Safari) it's 7 days where you use Safari, but don't visit the site. So if you go on vacation for a month and don't touch your computer, or if you switch completely to using Firefox for a month, localStorage will remain untouched.

Where is this explained?

https://news.ycombinator.com/item?id=22681370

Hmm no mention about "regular websites" there...

I fail to see why you need to see a mention of "regular websites". The comment clarifies the situation of what occurs if a user goes on vacation or switches to another browser: nothing will be deleted, as Safari is not being used.

What if you visit a link within the home screen app that takes you to another domain? Presumably if you kept using it with ever returning to the original domain the clock would be ticking.

Suffice to say that the author of this blog post should have spent less time congratulating themselves and more time clearly explaining the impact of this change, to avoid scaring off developers and users.

Home screen web app data will be deleted onlY be deleted after 7 days of active use of that web app without any user interaction, which is nearly impossible. So the whole premise of the OP is false.

A clearer explanation has now been delivered by Safari’s evangelist: https://twitter.com/jonathandavis/status/1243228885006708737

Data isn’t deleted after 7 days for home screen web apps.

Jesus christ.

It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app.

I can't _wait_ to deploy an application where there is literally an "rm -rf" pointed at my users data, with a complex conditional blocking it. That makes it far to easy for a webview bug to nuke my users data.

This is shoddy engineering. Could you imagine a filesystem being implemented the same way? You would never include a code path in your "mount" logic the says "if ( some condition ) delete everything;" that would rightfully be viewed as a terrible idea and a disaster just waiting to happen.

I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are deleted. (It is possible for at least Android apps to write data to other places like the SD card, but that is a totally different story imo.)

Honestly, if my data really matters, I don’t want it to be stored only in a single place. I can get the argument of wanting to have federated syncing, that would give the user freedom to choose where data syncs or doesn’t. But in my opinion you either care about the data or you don’t. Any data stored locally anywhere should be considered lost until proven otherwise. Like, drop your phone in a sewer, leave it in the wash accidentally, have it stolen, or even just have a different software bug obliterate your data and it’s gone. That’s the definition of fragility.

This mechanism failing is mostly theoretical, but having ones phone break is not; I would guess those of us who have been using smartphones for 10+ years have, by and large, all experienced data loss when storing data with no backup.

To relate to your statement, can you imagine if your data on Dropbox was stored on one harddrive, in one server, in one datacenter? Servers fail constantly. You can of course do whatever you want to improve reliability but without redundancy you are very much pissing in the wind.

On the note of “localStorage is temporary,” nothing in the spec defines how long localStorage persists, just that it is not bound to the session. In fact though, Safari already deletes localStorage when disk space is running low.

I am very much an advocate for folks being able to control their own data. I personally self host a lot and use a Synology NAS as my own backup for most things. But I think Safari would be wasting time to disable the counter entirely for PWAs. It doesn’t meaningfully change the likelihood that users will lose data. I think users often do want strong durability and privacy, and an API that n apps from needing to implement many remotes would be way more impactful. I’d love to tell an arbitrary notes app, “Go backup to this Synology NAS” without it needing to specifically support Synology NASes or for example, WebDAV. Put the provider on the clientside and you have a place to implement end-to-end encryption.

(Of course, Apple has iCloud backup, but I don’t think that covers your localStorage content anyways.)

> Honestly, if my data really matters, I don’t want it to be stored only in a single place.

That's all well and good except when you lose your emails that your wrote on the plane and didn't get a chance to send yet.

I'm not arguing that you should _never_ synchronize the data off the phone, but where I store data on my phone should be as robust as possible. So far I have never had my phone delete an application I had installed, but my browser loses local storage, cache, cookies, all the time. It is just not a robust storage location, and this new safari behaviour makes me trust it even less.

As a result, the web is continuously behind native apps for offline or semi-offline operation. There's no reason for that other than the shoddy engineering going in to web browsers, such as this recent addition to safari.

Web apps are unreliable for sure, but I think that is where PWAs should come in. The problem is there’s just not a ton of them today, and parity just isn’t there. That having been said, I’ve never lost local storage on a PWA in any OS so far...

Also I am not saying programs and browsers should not make a best effort to reliably persist data locally... just that robust local storage only really needs to be so robust, because any more robust and you might be fooled into relying on it.

I've lost localStorage on PWAs before. But that was a number of years ago when I was still bothering to develop them. I also lost data in appcache repeatedly, then service workers came along to fix that, because the browser vendors' strategy for broken implementations is to deprecate them with an even more complex standard that they will never finish. Then they can close your bugs against the old standard that they never finished implementing as WONTFIX and everyone gets a promotion for shipping.

If there is, as they say, a dedicated counter on those home screen applications, what is the threshold? Will home page PWA apps not used often (say, for infrequent uses like travel) have first party data deleted after the icon isn’t clicked for some time? This is highly unclear and confusing.

The deletion occurs if you use the app for seven days and don't visit the site. Pinned sites cannot meet those criteria and will not trigger deletion.

How about pinned sites that have not been accessed for > 7 days? I neither use the app nor visited the site for e.g. 2 weeks.. what will happen to e data for e pinned site? Apple is being vague here.

One of the criteria for deletion is accessing the app for 7 days. If you don't access the app for 7 days, it doesn't meet the criteria and won't trigger deletion. It's poorly worded, but it's not vague.

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

But said timer... does nothing? Why does it exist?

I suppose it would still affect any sites you visit from within the PWA, for example through an iframe.

Also, it's simpler to have a timer that effectively does nothing than having extra logic to suppress it.

Presumably because WebView is available to other applications besides Safari and pinned sites, and they want to offer the same privacy guarantees to users for WebViews in apps as for Safari. Adding an exception for pinned apps is unnecessary because it's impossible to meet the criteria for deletion.

Ok but OTOH Apple is not helping PWAs by hiding the "Add to home screen" in submenus and not having an official API to show a banner like Chrome has on Android.

Edit:

Also what about desktop?

Not having a way for web apps to communicate a call to action dramatically reduces engagement with this feature, no doubt. The only way I can see this from Apple's side is they see it as a feature for Safari users, not from the platform side for the web.

From Apple's standpoint, when you put yourself on the user's homescreen, that is a deep connection between that app and the user. Apple spends billions in each finding new ways to enhance and enrich that connection. IMO, their _belief_ is that building a native app to take advantage of all these rich and engaging ways is the best way to build deep connections with your (developer's) users.

Being an icon on the user's home screen is where deep connection begins, not ends. You might add a today widget, you might want to send notifications, you might want to add AR experiences. You might want a Tablet experience and allow hand off between these devices. Apple is invested in becoming a deep level of importance in a user's life. They want to share as large of surface area with 3rd party developers as they can. It would be irresponsible to promote an API that made developers have to start from scratch when they decide they want to go deeper.

As the article has been updated to say, "installing" a PWA to the home screen is an optional step that many people prefer not to do in favor of bookmarks or the address bar or the new tab page or whatever.

But it's no surprise that Apple would want to impose an "install" step on the web to prevent it from looking more attractive than the App Store.

> But it's no surprise that Apple would want to impose an "install" step on the web

The FUD here is getting out of control. "PWAs", that Google pioneered, are all about having an ‘install step’ to put the "web apps" on your home screen. https://web.dev/customize-install/

No, they are about safely adding capabilities to the web that native apps have. Home screen icons are only one of those capabilities, and not the most important.

PWA is in fact a corporate born, bred and sponsored definition created to push and promote an _arbitrary_ set of Chrome features. It was an attempt to build momentum towards a vision for the web where browsers can run "open" apps. Unfortunately visions don't die, and thus the term lives on. Sigh.

It is no surprise because the whole point of keeping storage around is because you intend to come back. Pinning a website to a homescreen is clear intent. Having a tab or a bookmark does not make that clear. I have tabs and bookmarks open that I haven't visited in years. Thankfully Safari now kills tabs that haven't been touched within X time frame.

"impose" is the wrong word. I think you mean they are "trying to understand you and do the best thing"

Good luck getting your app added to the home screen. It only works through safari, so chrome or firefox users are ruled out, and it's hidden under some "bookmark" or "share" menu that is too difficult to discover.

Safari is the only browser on iOS because Firefox and Chrome are forced to use the Safari engine due to "security reasons".

The issue is that if you're using the Firefox or Chrome apps (which are the same rendering engine underneath), they aren't allowed to implement the "add to home screen" action in their UI.

I ported Polar (https://getpolarized.io/) over to a PWA about a year ago.

It's kind of a nightmare due to both Google and Apple messing things up.

PWAs could be an amazing platform but both companies are really messing it up.

Apple is trying to kill them by giving plausible explanations as to why they can't have PWAs. Security this, blah blah blah. There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.

Google's problem is, well, they're Google. Meaning things are somewhat incoherent, docs are all over the place, they start new initiatives then abandon them half way, etc.

Consumers are another problem. They have no understanding of PWAs and they go to the app store, don't find us, and then complain we don't have an app..

The plan now is to use Google TWAs and port our PWA to Android.

We're going to do the same thing to Apple after we do the Android release BUT I think there's a 50% chance that apple will just flat out block us.

I think we might have a chance of getting around it if we use mobile gestures properly, use platform specific APIs like the camera, audio, and GPS that aren't on web and try to really integrate into the platform properly.

For example, they have an API to detect dark mode now. IF that's on we're just going to magically enable our dark mode in our app.

> There's no reason they can't have PWAs work well in Safari other than they want you to port your app to the App Store and get locked into their native APIs.

Is it possible they also want you to port your app to the App Store to prevent an explosion of garbage and malware that could happen if PWAs really took off?

> to prevent an explosion of garbage and malware that could happen if PWAs really took off?

You mean, like the Internet. The App Store is a nice, safe walled garden, like AOL.

This is one of the primary value props of the platform.

Value to whom?

To me, as a user of the device. Native apps can be a joy to use, websites almost never are.

Sure, but this is usually because of UX reasons and less because of performance or capabilities

And is anti-competitive and gives Apple and Google too much power over a device I own.

I seriously doubt that. It's a lot more difficult to do horrible things with PWAs than it is with native apps. Apple has a history of doing everything they can to keep people inside their walled garden and this is just another instance of that.

There is absolutely no reason that PWAs can't be sandboxed like native apps, or even more aggressively. In fact, native apps are more likely to be spyware, as they can collect much more information from the user than a browser-based app can.

Native apps ostensibly go through review so that Apple can flag malfeasant behavior that is nonetheless allowed by the sandbox. Think things like a $999 purchase request that pops up on app launch (Yes, I know Apple isn’t that great at this. But that’s the argument that they use for review.)

It's not a good argument because I can find Bonzai Buddy-like apps on the Mac App Store, and they ban any GPL apps on their iPhone App Store.

GPL apps are not banned on the iPhone App Store.

Yes, they are[1]. The GPL is incompatible with the App Store terms and if Apple is aware that an app uses GPL software, they will reject or remove it from the App Store.

[1] https://www.zdnet.com/article/no-gpl-apps-for-apples-app-sto...

That link is from 2011, and the referenced verbiage is nowhere to be found in the App Store terms. I believe that the current terms leave the App Store open to GPL software. Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.

> I believe that the current terms leave the App Store open to GPL software

Please read the following:

https://github.com/nextcloud/ios/blob/master/COPYING.iOS

https://news.ycombinator.com/item?id=12827624

https://www.fsf.org/blogs/licensing/more-about-the-app-store...

> Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.

Developers of GPL software have had different experiences with Apple than what you're asserting. There is a direct incentive for Apple to police licensing incompatibilities if they are profiting from illegal distribution of GPL software on their platform.

> https://github.com/nextcloud/ios/blob/master/COPYING.iOS

I tend to think of this as reaction to GPL FUD; I know some people who have these so they never have to actually figure out the answer to this question.

> https://news.ycombinator.com/item?id=12827624

I have argued that a close reading of the TOS currently seems to allow GPL: https://news.ycombinator.com/item?id=21943994

> https://www.fsf.org/blogs/licensing/more-about-the-app-store...

Again, this is super old. Do you have anything newer?

Hi there, I'm the product manager for PWAs on the Chrome team.

Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t

Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recently (https://web.dev/progressive-web-apps). Consolidating and adding docs is an active area of investment, and our goal is to create a well lit path for developers to succeed with PWAs.

More background services would be very nice even though it's a bit of a security nightmare. A request was opened almost 5 years ago for background geolocation services.

Any plans for https://developers.google.com/nearby ?

I don't want Google or central authorities to decide which PWAs are "trustworthy" directly to ask for certain permissions but there could be a way or compromise. I don't remember which feature it was but it required yes from Google.

I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them. It should be mandatory and important or may show a default screen with permissions and few dangerous ways they can be used for.

"I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them."

Wouldn't it make more sense, to display this info before you install a pwa?

Oh, yeah before. Though, I think it should also show that screen if a user hasn't used the app for a while.

Background geo, including geofencing is challenging, but there may be a way forward. We're exploring this conceptually, but it's not in the plan for 2020. I'd certainly like to be able to improve the capabilities of web based ride sharing and similar apps that have a need for this.

Bluetooth discovery is an especially thorny area from a privacy perspective. What use cases did you have in mind?

Asking for permissions upfront has been found to be an anti-pattern in systems UXR. Research has found that users make better decisions and find the experience less interruptive when permissions are requested in context at runtime. For example, in a video chat app, it's better to ask for the camera/mic permission at the start of the first chat session, not when the app first starts. Mac OS, Android etc. and other platforms have all been moving in this direction over the past few years.

When the permission is requested, we're investigating ways that we can do more to communicate permission risks to the user. Nothing publicly shareable yet, but do expect experiments to be showing up in dev channels over the next few months while we try new things.

Well, it would have been helpful to provide a simple example of a working pwa.

The example at

https://codelabs.developers.google.com/codelabs/your-first-p...

was way too complicated as a first example, if all I wanted to know was how to make my app installable and is also broken as it uses some outdated tools. (don't remember the details)

Also, it could have been mentioned somewhere, that when you serve from localhost, you do not need SSL to install it. Knowing that, would have saved me the trouble of messing with apaches config and certificates.

So that was very frustrating as a start.

Much more helpful was a very simple hello world pwa which was barely installable. But it worked. And from there it was easy.

https://medium.com/james-johnson/a-simple-progressive-web-ap...

Thanks for the feedback! This is now the reference "first PWA" example: https://web.dev/codelab-make-installable. Let me know if you find it easier for new devs to get started with. The other codelab and a lot of other scattered content will be removed once we finish the migration to web.dev.

Please consider contributing to MDN. It's the best source for web development and it would be great to keep everything there, properly cross-referenced, etc.

Heh, you're asking a googler who's basically responsible for some of the actions Google is taking with Chrome, trying to make the web only browseable via Chrome and centralizing information under their own Google brand, to contribute to a cross-company/community effort (Mozilla + Microsoft + open source hackers)? While noble, I can only wish you good luck.

I think the sail has long sailed for asking Chrome/Google to help out with the openness/sharing on the web/internet. It's time we just start ignoring them instead.

Just want to note that you specifically mentioned Microsoft working with open source hackers in this comment saying that the ship has long since sailed on Chrome/Google contributing to the open web.

I don't know, never say never I guess. I'm certainly not going to defend Google's track record on openness and privacy -- there have been, under even the most generous of interpretations, huge missteps, and I don't think they deserve the benefit of the doubt -- but they do contribute. Edge backed by Chromium?

I was thinking about a particular announcement where Mozilla announcing that they are working with Microsoft on MDN.

Color me surprised when I discovered that also Google is mentioned there! Here is the announcement: https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

Reading that announcement makes b1tr0t's statement "We've started to consolidate docs under web.dev" even worse, as they previously said they are gonna contribute to MDN, but now they have turned and use their own shit anyways.

Screw you Google.

Our team actively contributes to MDN. Web.dev is not an MDN replacement, it's a channel for guides & other supporting documentation.

Just so understand correctly, you're contributing reference documentation to MDN but then everything else goes into web.dev? Why not contribute the "guides and other supporting documentation" to MDN as well?

As I understand, the Product Advisory Board for MDN was created with Mozilla + others in order to combat the fragmentation of information, but your actions seems to do the opposite.

Don't they already do that? They are part of the MDN Product Advisory Board since 2017.

Blog post of the announcement: https://blog.chromium.org/2017/10/building-unified-documenta...

The statement from b1tr0t directly refute that Google is contributing to MDN, as they put it: "Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev". As far as I know, web.dev is not MDN and has nothing to do with MDN.

Mentioned in another comment, but to be clear, our team contributes to MDN, and will continue to do so.

Web.dev is not an MDN replacement.

As another user mentioned, we do contribute to MDN. MDN is where we point devs for reference documentation. web.dev is for guides, how to's and other support docs.

> ... Consumers are another problem. ...

You blame Apple, Google and your consumers, instead of just making native apps. Why?

Yep. Just because "PWA"-geek niche at HN wants to go back to shitty UX from 2004 it doesn't mean all tech companies or consumers want to.

I hope Apple keeps restricting this in the future too so that iOS app ecosystem won't turn in to a turkish fruit market full of crap like Android.

You’re getting downvoted, but I agree. Enough with shitty UX’s already!

So, make 3 apps instead of 1? This was the whole idea behind PWA.

Yes, that's the whole idea behind having different devices and operating systems with different capabilities.

Why should users suffer the lowest common denominator because of lazy developers?

The lowest common denominator is not having the application available on your platform at all.

I'd rather them not have the resources to get an app working on my platform, then have enough resources to _barely_ get an app working on my platform.

I wouldn't attribute it to laziness. Quality can really suffer when you need to maintain so many code bases. Not all teams have those kinds of resources.

Perhaps Electron/PWA should be seen as a last resort, not the norm, reserved for exactly such a situation: when you don’t have the resources to build native for all platforms.

It makes it a lot harder for solo developers or small companies to develop apps that work on all platforms

Why should customers pay for the development and maintenance of three apps when one is entirely sufficient for their needs?

"just making native apps"

Hiring aside, it’s probably simpler than attempting to reconcile souped up document viewers with contemporary expectations of “apps”, iOS and Android being purposefully built for the task and all.

Having done native Android/iOS and web dev, web dev is much easier than Android and at least on par/if not easier than iOS.

There's a bunch of very complex web/electron apps that disprove the idea that the web is only for static documentation and web-inspired ideas are coming to mobile (React --> Jetpack Compose/Swift UI).

More importantly, hiring can't be put aside, and it's much easier to adapt your web app to work for mobile (since websites should be screen size agnostic anyway) than it is to build a fully native app from scratch.

As an iOS and Android developer myself, this doesn't effect me but I still think Apple and Google making things harder for PWA is bad because Apple and Google are the gate keepers for what goes on their native app stores. I can cut some slack for Google as they at least allow third party app stores but Apple doesn't.

Either Apple should stop being the gate keeper or stop making life harder for web devs.

Maybe Apple could offer a compromise and allow users to sideload apps, but restrict non-App Store apps from accessing the file system or any kind of personal identification (like location etc.)

And improve their documentation to lower the barriers to native development.

Makes sense, they want you to create native apps so they can collect their rent, and also dictate what is in, what is out, and control searching of apps.

I tried using your app on an iPhone (with Add to Home Screen).

- If I press the settings gear, the text on the settings page is about twice as wide as the screen, requiring horizontal scrolling.

- On the front page, if I open the color picker, it's partially offscreen.

- On all pages, if I do a scroll gesture in the wrong direction, it scrolls the entire UI rather than just the scrollable part. Admittedly, iOS has long made this hard to avoid without hacky JavaScript, but it's been doable, and it's much easier now [1].

- The hamburger button on the left opens a modal view that covers all of the screen but a small margin on the right, making it unreasonably hard to exit.

- If I try to create a tag or folder, the name prompt appears under the other modal view and is improperly sized.

- Oh, and the UI looks thoroughly non-native, e.g. Google-style floating action button, UI not covering the status bar, bottom tab buttons too short, etc. The animations are also haphazard.

My point is not just to nitpick. It's just that while I sympathize with the idea of PWAs in principle, almost every single time I see someone talk about theirs, the PWA in question has immediately obvious glaring UI defects that have nothing to do with browser limitations, and leave it far below the standard of a good native app, or even a bad one. I honestly don't know why this is, but experiencing it over and over makes it hard for me to care about PWAs.

[1] https://benfrain.com/preventing-body-scroll-for-modals-in-io...

There are some fantastic PWAs out there. Twitter is the one I use most regularly.

I think one of the reasons we see a lot of less-polished PWAs is that the idea of the PWA appeals to businesses at certain stages. Larger shops can afford to ship native binaries to more than one platform, but a smaller operation can't. PWAs are presumably tempting to those types of product teams: you get multi-platform reach while truly only writing for the web. The fact that their UIs have rough edges are probably a result of having an MVP-stage product.

Writing for the web and trying to be consistent with native UI is a nightmare. It is not about MVP-stage or not, it is simply not worth it.

There's no rule that says that an app UI must be consistent with native app conventions.

Is Twitter really a PWA or just a nicely done responsive website? At this point the boundary is a unclear.

Beside Twitter rely on server side storage and pretty much only store session token in the PWA "local storage" (largely speaking).

And as a user I rather installed iOS native App to keep finer grained control on permissions. (I also use multi accounts not sure the PWA Handel that?)

This highlights a longstanding issue of PWA definition and how to position it against modern web practices and features. What is a PWA? Why is it even a thing?

It is absolutely a PWA, and an excellent one at that. You can add it to your home screen on the desktop and mobile platforms that support it; they have all the trappings of a native application including notifications support, background refresh, etc.

Twitter's "PWA" is crap. It has an unending stream of glaring UX/UI errors that only get worse over time.

I'm just gonna link to a small subset of failures we've documented: https://www.google.se/search?q=twitter+site:grumpy.website

Why enclose PWA in quotes? Just curious. I use Twitter's PWA weekly on more than one platform and it works great for me, but that's just one person's opinion. I prefer it over their native clients for a lot of reasons, but the main value-add is that I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.

> Why enclose PWA in quotes?

It's twitter's mobile site that they extended to cover both desktop and PWA. As a result, it's quite bad on all fronts and judging by the number of bugs that are lingering with no fixes, abandoned. At least they managed to almost fix the epileptic scroll position [1]

> I don't have to give Twitter access to detailed information about my system while still using a full-featured, first-party client.

Yes, this is, without a doubt, the best value-proposition of PWAs.

[1] https://grumpy.website/post/0RQvmdNmN

Are you sure that's not a catch-22? The reason you've not seen any good PWAs is because the ecosystem doesn't exist for making good PWAs, which doesn't exist because there aren't any good PWAs. Any sane technologist is going to look at the shortcomings of PWAs, and choose a different technology to build their app. Choose boring technology[0], and unless your product is a PWA toolkit, the app UI library isn't the place to get creative.

The single issue with PWAs, on iOS, is how do I add a PWA app to the home screen? I go to the app store and search... and your app isn't there. As developers we innately understand why that's so, but our users don't and shouldn't need to understand the difference.

[0] https://mcfunley.com/choose-boring-technology

Regarding your point on consumers, we put our PWA/TWA into the app store (for the reason you outlined) - and now get a raft of negative reviews that the TWA is the same as the mobile site... Which is frustrating, because that's the point.

Making it clear why a TWA is in the app store is hard in itself. Trying to explain why it's better for consumers over a native app + mobile site is even harder.

See these reviews for yourself here: https://play.google.com/store/apps/details?id=uk.co.openrent

> Consumers are another problem. They have no understanding of PWAs...

Really? You're blaming your customers for not being sufficiently tech savvy and not wanting what you're providing?

Personally, I am happy with Apple's decision here.

I really appreciate this link. I would have never seen this otherwise. It's kind of a disappointment for us on the enterprise side. Our main offering is an offline app where people are disconnected from the internet for weeks and we use localStorage to validate who they are. It's a bit vague about how this affects apps that don't use safari. Nevertheless, we might have to start to really think about the user experience here now that this update is out.

Webkit's website says: "[..] deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site."

It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.

Yea, we actually don't use safari at all in our app. So this might not have an effect but it's pretty vague.

If you don't use Safari you can patch webkit to change the policy, right? Change 7 to 10000000

Apple only allows apps to use their webkit implementation.

Even for other browsers. Chrome, Edge, Opera etc. on iOS all use webkit under the hood.

You could...but it's a change that the Webkit project would never accept and you would be forever diddling this value every time an update came along.

Sisyphus says 'Hi!'

User not coming to website 7 days can't be invalid use-case. Losing important data simply because someone went on vacation is unacceptable.

So store this data on the server.

The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.

But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked

It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss.

Server side, or if you need privacy, have the user export to / import from a local file.

This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.

This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.

I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely.

Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over.

I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.

I really liked the web when it was just documents.

> you didn't build an app, you built a web page

"Progressive web apps use modern web APIs"

The word application is there twice. I don't have to like it.

> they are just web pages that exist in a web browser for the lifetime of the tab they're in

Evidently not. My opinion doesn't matter.

> They shouldn't expect to have any persistent storage

2016 "With Chrome 52, we're introducing the ability to make storage persistent"

> ...a clear lifecycle of installation and deletion that the user has complete control over.

I've never asked for 7 days

> it will never be as good as native apps

I don't develop anything for walled gardens. I cant wait for my linux phone.

> it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

This already happened. Again, I don't have to like it.

> I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle

But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless?

I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound.

This is how it should work!

The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent.

If browsers asked approval before using localstorage, we wouldn’t have this decision.

Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy.

This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.

Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.

The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/.

Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.

Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.

Not sure about pinning, but bookmarking should not grant any extra rights. Even the useful websites should not be able to track me forever.

Look, we already have lots of website prompts, like camera and location. The best thing, privacy-wise, would be an explicit prompt: "this website wants to store information, possibly including tracking identifiers, forever. Allow?"

> have the user export to / import from a local file.

Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.

If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)

Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.

For your app, maybe.

But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.

There are many legit uses for localStorage.

Storing JWTs, game state data, etc.

why to store JWT in local storage. Localstorage can be accessed by CDN scripts also. Please don't put risk on ur users data.

Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins).

This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).

It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.

I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.

You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.

Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.

Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.

Not allowing important data to be downloaded for cold storage is unacceptable.

Ok, allowing, then what? I still don't want to deal with export/import as a user.

I have a few suggestions in the comment section you may or may not find agreeable.

With all due respect, this comes off as apologizing for Apple's disagreeable design choice.

If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful. Your suggestions might as well be aimed at browser vendors, who could conceivably offer user friendly controls for local storage (e.g. import/export without the dev panel). But as is usually the case each of the browser vendors has these little annoying ways that they cripple the browser to protect their business models. Apple is no exception to this. Look at how they've hampered the WebGPU process. Look at the history of their PWA support.

I strongly oppose Apple's anti-consumer practices in their App Store policy, PWA policy (non-existent) and similar places. I just believe this (localStorage policy) is not one of those cases.

Agreeing with Apple's disagreeable design choices isn't an apology, it's an honest opinion. If these choices are disagreeable, which I believe they are, they must be also agreeable by definition.

There's one simple thing that Apple could do. Do not delete local data if user bookmarked page from that website (or pinned it to home screen for mobile devices). Now bookmarked website treated like an "app" with slightly less restrictions and some random website data will be eventually purged (although I believe that 7 days should be extended to few months).

This is a great idea. Long forgotten bookmarks now has a purpose. I wish someone pitched this to all browsers out there.

> If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful.

Not if the features allow for increased web tracking.

> Not if the features decrease the need for the App Store

Fixed it for you. It's all about profit.

I don't think that web tracking must be fought at expense of user UI. It's fine to fight web tracking by introducing measures that don't break honest websites. It's not fine to fight web tracking or anything by crippling user experience with honest websites.

You want all your important apps to migrate to a platform where their data is all tucked away in inscrutable filesystem locations that don't expire ever?

Yeah, as far as I understand, cookies is the only storage method that will be left to use for long-term storage of user data. If I'm wrong, someone please correct me.

Edit: getting downvoted without any reasoning provided, so I assume I'm incorrect, there are more/less ways of storing data in the future for Safari users?

Cookies expire in the same way.

With cookies you can set the expire time yourself, as a developer. And looking at the list of the original blogpost from webkit (https://webkit.org/blog/10218/full-third-party-cookie-blocki...) it shows the following will be affected by the 7 day cap:

Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations

Since cookies are not mentioned, I'm assuming it's NOT affected by the 7 day cap but will instead continue to work as normal (except for the fact that 3rd party cookies will stop working, which is a Good Thing)

If the cookie is set by http headers, yes. If it's set with client side js, though, it's capped at 7 days (since ITP 2.1).

Interesting, I did not know that. Thanks for clarifying!

What if you have a cookie set by http and try to update it with js? Will it self-destruct now?

Technically, when you update it via js you're overwriting the existing cookie with a new one. And, from my understanding, it's then subject to the same restrictions as any other cookie set client side.

So in order to have a long-lived cookie, you essentially need to treat them as read-only client side, and push any and all update/write logic to the server such that it'll return a set-cookie header with any changes you require.

I would guess is works, but expiration is capped at today + 7 days.

Does this mean I'll soon be setting up an dummy "cookie maker" endpoint on my server that turns XHR body data into HTTPS cookie data as a workaround? :/

Secure + HttpOnly do not expire at 7 days. These are invisible client-side.

great, sounds like we‘ll get to consent to storing cookies more frequently - everybody loves these banners. there’s even more fun to be had, thanks to GDPR dialogs with 73 nested toggles.

Not sure if this answers that, but: https://webkit.org/blog/8613/intelligent-tracking-prevention...

Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

Have you considered porting to a native application?

Users are using other than macOS/iOS devices too. Most of them are not willing to pay extra for native app that runs on only one of the platforms used.

Why would users have to pay extra?

If right now you have a web app with paying users, that means you have an accounting system of paying users.

You could publish a "native" app that simply serves that web app through a web view, using those same accounts.

The issue is elsewhere: you need to pay your developers to develop the second app. You would most probably need to bring in one more team, for each native platform.

Will you get new users from that? If yes, they will pay for that (in principle). If not, just some existing users would migrate? Then you just increased your cost without increasing your revenues. So you would need to gain enough new users to make it worthwhile.

* * *

In a nutshell, it is the same reason why Adobe won't port their apps to Linux. They already have all the users that need their software, and while it would be nice for some of their users to migrate, it won't bring anything to Adobe.

You don't need a dedicated developer to ship a WebView app. That's the whole selling point behind tech like Cordova. Most of your code can stay the same and most likely all of it will stay Javascript (or whatever you are transpiling to it).

Again, if you are actually affected by this issue right now, you have a web app that is more or less trivially ported to a web view app. Your user don't have to migrate, they already have accounts, they just need to download the app again, this time from the App Store.

> In a nutshell, it is the same reason why Adobe won't port their apps to Linux.

Linux is a non-market for Adobe apps. On the other hand, if you have an offline PWA right now, you most likely already have iOS users that you would probably lose if you start confronting them with this "7 days and your data is gone" bullshit.

Why is nobody mentioning that distribution of apps is behind apple's doors and they can stop you from distributing anything they don't like or want for any reason?

On android, you can side load apps. On iOS, you can't.

You have to pay 30% cut if you are doing payments.

You have to adhere to their reviews and design guidelines. Which is OK but not ok if you are a small team and your users are fine with somewhat lacking app.

I've considered just not supporting iOS.

IMO it is completely unacceptable to have a persistent permanent non-expiring store in the browser. The potential for abuse is too high.

Then why are first-party cookies okay? FTA:

> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

Unexpiring cookies shouldn't be okay either.

To be honest, HTML5 LocalStorage was always different on iOS when compared to other platforms. The iOS browser localstorage is stored in /caches so it is cleaned when the device goes low on disk space. I found out the hard way, had a cordova app which ran on Android and iOS (and web) and saved an account token in LocalStorage. Some iOS users kept on getting logged out, mostly users with smaller size iPhones!

Now we store the account token in iOS keyring and that works.

ref: https://stackoverflow.com/questions/32927070/complete-data-l...

How do you use the iOS Keyring from within a PWA or website in Safari?

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

Right, but Cordova isn’t PWA.

Sure! In a PWA, storing login tokens in the keyring would not be possible. So as I said, on iOS the localstorage (and cookies) would be cleared in low disk space conditions anyway. So the PWA experience was already not good!

Yeah I've got a lot of users with very shaky internet and intermittent involvement with a given application (not using it for a month, more). This presents some serious challenges / impossibilities for those user's use of a web app when they're not online.

I hope they come up with some good options as this news settles. It's hard to see this as anything but even just a accidental push ('well you should always have written an app for the app store') to force folks to write a native app / participate in the app store.

If you're using Cordova or Capacitor this is why, at Ionic, we recommend never using localStorage for storing important data. Better to use an explicit filesystem storage solution like SQLite.

This is really in response to the irresponsible use of APIs for trackers. Evercookie is a stunning example of how far it can go... From their repo:

- Standard HTTP Cookies - Flash Local Shared Objects - Silverlight Isolated Storage - CSS History Knocking - Storing cookies in HTTP ETags (Backend server required) - Storing cookies in Web cache (Backend server required) - HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode) - window.name caching - Internet Explorer userData storage - HTML5 Session Storage - HTML5 Local Storage - HTML5 Global Storage - HTML5 Database Storage via SQLite - HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images (Backend server required) - HTML5 IndexedDB - Java JNLP PersistenceService - Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive.

https://github.com/samyk/evercookie

In short, everything and more can be used for tracking, and that has really killed the party for the many people who have created responsible, useful applications of these browser APIs.

“... abusing over a dozen technologies...” is this a proof-of-concept or a real thing ? It just seems too horrendous to be real.

I think your comment really hits the nail on the head, IMHO the frustration shouldn’t be directed toward Apple but more toward the groups who have pushed the tracking practice so far to necessitate such draconian measures.

This is 100% correct. Being upset at Apple here is exactly like publishers whining about ad blockers when they should direct their frustration and anger directly at the ad creators (or themselves) for foolishly abusing their audience.

No, the two are different. Ads are only used for ads. localStorage has lots of uses, tracking users being only one of them. Apple is throwing out the baby with the bath water. Ad blockers merely throw out bath water with varying levels of dirtiness.

This is real, but also not new (as you can tell from the name check on Flash, Silverlight and IE). They used to be called "supercookies", but that term has come to mean something else in the last few years.

It's really in response to a confused, ad-hoc web privacy model that has never been designed and is simply incrementally patched over time in response to complaints from an equally confused, directionless and visionless 'privacy warrior' subculture.

Mobile apps suffer these kinds of problems far less, partly because it's understood that actually mobile users don't install apps then get upset about "tracking", in fact, the vast majority of apps will want you to sign in to some sort of account and those that don't will be using ad networks to fund themselves, that users understand and accept this and that throwing up permissions screens doesn't achieve much because users will typically grant the permissions. Privacy on mobile platforms is more about stopping activity the average user would recognise as illegitimate spying - turning on cameras and microphones to feed conversations to angry ex-girlfriends, that sort of thing.

If the web's architecture had some sort of coherent view on how the tension between users, content providers and advertisers should work, then we wouldn't see this steady endless churn of app-breaking API changes. Everyone would know the rules of the road and there'd be way less tension as a result. Mobile platforms aren't quite there because they were designed with security architectures that were then pressed into service as ad-hoc privacy architectures, but they're still far more coherent on the topic than the web.

"some sort of coherent view on how the tension between users, content providers and advertisers"

Please share anything you think and find.

Balancing these kinds of trilemmas, on a knife's edge, is my metaphor for designing open markets, governance, democracy, planning, and so forth.

You could permissionwall that stuff, just like iOS asks for permissions to ask your location. If a random website wants to mess with Local Storage I know that I need to turn around.

Yes, that would have been a much better approach. It would hinder trackers, but not valid uses of localStorage.

... however i'm afraid that 99% of all users (the non-techies) would just be annoyed by the popup and click "OK"

I’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 systemically hindering web apps, especially on ones that are good on iPadOS, in order to boost native apps.

(I’m not saying this necessarily the start of this, but I am saying I'm not surprised. This is exactly the type change, targeting the exact type of app I’d expect to be targeted.)

[0]: https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-su...

moving forward we can expect Apple to start systemically hindering web apps

They have been doing this for quite some time now. Always ostensibly to protect users but always also conveniently putting webapps at a permanent disadvantage to native apps.

For my part I'm not interested in being a user of a platform so hostile to the web that it disallows any third party browsers.

Apple disallows third-party web rendering engines. Google Chrome on iOS uses own networking stack.

It is still a significant restriction, but it is rather understandable. Without it it could be just Blink everywhere at this point.

> Without it it could be just Blink everywhere at this point.

In what reality-distortioned universe is that worse than having a crippled web?

Please don't call anything that's not Blink "a crippled web".

I believe that OP is saying it would be preferable to have blink-everywhere than to have a deliberately-crippled Apple web browser with all other choices banned.

I'm the OP and I am a Mozilla volunteer. I prefer a web with many engines, I want it to have WebKit, Blink, Gecko and more.

Agreed. There is no choice with IOS: you choose the same WebKit that they've chosen, or Safari. One engine and version, or one browser using that one engine.

Android is a web monoculture too. Non-Blink browsers on Android are at <1%.

You can install any browser you want from playstore or outside of playstore. There are no restrictions on what you can and cannot have on your phone on android.

Yet non-default browsers on Android are non-existent. So in practice Android has the same web-engine mono-culture as iPhone. Given how successfully Google was able to ensure Blink domination on desktop and even more so on Android it is very understandable what Apple has done. And for me having at least 2 web engines on mobile is better than 1.

In what reality-distortioned world is that worse than 0%? Also, several of those Blink-based browsers include additional non-Google-approved features, like Mozilla's own Firefox Focus, Samsung Browser, Edge, and Brave. I'd hardly call that a monoculture just because they share the same lineage.

Then you also prefer not to have those options banned.

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.

If so it would be because users chose it and it would also help keep Firefox in the game which important to the long term health of the web.

> everyone would be using Chrome.

I'd be amazed if there were more than a tiny fraction of iOS/iPadOS users (of which there are hundreds of millions) who weren't perfectly ok with Mobile Safari for their everyday usage.

[I'm probably the "target market" for Chrome (backend, occasionally frontend developer) and there's no way I'd have it on my phone. I only suffer the GMail app because they've made IMAP usage of gmail unreliable.]

It doesn’t matter what users choose, devs would badger users into using Chrome for their own convenience. It’d be the return of the “viewed best in” badges from the late 90s and early 00s.

Remember, making everything a web app is Google's agenda because they benefit most from it.

Remember, harming webapps is Apple's agenda because only they benefit from it.

On the other hand, the web is mostly open for all, so most people benefit from it, not just Google.

One can always rely on cordova/phonegap type of app with a C++ plugin to address this issue.

Personally, not having web app storing large amount of data is a good thing.

Technically it's disallowing third-party JITs / executable data. Which is a good thing all-in-all.

Eh, I'm not completely sold on that.

Actually the guidelines specifically ban non-webkit rendering engines.

> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

At a minimum we can be thankful that Apple's rules force web developers to care about one additional browser.

Lucky us. We web developers really want to care about specific browsers like it's 2006 again.

IE6 must have been a great inspiration for Apple judging by their behaviour when it comes to Web.

> Always ostensibly to protect users but always also conveniently putting webapps at a permanent disadvantage to native apps.

This isn't always a bad thing though. For example, Safari has prohibited some obnoxious behavior that Chrome has allowed: Autoplaying videos, tab suspension, push notifications. These hog CPU and destroy battery life, worsening the user experience.

Remember, making everything a web app is Google's agenda because they benefit most from it.

I would just point out there are very valid use cases for these things, i.e. push notifications are very useful to me (from certain apps). The problem is one of consent.

MacOS Safari autoplays YouTube videos with now way to disable...

Interesting. I can tell Safari to not autoplay videos on YouTube in its preferences, but that doesn't seem to do anything. Seems more like a bug on Safari's part and/or workaround on Google's part than anything deliberate.

You mean Safari team accidentally forgot to test a video feature on a largest video website?

Safari uses some sort of algorithm to determine whether you actually want the autoplay to happen.

For example I've noticed that if you play a video on a website during that session, it will allow autoplay from scripts on that page (not 3rd party) for the rest of that session. Same for unmuting an autoplaying video.

This is all undocumented though and through personal observations, as Apple seemed to stop posting Safari documentation years ago.

By your logic they should just remove push notifications completely from iOS because it uses power. Wouldn't that be bad?

Web push is better than native app push when it comes to power consumption as web push is stricter on what you can do.

If an app on the app store abuses push notifications though, they can get kicked. Apple can’t kick a website off the web.

Technically they could blacklist certain behaviors from certain sites. They and all other major browsers already do this in a privacy-preserving way for Safe Browsing, certificate revocation, etc.

Blacklisting is a losing game, especially from the malicious sites most likely to abuse this. Notice how those malware and fake Chrome extension ads have a new URL every day.

Sure they can, Apple would still have full control over push functionality. Web or native doesn't matter.

As a native app developer, I can live with this.

As long as you start refering to the "i" in "iPhone" as Intranet and not ~Internet~ then we're cool.

I have nothing against hybrid apps. In many use cases, they are the best approach, and I have often declined business, in recommending them to others, as opposed to what I can do.

My post was not an attack on anyone or anything, and it was not being snarky. All I said was that I develop native apps, and that this policy does not affect me.

I like developing native apps. I've been writing native Apple software for 34 years. It's not really difficult; just different. I have also been developing "Internet" software, of all kinds (full stack), since before the WWW. Using Apple stuff. It certainly can be done.

My iPod Classic has no intranet or internet.

What does the "i" mean in that case???

iPod was that Harddrive MP3 Player that piggybacked on the MP3 download craze people were doing on the internet, obviously.

Ha! Thanks!

I had never thought of that!! I wonder if that same idea came into naming the iMac then??

The Internet Phone was the Cisco iPhone, not the Apple iPhone

As a navive app/web/backend developer and most importantly as an iOS user I can definitely live with this.

We don't want filthy legacy webapp shit, but 2020 high quality user experiences.

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.

This particular move takes something that is possible in web applications today and makes it not possible in the future (offline capable frontend-only applications), making the gap between native applications and browser applications further, so developers who need to build apps that works offline on iPhone, will only be able to use Apples own technologies for doing so, in a non-cross-platform way. Which in general, is what Apple always been favoring.

Google Docs doesn't really work offline, so it's not impacted by this change. Could also be a change of heart from Apple, since their stance on web applications have changed before.

It could also be exactly what they say it is: a way to prevent the abuse of local storage for tracking.

People who want to track users will always find a way to do so, it's a endless cat-and-mouse game. Now they will just use cookies instead... The only way to win this is to legislate away the freedom to track users by using privacy-invasive methods. That's the only way that will work long-term. But that'll make half of the internet industry disappear, along with it's shareholders, so it's unlikely to happen.

> People who want to track users will always find a way to do so, it's a endless cat-and-mouse game. Now they will just use cookies instead...

Isn't the new policy for local storage being copied from an existing policy for cookies? How can they switch to cookies?

Arbitrary government rules are never the solution for issues.

Now I'm not a native English speaker, but seems "arbitrary" means "determined by chance, whim, or impulse, and not by necessity, reason, or principle". Introducing a law to protect peoples privacy would not be arbitrary, especially since most countries have a due process for introducing laws.

> Now they will just use cookies instead

In the linked article it actually mentions that this policy is being widened from cookies to the rest of script-writable storage.

It's both.

They could restrict these APIs to "installed" web apps via the web app manifest file, if they were to adopt that. Maybe they will in the future, but for now they've just made web apps far less powerful.

> Google Docs doesn't really work offline

It actually works quite well offline

This is a great point with a simple explanation: How good Safari was on iPad was irrelevant before mouse support. Before mouse support, we had apps made with UIKit, which is a touch-first app framework, competing with web apps, which are keyboard-and-mouse first. So UIKit apps won, because UIKit apps are better for touch. With mouse support, that situation becomes exactly inverted: In UIKit apps, the keyboard and mouse are secondary, so web apps have the advantage in being keyboard-and-mouse first.

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.

We’re all speculating about Apple’s motivation, but none of us really knows why Apple made its decision. Perhaps it’s best to focus on the trade-offs—privacy vs. functionality—and not the speculative Kremlinology.

Respectfully, no. Learning software is a big investment in time and effort. Since I'm on Apple's platforms, because I think they're the best compromise for running the software I want to run, I am going to continue to speculate their reasoning to try to predict which software will be successful on their platforms in the future, because that's how I choose where to invest my time and effort.

I respect you have some other motivations here, but I'm not doing this for fun. I'm doing this because it's important to how I spend my most important resources: my time and effort. So no, I'm not going to stop speculating, the mere idea is laughable. Like buying an individual stock while having no opinion of what direction the company might take in the future.

Of course you are free to speculate, but my point was that we lack evidence of Apple’s motivations that would help us to make predictions of any value. All we can do is tell a plausible story, and without evidence your story is no more likely to be true than mine.

> In UIKit apps, the keyboard and mouse are secondary

Apple just added new APIs to support these.

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

As a web developer, I've never believed Apple has hindered web development on their platform, purposefully or not. They just don't spend their resources adding in WebBluetooth or whatever new API-of-the-day Google has decided to come up with.

As I see it, their focus is on the user, which is why they've been slow to adopt APIs that are privacy concerns, or drain battery, or have other negative implications.

That’s a very rosy way of looking at it. iOS has had bugs with its “add to home screen” webapps that kicked around literally for years. If they were being “user first” they’d support it fully or not support it at all. Instead they implemented then neglected it.

How many users even know or care about that feature?

How is that relevant to the conversation? If it is so little-used as to be irrelevant then the user-first thing to do would be to remove the functionality but Apple haven’t.

I can speak from personal experience that users do use it when you include specific instructions on how to use it. And it’s used in a number of corporate settings for installing webapps on an iPad.

What bugs exactly? Been using this feature for years and have never had issues with it.

Until a recent iOS release they had a number of undesirable features that made them a bit inconvenient to use: they used UIWebView (instead of the faster WKWebView), they "restarted" if you ever left them, and generally had a number of other quirks.

Probably because Apple giving a crap about web apps was depreciated with the release of iPhone OS 2.0 and the App Store over a decade ago. I'd bet few users even use the "add to home screen" button outside of corporate environments that want to add a shortcut to internal sites.

Facebook messenger is good use case for web app, but zuck want's to track you so you need to install app instead...

Try sending an AR video capture to someone over the web, lol

I'm sure there's more efficient ways to send text messages lol

To be fair, they've had bugs in iOS they've kicked around for years...

All parts of Apple's platform has had bugs that have kicked around for literally years. Their native SDK is infamously under documented and has all sorts of bugs https://twitter.com/caseyliss/status/1171778706878160897

The bugs in Apple's software, whether in web or native or in documentation are not part of some nefarious plot, its just a part of Apple's mismanagement and relatively minimal resources.

> relatively minimal resources

Uh, they're the most well capitalized corporation in the world (or hovering in the top 3 plus or minus a few quarters). They have the resources to make it work if they wanted. There are undoubtedly thousands of engineers, hundreds of managers, and at least a handful of execs, working for Apple, lurking in this HN thread today, not because they're unaware of their ongoing sabotage of web standards on iOS, but because they're completely aware of it and want to take the temperature on how their latest kick to the shins of PWAs is going over.

Apple really does run with very small software teams. It's cultural.

I’m fully aware of how much cash Apple has, but they’re known for having very relatively small software teams looking after whatever app needs updating that release.

I wouldn’t be surprised if Safari/WebKit was one of the larger teams within Apple dedicated to a single app.

You’re between one to two orders of magnitude off in you estimate of the size of Apple’s web technologies team.

> As I see it, their focus is on the user,

Oh and let me guess, they know better than me that I don't need this or that.

Let them suffocate inside their poisonous wall garden as the web gets richer and richer.

Be careful what you wish for! I don't for an instant believe that Apple's motivations here are purely for their users' benefit, but their actions do at least tend to have some beneficial effect on privacy. Letting them suffocate so Google's spyware-laden ecosystem becomes the only viable way to access the web on mobile devices would not be an improvement.

In my opinion only we ourselves can save ourselves from Google. By using things like AdNauseam and educating everyone and their dog about ad blockers.

I don't think the way to fix ad bullshit is to close down everything, I do think it's in opening everything and educating everyone. That way people actually win, not corps, as it should be.

As a web developer, I've never believed Apple has hindered web development on their platform, purposefully or not. [...] As I see it, their focus is on the user, which is why they've been slow to adopt APIs that are privacy concerns, or drain battery, or have other negative implications.

As another web developer, I find this entirely unrealistic. Apple's QoI even for popular new features like the HTML5 media elements was a bug-ridden mess for years before they fixed even basic problems. Conveniently, having managed to break the de facto standard for serving video on the web that had been working for years up to that point (Flash players), that left native apps as the only reliable way to do a lot of even quite simple things you might want to do with multimedia content. There is a deep irony that some of the breakage was because they were playing those media elements through effectively a separate plugin of their own that wasn't properly integrated into Safari and consequently broke other basic web behaviours like cookies.

At this point, the idea that Apple's motivations for the constant breakage and even severe regression of web functionality on iOS devices are entirely altruistic and for the benefit of their users is about as credible as Google and Facebook lobbying for privacy regulations because they want to decrease tracking on the Internet.

Just to be clear, Apple didn't kill Flash, mobile killed Flash.

Even on the Android phones that supported Flash, it ran like shit and drained battery. Apple just never opted into that experience.

This revisionist history, of seeing people wanting the proprietary Flash to come back, is crazy.

Just to be clear, Apple didn't kill Flash, mobile killed Flash.

I don't think that generalisation is warranted.

Apple refused to support Flash at all, meaning everyone who wanted to provide (among other things) audio/video content had to switch to the nascent HTML5 functionality, which was at that time and for some years afterwards inferior to Flash in almost every way except availability.

In that situation, it made little sense to invest in better Flash support on Android as it was presumably seen as a dying technology. However, there was no inherent reason why Flash couldn't have been improved to use less battery in the same way that the browsers themselves were, or that Flash could not have taken advantage of better hardware support on mobile devices for computationally expensive tasks like video decoding as this became available with newer devices.

This revisionist history, of seeing people wanting the proprietary Flash to come back, is crazy.

There's nothing revisionist in saying that people wanted A/V content on their sites, that Flash player had been by far the dominant way of providing that content up to that point, or that the then-new HTML5 alternatives were also very poor in quality and performance on mobile for several years afterwards.

Remember how for several years everyone with iPhones couldn't watch the videos on a lot of websites, and how excited people were when the big video hosting sites started adding HTML5 players and, in time, support for better codecs? Probably many of those people had no idea what Flash or HTML5 even were, so I don't suppose they did "want Flash to come back", but they certainly weren't happy that they couldn't watch videos on websites like everyone else.

The people who work on making websites function better on iPad are literally a 20 second walk away from the people who work in Intelligent Tracking Prevention–do you really think that they'd seek to undermine each other in this way?

Absolutely, do you have evidence they are talking and consulting with each other? Obviously lack of evidence isn't evidence either, but departments do things all the time that are at odds with each other in companies like Apple.

> Absolutely, do you have evidence they are talking and consulting with each other?

Firsthand.

Which is strange, because they're already under scrutiny for being anti-competitive WRT their app ecosystem. Having good support for web apps could've softened that case a little bit.

Better title: Apple restricts tracking by limiting browser storage, which hurts my particular app.

Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).

> If you want more access

which is somewhat ironic, because the goal of a web app is to break free of the walled garden and become OS-independant.

No way that's happening on iOS as long as Apple takes 30% off the top

Yes because think of all the money Apple gets from taking 30% all of the free apps that would be free web apps....

There are very few free apps. Most of apps are paid with ads or external subscription. And Apple wants cut there as well.

Apple doesn’t have an ad network outside of the little money it makes from ads on the App Store itself.

Also, Apple may want a cut of the subscription revenue but most companies who have significant subscription revenue, don’t go through Apple’s subscriptions payments.

Apple doesn't get a cut of ads within apps. A free app with ads doesn't make Apple any more then the $99/year for being a developer

Yeah, cause everything in the browser is free, right?

Clearly it's A LOT of money for apple. If they didn't care about the money then they would just allow it so everyone could avoid receiving payments using apple and giving them 30 %.

That still doesn’t answer the question. How many websites were required to be apps because of limitations of Safari?

What makes you think users would willy nilly put their credit card on every random website.

Everyone can avoid using Apple for subscriptions. There are existence proofs of apps on the store that require payments outside of the store - like all digital content from Amazon.

Most of the money that people spend on the App Store are from games and in app consumables. Especially since the major services like Netflix and Spotify don’t allow in app subscriptions.

The 30% includes any kind of subscriptions or payment tied to the user account.

Seeing that most major subscription services on the App Store are already forcing users to subscribe outside of the App Store, Apple isn’t getting a cut of subscriptions from the most popular service.

How many apps require a subscription and cannot be a web app because of limitations of Safari?

How many paid apps would be websites if it weren’t for limitations of Safari?

The moment you offer in-app payment, apple gets a cut. This goes as far as not allowing apps that link to payment outside of the appstore's payment system.

There is a huge number of cordova apps out there. These are webapps inside a native wrapper, to access exactly those features that are crippled in safari. Reliable storage, push notifications, and not much more.

Yet dozens on companies have had successful businesses not doing in app purchases - like Amazon.

Yeah big players get an exception - not a good example.

ACloudGuru does not allow you to pay for subscriptions via in app purchases, Udemy allows both. A company can decide whether it is right for their business model to allow in app purchases exclusively or along side their own payment options.

Hulu for instance allows in app purchases for the regular Hulu service but not Hulu Live

Which in a current situation is running a risk to fall into Google's walled garden. It is not there yet but Google's working hard on subverting the Internet.

But browsers are severely sandboxed already. What the article is talking about is:

> deleting all local storage (including Indexed DB, etc.) after 7 days

which I can see how it might help privacy (since you could be tracked via local storage too) but also how it might break any potential web app that might need data to last more than 7 days.

> If you want more access, make a native app

But then, everybody will complain about yet another Electron app, right? Not to mention that you have to fork over $99 and go through the signing / notarization hoops that change from one week to the other.

I think in the name of privacy and security only Apple and some select few corporations will be allowed to make software in the future. macOS / iOS and Windows 10 are evolutionary dead ends in many ways.

They do not "change from one week to another". They have changed, what, twice ever?

and to be honest the process has gotten a lot easier.

Two counterpoints:

* AdoptOpenJDK releases that were notarized some months ago are no longer accepted by Apple since they made the rules even more stringent. I had releases accepted by Apple that are not accepted today using the same AdoptOpenJDK binaries.

* Apple's notarization rules are not global. There's whitelists for given companies/institutions/apps/files which means the same dylib might not have to be notarized by a bigger player but will have to be codesigned by you.

The above happened to me in the span of less than 3 months I think?

Indeed, the scripts I use per se to do the notarization are about the same as originally.

Do you have more details about this?

I think I gave quite some details. Do you need the exact AdoptOpenJDK version (11.0.5+10 for macOS)?

And I made a test about the non-global rules too (by trying to submit the same binary and getting rejected).

Apple may have stepped up notarization requirements, but I never heard them be inconsistent across developers. Are you sure you submitted the same binary? Nothing different about the signing or bundle layout?

Well, I would love to know how to change the bundle layout to have to sign less.

My notes are here: https://www.patreon.com/posts/34472331

You can take the same Apache-NetBeans-11.3-bin-macosx.dmg and see how you could submit it with your own key.

I guess there may be different rules on a .pkg vs .app in a DMG but it seems silly since the user gets the same bits on disk.

Native app != Electron app (fortunately!) The less of that bloated slow crap the better.

If we had to make non-electron, native version of our app, that would mean Windows[1] and Android, because that's where the current users are. Forget the rest.

Is that the future you want?

[1] And they would not be happy about that either. For many that would mean RDP or Citrix. They prefer webapp right now.

I think apple DOES want this. Core markets cleanly segmented are probably a better value prop to apple than everything working everywhere and users being able to freely migrate between platforms

Sure, keep your (likely crummy if you’re OK with Citrix as a primary use case) Windows and Android apps.

The market will decide. Your comment is just on the user-hostile side of assuming it will prefer your technology choices.

It would only be citrix if it was made a native app. It is presently a web app, presumably because it was determined to be a better choice. You proposed that it should be a native app. It would be the customers that would choose Citrix, but they'd probably prefer web apps (if they're anything like my customers).

The deployment story is so much better for web apps, which is the main reason it seems to be so compelling for big enterprises.

7 days after Safari use without user interaction on the site.

Apple requires that all code-related assets for an app should be included into the app. So the app cannot just be a launcher that show a browser with a website.

That doesn't seem to be completely true. Basecamp has a "hybrid" app, where they use native frames to load web pages for content https://twitter.com/dhh/status/940358921960677376

More likely that apple and the other corporations are also evolutionary dead end and this is a temporary hiccup

> Apple restricts tracking by limiting browser storage

But the argument that this will protect privacy in the first place seems really weak.

Before this change in Apple's policy, an app could store my config data on my PC.

After this change, they'd need to have me log in and send the config data to their servers.

That seems like I've lost privacy, not gained it.

> they'd need to have me log in and send the config data to their servers

You'd have to log in. That's a hurdle that involves implicit consent.

That's a hurdle that involves de-anonymization of the user.

No, Apple offers anonymous user credential technology. Server gets unique identifier and ability to authenticate with no actual user info. Server gets an anonymous redirected email for sending info to the user. Apple is the intermediary. Of course, you can choose not to trust Apple, but Apple already has my info and their business model is not predicated on tracking and advertising. I'd rather continue to trust them than spread my data across more orgs, but that's my choice. You might choose differently.

But that's a solution for a single OS, for a web page that should be cross platform by default. And it's not really a solution, just additional complexity to what was a solved problem.

I choose differently, but my choice may matter to you if I throw up my hands and say "Too much effort; if the user visits my site in Safari, I'm just going to toss up a banner page that says "this site does not work in your browser."

It's a power-play on Apple's part to intermediate themselves where their inter-mediation isn't necessary. And all kinds of customers (enterprise in particular) won't appreciate Apple getting a free "hi hello" signal on how much their company uses some service that leverages this scheme. Especially if Apple is a potential competitor to them.

Same. We momentarily considered adding Apple Login to our app when they changed the rules a couple weeks back, but instead we are removing all social login and migrating all accounts to (email/username)/password. Why?

Because a) it's even more code we now have to support, both in our apps even on android and on web -- a huge investment we are not prepared to make, and b) because for what we do, we actually do need to know the user is who they say they are (we offer the ability to contract a service between third parties, which means anonymity is NOT desired). I was never really comfortable using social login at all, for that second reason, but was pressed to by my peers; after Apple's shenanigans we came to the mutual decision that it was time to cut the cord. The login screen is already busy enough, we don't need yet another button. So we'll simplify.

For this latest change, it won't affect us much because I have always made it a policy neither to trust, nor to rely on, the data in Local Storage, and only to use it for performance boosting via caching. If data isn't there, it isn't there, and we go get it. This is largely due to historical reasons where browsers have always borked the LS implementation in one way or another, but it's beneficial now in that it won't really change anything for us.

I do feel for folks that are using it for genuine storage though, I know some apps that use it in order to AVOID storing private data on their servers, which will now have problems and be forced to reduce privacy in order to adapt.

This is definitely a power play on Apple's part to further weaken the web ecosystem. Device sales have been falling for years, they know their cash cow is their 30% cut on app purchases and IAP, and they aren't going to let the browser cut into that. Any "privacy" benefit in this case is purely incidental (and as noted above I believe it will do the opposite in many cases).

Most people don't care about logging into services anymore. just implement a fb login and it takes less than 5 secs

If you've ever looked at user analytics you know this is absolutely not true

I'm interested. As a iOS developer I always found that user want to skip the login page soon as possibile, if there is an FB button they press it. Do you have different experiences of it?

I run away from services that only allow social media logins.

1) I don't want social media to track me everywhere

2) If the people developing this app have taken this shortcut, what other bad, leaky implementations do they have on their site/app?

-> No thanks, exit this way

Web-wide analytics (and our own, which have almost exactly the same stats), show about 30-40% of users still rely on email/password (and that's actually growing, as password managers become more ubiquitous especially when Apple implemented the built in credential manager in apps and in Safari on iOS).

We're actually getting rid of social login in our apps. And we're not alone, alot of platforms I use have recently moved the same direction, and I think for the same reasons.

Google, Facebook, Github, Twitter logins proliferated because

a) the cost of implementing an auth system is high, and those offered a turnkey solution that was cheap and quick to implement. This is no longer true, there are lots of options now to host your own auth while federating the hard work to someone else (e.g. Auth0, Cognito, et al)

b) for awhile, people LOVED the idea of having "an online identity" and a single login everywhere. Over time this has not really panned out, because it's the prisoner's dilemma; for it to work, everyone has to do it (which is why G and F have tried so hard to get everyone to use them). But also, because privacy questions have reduced the shiny appeal of that scenario in the first place. Combine that with easy to use password managers now, and it's much less necessary.

Respecting someone's privacy doesn't mean forcing them to "consensually" give up their privacy.

Thank you. I think this is very often overlooked. "Consent" gets thrown around alot but most of the time people basically have no choice if they want to, you know, participate in modern society. That's one of the reasons why an open web is so so so important and why I think Tim Berners Lee is working so hard to try to bring some part of that back as the "online world" (apps and internet) become more and more walled garden.

If you are coerced into giving consent, it isn't consent, and most of the time if you're doing it so you can be part of the world around you, it is coerced, whether people want to recognize that or not.

Any time you see the phrase "implicit consent", it can be helpful to stop and ask how that consent could be withheld without changing anything else. If it can't be, then it's not really consent at all.

Wouldn't it be possible to retain the data with privacy by:

- Asking the user client side for a password

- Encrypt data as a blob using some symmetric encryption (AES)

- Push encrypted blob to the server with login attached

If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted for a "data" password for that particular site. Or would there be an easy way to build a pki/pin cert type of encryption to eliminate the password prompt? (I feel like this is essentially what Keyring!? would do but maybe not?)

Outside of implementation weaknesses which I feel could be mitigated by created standard libs to do this, what am I missing?

Bonus points for pushing the data diffs only or even a version controlled blob (data stored in a git repo where only the diffs are pushed in encrypted form).

Edit: Or how about a local hardware appliance for your network that stores all data like this encrypted and pulls from there.

It's very hard to verify that the data is indeed encrypted, whereas with local storage you can just monitor your network usage and see that no requests are going out. Hell, you could airgap your machine and have no problems with localstorage.

You can implement end-to-end encrypted applications e.g. with the subtle crypto API, though there’s always a debate of whether this really provides good privacy as the website owner or an adversary who can inject code can still change the JS and steal the data. Personally I think it’s still much better as the data at rest is encrypted and only the user can decrypt it. Now the problem is of course that if the user forgets his/her password the data is gone. To alleviate that you can again think up some schemes like encrypting the encryption key with an asymmetric scheme where the private key is kept secure by the website owner, but that then requires a process for securely using this key... So it’s possible but not trivial I would say!

Technically local data is more private than contacting a remote server to download it again. I don't see that being a controversial stance.

I know this is ad hominem, but your comment just sounds like "I make big money with native apps and don't want web apps to catch up!"

> If you want more access, make a native app (with or without web technologies).

Browsers usually ask for an additional permission in this case which would be a good approach. Your post sounds like "browsers need to be severely limited, so if you want to watch video, just launch VLC". It does not work this way.

> Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).

Native apps have the same problems too and such "severe" limiting of apps in web browsers still doesn't solve it. The only more or less privacy preserving model I can think of for native apps today is open source repositories with app distribution not controlled by app developers, like f-droid or repositories in various linux distros.

> If you want more access, make a native app (with or without web technologies).

How's installing a native app better for a random user privacy or security wise, exactly?

You have to send every change to Apple before the user can run the code. In theory, that allows Apple to do more checks than when the code is dynamically loaded from your web server.

I'm sure apple catch all privacy violations of their so developers.

Apple doesn't care if your app logs your usage to Google Analytics every 1000ms.

Besides, in the browser you have trivial tools like uBlock and the network tab. In native apps, you have to use mitmproxy just to see what the app is doing at all.

With embedded SDKs and device identifiers that work similarly to third party cookies, they're not.

I understand it's changing too, but not as fast as safari.

It must go through the App Store vetting process, whereas a web app can come from anywhere.

And, um, any other app which saves local data locally.

It's not "limiting browser storage", it's making browser storage expire. TFA's example is just some random app, but this essentially kills the entire concept of an offline-first web app, and severely hurts the browser as an application platform.

Web apps brings nothing in revenue to Apple.

Genuine question: what makes native ad frameworks different here? They execute with the same privilege of their containing app so surely they’re open to similar privacy concerns. Shouldn’t native apps have their storage cleared?

OR maybe it's apple's responsibility to figure out how that usecase can exist without security flaws?

As a customer, I'm tired of devices functionality being limited coz "security risks". Functionality that is arguably superior to native apps apart from the security risk.

Wouldn't making it first party only cover it? I don't see how this has anything to do with privacy/tracking. webpages can still leave long term cookies. The only way this is a privacy issues is if 3rd party iframes can use localstorage but just like 3rd party resources have their cookies blocked so to could localstorage.

Otherwise this has absolutely nothing to do with privacy or tracking.

Making a native app is more complicated than making a webapp, especially if you want something cross platform. Browsers are now an universal virtual machine, what was the JVM years ago, and with webassembly we will se more and more things done in the browser.

The real 'write once, run everywhere' are webapps, a webapp doesn't care if you are using Apple, Windows, Linux, BSD, whatever, if you have a compatible browser you use the app.

Sure there is Electron (or React Native), to me it doesn't make sense, what is the point that every application needs to ship basically a browser? And still Electron apps need to be compiled and packaged for every platform, while with webapps you enter the URL in the browser and you are done with it.

Doesn't adding APIs to browsers not only to use the local storage but also to access the filesystem of your device (of course asking the permission to the user) make more sense?

Of course what really Apple fears is loosing the control of the apps that gets used on their device, now they control the App Store that is the only way to get apps on their devices (beside jailbreak), with webapps is different, since you can access them directly from the browser.

And the thing that is absurd is that the first iPhone didn't have the App Store since Apple decided that the only way to get third party apps was trough the browser, now they are aiming for the opposite thing.

My company created a web client for our chat software product around 5 years ago. The quality of our product has slowly deteriorated as browser vendors continually remove or restrict features that once worked fine. Just to name two examples: autoplay audio for chat notifications and tab throttling killing websocket connections and background timers. I understand bad actors are abusing these things, but they're breaking totally legitimate use cases.

We've been forced into an electron client and now urge our customers to ignore the web client. If we didn't have a small number of customers on Macs, we would abandon web tech altogether and build a native Windows client.

> The real 'write once, run everywhere' are webapps, a webapp doesn't care if you are using Apple, Windows, Linux, BSD, whatever

that’s not been my experience*

* unless you use some huge web framework to abstract everything and patch all the differences between the browsers

> If you want more access, make a native app

...and give apple their cut. Why not add permissions to webapps? Like location, or push notification... oh that's another feature that happens to be missing only in safari.

Just accepting these moves from apple as "in the interest of users" is naïve. Apple has a huge vesting in their appstore, and every webapp is a potential appstore-app that is some lost revenue.

I mean, maybe apple is right, and the web should go back to a readonly document-like format, like in the old days. Articles and links. Apps for everything else. But let's not kid ourselves that they do it purely in the user's interest.

> which hurts my particular app

A big chunk of the web these days uses JWT and localStorage for auth.

I’m a little confused by this and maybe I’m missing something. Wasn’t localStorage always intended to be treated as a volatile storage mechanism for non-critical data and caching? The advice I’ve seen for several years says to avoid storing sensitive or critical data there.

Can PWAs not switch to using IndexedDB which seems like it’s more purpose-built for this use case?

No snark intended. I’m legitimately curious what the situation is and where any blockers are.

> Can PWAs not switch to using IndexedDB which seems like it’s more purpose-built for this use case?

IndexedDB is also subject to the 7 day limit. Leaving no persistent storage for web apps at all.

Ah, I missed that in the original documentation and most of the discussion I've seen has been around localStorage. Thank you!

It's a bit confusing because there are two similar terms being used to describe this. First is "local storage" which refers to any of the storage, as long as it's on the local device. Second (which you used) is "localStorage", which refers to specifically the window.localStorage API (which you are right about, has been described as a volatile short-term memory for apps).

In the original post from Apple[0] announcing these measures, they've listed all script-writable locations are subject to cache clearing:

- Indexed DB

- LocalStorage

- Media keys

- SessionStorage

- Service Worker registrations (I guess this means service worker caches)

[0]: https://webkit.org/blog/10218/full-third-party-cookie-blocki...

Thank you for outlining that! I missed the impact on Indexed DB in my original read of the issue. It makes more sense, now.

I would be OK with 7 days being the default with a permission model where I can grant a website longer storage time.

Actually, I'd be even happier if any form of offline storage required explicit user permission anyway.

There's certainly a balance to achieve there. Too few permissions prompt and you lose control, and too many and you get desensitized or even worse annoyed at them.

There's no balance. You just let the user set any permission and make the prompts unobtrusive.

There is no such thing as an "unobtrusive" prompt.

Actually there is - firefox does it all the time. It's simple really - just add a new obscure configuration parameter and tada - the browser starts ignoring your dns resolution setting and automatically uses a preconfigured one. No need for a prompt, obtrusive or otherwise.

network.trr.mode I'm looking at you.

I configured my Chrome to block sounds on all websites except for a few selected ones. Now if blocked website plays sound, I can see tiny icon in right of my URL bad. It's absolutely unobtrusive, yet I can enable sound with two clicks.

Some browsers show an icon in the address bar when an app is requesting/can make use of an optional permission or feature. Clicking the icon allows you do grant the extra permission (i.e. allow cookies, enable, camera, etc.) but otherwise no additional prompt is shown.

I think this is an excellent example of such an unobtrusive prompt and is how ALL such features should be implemented. Sites should get almost no permissions by default and certainly not be able to show popup prompts.

That is not a prompt at all, just a fancy configuration option. Which most users will never notice and just assume the app is broken.

When the site tells them to "active X permission" without telling them how to (for their specific browser version), most will leave instead.

When the site gives super detailed, up-to-date instructions on how to activate the feature, a very large percentage of users will still leave instead.

When the feature is so useful that many sites go through all thouse troubles and it's common enough for users to encounter this that they'll follow through, most will do so for every site that tells them to and entices them with "ACTIVATE X TO RECEIVE YOUR $10,000 PRIZE, LUCKY WINNER!!!".

> Actually, I'd be even happier if any form of offline storage required explicit user permission anyway.

Even offline storage that is only used locally? Say a game with savegames that has doesn't use online connection to play it.

Another example: a password manager.

I would say yes. The reason being is that exceptions will be abused, so it is better to enforce rules that everyone has to follow than to depend upon good behavior which the people we are trying to stop won't (almost by definition, because we wouldn't be needing to try to stop them with rules if they were already respectful of the social contract).

If there were a way to enforce that the application has no access to any communication system (network, inter-app, maybe excluding explicit copy/paste), then I would be happy to give it permanent storage.

But as soon as you allow it any access to network resources then carrying state becomes a liability.

Both network usage (in native apps) and storage (both for native and web apps) should prompt for permission IMO.

Even before this change, data in IndexedDB was kind of volatile - if a device was low on space, browsers could delete stored data.

https://dexie.org/docs/StorageManager describes the StorageManager API which lets you prompt the user to allow your IndexedDB data to be stored more reliably. My first thought after reading this article was wondering if this would allow an exception to the 7 day rule... but then I remembered that Safari is the only "modern" browser which does not support the StorageManager API

lol, sucks for users of my client side JS video game!

Sounds like the solution is to add the app to your home screen. I don't think its reasonable for a browser to let any site I ever interact with to store data on my device indefinitely

Even web apps that you add to your home screen are subjected to this.

"Web applications added to the home screen are not part of Safari and thus have their own counter of days of use."[1]

From WebKit: [1] https://webkit.org/blog/10218/full-third-party-cookie-blocki...

A Note On Web Applications Added to the Home Screen

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.

Of not, this also contradicts the article‘s scenario of going on vacation. Only days with some browser use are counted.

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

Can anyone explain this with an example?

So web apps added to the home screen will have their storage wiped under some scenarios? If not, what does "have their own counter" mean?

How are web applications added to the home screen not part of Safari in a way that's different from a regular URL you might visit?

> Can anyone explain this with an example?

Note this is totally based on my reading of the GP:

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

I'm understanding this to mean: you access Site A and it stores data to your local storage on day 0. Then you use Safari for Sites B, C, and D, but not A for the next 7 days. Since Safari has been used for 7 days without using Site A, Site A's data is cleared.

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

I'm understanding this to mean there's no distinction between Safari and Site A anymore. Since you can't use Site A for 7 days without using Site A, Site A's data is never cleared.

It would make much more sense for them to just disable the counter in this case, or at least just explain it that way. It would be less confusing.

Home screen installed PWAs are treated as a separate web browser.

So installed PWA's do have automatic deletion, but that basically only applies to third party content (like advertiser tracking cookies, or content from other sites you show inside an iframe), since the number of days used since last interaction counter will stay at zero for the main site.

If you add the Twitter PWA to the homescreen and don’t use it for seven days, it’s storage will be reset and you’ll have to log in again.

I think WebKit’s handling of local storage is the prime example of how optimizing for privacy to the exclusion of every other consideration is user-hostile

I don't read it like that. It's not about 7 days real time, it's about 7 days on which you use the app.

Since you can use Safari without visiting the PWA's domain, this feature can delete the data of a PWA which runs in Safari.

Since you can't use a homescreened PWA without it visiting the associated domain, the data saved by the PWA's domain will never be deleted for homescreened applications. But data associated saved by other domains can still get deleted if you use the application for 7 days without it opening that domain.

How is this any better?? I don't expect apps I install - native or PWA - to clear their data if I don't use them every 7 days. That's crazy!

I'm not sure I understand how it is "installed" if you aren't adding it to your homescreen?

Isn't that just visiting a webpage?

the service worker is installed regardless if you add it to the home screen.

> Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. [...] We do not expect the first-party in such a web application to have its website data deleted.

I don't get it. Which of these statements is correct?

1. "Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Of course, that counter doesn't do anything. It just sits there, counting, for no particular reason. We just love counting things!"

2. "We do not expect the first-party in such a web application to have its website data deleted. Except, of course, if they don't use the web application for seven days. In that case, that data will be _extremely_ deleted! Really just wiped from the face of the earth."

Neither.

The counter is per days of application use, so (2) is false. Not using the app does not affect the counter.

The counter is also per domain, and so while the first party domain for the PWA (which is likely to, of course, be loaded on each PWA launch) is effectively meaningless, if you visit other domains from within the PWA they will be subject to the counter independently.

Okay, that makes sense - counter is third-party domains only. Thanks!

So let's say I launch the zombocom app, then click a link inside the app for "zombo updates" that goes to their twitter.

Then the next few times I switch to the app, I don't launch it from scratch, I just look at the twitter.

Then I've gone seven days inside the zombocom app without touching their actual domain.

Does everything except the twitter cookies get deleted?

I believe the first-party primary domain of the app will never have its data wiped — though the article could certainly be clearer on the point. What would be cleared in that case would be any other domains — if there's also a "Visit Zombo Facebook" link in there, and you only looked at Twitter for a week, the Facebook cookies would be wiped.

This is a baffling word salad. So they are tracking days of use of home screen web apps... which sounds like it means that if you do not use the app for seven days the cache will be deleted... but they don't expect a web app to have its data deleted. What?

The only coherent interpretation I can think of is that accessing example.com in a home screen app doesn't reset the timer for example.com in Safari. And vice versa. But it's still really unclear whether that implies that home screen apps get their data wiped or not.

Home screen installed PWAs are treated as a separate web browser.

For all web browsers, content is only deleted after 7 days in which you use that browser. So if you shut for phone off for a month, and then turn it on, and open safari, that whole month only counts as one day, since you did not use the safari browser during that month.

The same rules apply to PWAs installed to the home screen, which are being treated as seperate browsers. Of course, the count of days of use of this "browser" without using the main site will always remain zero.

But for third party cookies, or third party content from an iframe that uses local storage, those would get nuked if the home screen installed PWA is used on 7 different days without interacting with those domains.

It depends on the context.. For example, I use an invoicing web app that stores previously created invoices indefinitely in localStorage. This gives me the benefit of not having to manage login credentials and keeping everything client-side. It also gives the site's developers the benefit of not having to manage user accounts or server side state.

Without being able to use localStorage as a long term store, I'll have to register for an account, have to deal with them handling my data, etc. Losing the functionality of localStorage as a long term store has disadvantages.

Maybe it is because I can't seem to hold onto a device for more than a year or two before I lose it somewhere, but the idea of having all my important invoice data on a single device sounds scary to me. I would hope that localStorage is included in in iCloud backups.

I think looking at Apple as saviour of Privacy, is for lack of better term just wrong. They have always favoured closed systems even if didn't provide privacy advantages or as in this case was counter-intuitive for privacy.

I feel the comparison of Apple with data companies such as Google, Facebook is by itself at fault. Apple like any computer company of 70's was not into data, just because Internet itself didn't exist at that point like it does now. 'Apple didn't choose to be in data' is projected as altruistic, instead of just a marketing ploy(they didn't choose, because it wasn't available).

Apple doesn't receive even the fraction of scrutiny Google, Facebook receive (which they should). e.g. iCloud hack, Apple's response to iOS vulnerabilities targeted by state actors, Newer Safari being incompatible with privacy extensions such as uBO etc.

Personally I feel good that Apple is not into data, just because I feel if they are into data; they might be more evil than Google or Facebook aided by their walled garden.

This is webkit, which is open source. Apple took an existing HTML/CSS/DOM engine, rewrote it, renamed it, and opensourced its version, too.

It's compiled using LLVM, which also contains thousands of lines of open source code by Apple.

Of course you might argue that these examples don't prove your sweeping statement false, but please read https://en.wikipedia.org/wiki/No_true_Scotsman before arguing.

Open source is not the same as open. You can't run Firefox on an iPhone.

Sure you can

https://apps.apple.com/ca/app/firefox-private-safe-browser/i...

Sure you can't. That's not Firefox, but Firefox-branded Safari.

You can run real Firefox too, if you jailbreak first.

Before someone says I have Firefox/Chrome on my iPhone; they are just skins for Safari. Same vulnerabilities which exist on Safari(Webkit) can be exploited there as well since they aren't allowed to use their browser engine.

If I understand you correctly, "open source" is not a kind of openness and should be disregarded. Assuming that is so, for the sake of argument, what does count as openness?

It was open sourced as WebKit because it derived from KHTML, which was copyleft, and it took lawyers getting involved before Apple played ball and released it as open source.

I think looking at ANY company as the savior of privacy is a waste of time. Companies have proven time and time again that they are unable to self-regulate this. Only way forward is to introduce legislation that makes it illegal to track users using privacy-invasive practices, otherwise we'll never get rid of it. A company can be privacy-preserving today, but then the leadership changes or acquisition happens, and now they change their practices, without informing users.

I simply see no technological solution to this problem, it'll always be a cat-and-mouse game, until governments catch up and makes it illegal.

I'm eager to hear if someone here does have any solution to this problem though.

>> I simply see no technological solution to this problem, it'll always be a cat-and-mouse game, until governments catch up and makes it illegal.

Then you we will have privacy-avoidance companies just like we have tax avoidance. Problem solved!

Exactly, and when they get caught, they get fines or prison. Sounds good to me, let's ship it.

Let me correct that for you: When they get caught thet get a small fine(somewhere close to 1% of their profit) or no fine at all.

Well, we're talking about a hypothetical law here, so we don't really know the amount... The low amounts for fines when it comes to big companies is a different problem that should also be fixed.

Often, the fines for breaking the law are factored in to the cost of choosing to do so in the first place.

This is justified, of course, because the gain for doing so vastly exceeds losses due to the fines.

Agreed — Apple’s trying to project a high-minded motivation here, but their real motivation is likely to try and limit web technologies so that companies must still invest in native iOS apps and remain within their walled garden.

> They have always favoured closed systems even if didn't provide privacy advantages

Yes.

> or as in this case was counter-intuitive for privacy

I fail to see how this is counter-intuitive for privacy.

> iCloud hack

Targeted spearphising?

> Apple's response to iOS vulnerabilities targeted by state actors

https://news.ycombinator.com/item?id=20897368

> Newer Safari being incompatible with privacy extensions such as uBO etc.

https://news.ycombinator.com/item?id=21025252

> I fail to see how this is counter-intuitive for privacy.

It makes it impossible to have an app that stores data in localstorage reliably, instead requiring it to be backed up on the app's servers.

In the browser, sure. But it prevents a number of issues with advertisements tracking people around the web.

When you use Apple Maps, Apple doesn't know who you are, where you go. There's not even a way to sign in.

It's not incompetence. When you request a route, your iPhone breaks up the request into separate, unrelated segments so Apple doesn't even know your total route. They've done work to avoid tracking you.

Call it a "marketing ploy" or "altruism" or whatever, but the fact is that Google wants to know where you go, and Apple doesn't.

Did PWA's take off? What are some famous/big PWA's now? I can't remember ever "installing" anything in a browser as an app, or even being asked if I wanted to do it. Am I misunderstanding what they are?

devdocs.io is the most successful example I'm aware of. I've never "installed" it as an app, as I don't use a browser that supports that (basically Edge, Safari or Android Chrome), but I've certainly relied on its ability to load without an internet connection for train/plane journeys.

https://appsco.pe/ has popular PWAs. They don't need to be installed, they just look and work like an app on the browser.

they really “look” like an app

The look depends on how much effort the developer invests. If you take Bootstrap, the resulting PWA looks like a website. If you take Framework7 the resulting PWA looks more like a native App (including animations and the like).

The key is the 'P': Progressive. A PWA is just a web app, but one that takes advantage of features you'd typically see in a locally installed application like local storage, notifications, etc. This might mean it has metadata to make it "installable" in browsers that support that, but I wouldn't say that's a requirement to be considered a PWA.

I'm the OP, I use a lot of PWAs. My main machine is a Surface Pro X and I don't have native apps (as in native aarch64 binaries) for many of the things I'd like to use. So, I'm using PWAs for Instagram, Twitter, Kindle, Pinafore (mastodon client), Spotify, and some of my own.

I was developing a feed reader that was supposed to be a client-side-only PWA but that's tricky.

What is spotify pwa offering that is an improvement over their regular web app? Is it offline streaming (downloaded playlists)?

Their regular web app is a pwa... thats the beauty of it. PWAs are not different offer, they are just enhancement on top of web apps. Good PWAs are invisible.

Off topic, but how is this experience using the Surface Pro X as a PWA machine? Does Windows / PWAs work well in tablet form? I was thinking of switching to a similar setup and using it essentially as you describe. Seems like it could be a really lightweight and simple computing environment similar to Chromebooks but still allows you to run traditional Windows apps as well if you need.

I really like it but I wish Microsoft would support FOSS developers better and provide more support and incentive for them to port more developer tools. There are almost no native aarch64 programming languages for Windows 10. If you keep yourself inside WSL then you're good to go because Linux under aarch64 is quite complete. On the windows side of things you'll probably running a lot of 32bits x86 apps.

Which is one of the reasons I like PWAs, they are ISA independent and are working pretty well here. Unfortunately Firefox doesn't support an add to homescreen feature on the desktop, so I used Edge to do it for the apps I want to have a nice icon for (such as spotify).

If you're going to use it much like a chromebook then it might be a tad too expensive to be justifiable. I don't regret buying mine at all, I really like it, but I'm sure they'll release cheaper ARM64 Surfaces soon, I'm betting on a Surface Go with ARM64 at some point.

Do you know a PWA for Kindle? Their browser-based reader hasn't been updated for quite a while.

Their Kindle Cloud Reader is better than the native windows app IMO. I don't know when it was last updated, I first used it this year.

The Cloud Reader isn't a PWA. It's only available as a website and a Chrome OS app. Its UI is miles behind the Kindle apps on Android and iOS, which have better footnote support and font settings.

That is true but have you seen the windows app, the one they preferred to discontinue? It was awful.

PWAs haven't taken off because Apple won't implement full Push API support in Safari thus forcing you to go through the App Store if your web site or application needs push notifications. The App Store then complains if you try to publish an app that just wraps your web site so that you can have push notifications. It's... infuriating.

Seeing all the "enable notifications" popups on every site I visit, I am happy that Apple doesn't allow this for websites.

Sites could easily only prompt this after you've added them to the home screen. Browsers could, do?, also allow users to set a default of deny all notification requests.

The problem is that developers have to spend a significant amount of time and money to get on iPhones because of Apple's policy here. If browsers and devices fully supported PWAs developers could "write once, run everywhere". Instead we have to build separate apps and deal with separate release processes. It's a huge productivity cost.

https://www.ghacks.net/2016/02/19/disable-show-notifications...

https://support.mozilla.org/en-US/questions/1208251

Further, if Apple were truly concerned with the quality of the apps in their store they would free developers from having to submit apps just to support push notifications. Less time reviewing and rejecting apps, less "low quality" apps in the store, happier developers, happier users.

The only long-term solution I can think of is to build a competing hardware company, and that’s really hard. But I’m willing to do it.

Yeah so maybe try making a real native app instead of trying to hackaround with web sites?

Apple isn't obligated to implement every single "this is now cool on web"-thing on it's platform to satisfy small niche of people who will find value in them.

Are you an Apple employee? If not, as a consumer or developer why are you not talking from the consumer's point of view? I don't want to install each and every native app. As a developer, I don't want to write and maintain completely separate native apps.

As an iOS user, I’d like you to do both!

PWAs are also useful where you want visitors to be able to access a portion of a website while offline. I run a site that hosts audio tours[1] for museums and walking tours. I use PWAs to allow visitors to quickly download the tour onto their phone in case they don't have a data plan or a portion of the tour will not have cell service.

Apple definitely makes it difficult to use them effectively. For example you need to use Safari on iOS in order to download the PWA - it won't work if you're on chrome or another third party browser.

[1]https://www.youraudiotour.com

How should PWA take off, when Apple with a high mobile market share refuses to implement basic APIs like the Push API and other browsers can't run their own engine on iOS? It is abusive, but who cares.

There's a chicken/egg issue here. Apple's support for progressive web apps has been subpar, so it's difficult to justify the extra effort in making a PWA when a major platform doesn't fully support it. Which, in turn, means people turn around and say "why should Apple support PWAs? No-one uses them!"

Twitter’s web client is a PWA

Microsoft will be releasing PWA versions of the Office suite.

Twitter, Instagram, Starbucks, Pinterest and more have PWAs as well.

Given that the OneNote web and Windows 10 apps don't implement Find&Replace (just Find), 5-10 years after their first release, I wouldn't hold my breath for usable Office PWAs.

Edit: the official help page on how to do Find&Replace reads like a joke until you realize it is very real:

https://support.microsoft.com/en-us/office/find-and-replace-...

Twitter client is a PWA.

Ok I think I'll have to rephrase the question: are there many widely used PWAs that actually go one step further than being a web app using a few of these APIs (spotify, twitter), and actually try to "mimic" desktop apps more (installation, icons, fully offline etc)?

I think you should ask the reverse question: are there many apps out there that are not just a frontend to a web service?

DevDocs is great for offline documentation, and is entirely a PWA. You just preload the doc sets you're interested while online, and they will always be there for you when you need them. Automatic updates can be enabled for when you come back online.

I think the original post is oversimplifying the new behaviour a little. If you look at the other blog post on ITP 2.3 [1] it says:

> ITP 2.3 caps the lifetime of all script-writeable website data after a navigation with link decoration from a classified domain.

i.e. the 7 day timeout for local storage only kicks in if you've been redirected from a domain that ITP has classified as one that tracks users. So, for example, web apps that users navigate to directly will be unaffected.

[1]: https://webkit.org/blog/9521/intelligent-tracking-prevention...

When will Google Analytics and Google Tag Manager get onto this list of trackers? Lots of web apps are using them.

As far as I understood this is not a "list of trackers" per se but a "list of websites that track you when you navigate to another website from them" and people don't navigate away from the Google Tag Manager or Google Analytics domains because they don't serve content with links.

So this would apply to t.co links from Twitter, for instance?

I don't know if t.co is such a classified domain but if so, if the link contains query parameters or a fragment part, then yes.

I'm also not sure if "navigation" means through user action or if redirects count, although for the purpose of tracking prevention I don't see how the latter should not also count.

So, if all of this is true the way I understood it now, the restrictions could apply to when someone reaches your site via social media.

I think confirmation in the blog post yesterday would have provided a lot of clarity.

Okay that's good but still, couldn't a domain on that list be weaponized against legitimate sites this way? For example:

- Somehow goodsite.com's user ends up on evil.com

- evil.com redirects to goodsite.com?clickID=1234

- goodsite.com's storage gets flagged

This! ^

Could someone please change the title of this post? It's rather inaccurate and spreading FUD... legitimate offline web applications are not going to randomly lose their storage abilities in Safari. Tons of people read this (admittedly hard to follow) blog post quickly and then took a nose-dive into their own hot takes.

Hoping Webkit pushes another of these posts later to clear things up.

They already have–the post referred above is old.

> If you look at the other blog post on ITP 2.3...

why would you look at the old blogpost for the new behavior?

It's all web pages, regardless of classification or redirects. The new webkit blog post is quite clear:

> Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site

https://webkit.org/blog/10218/full-third-party-cookie-blocki...

Or straight from the ITP lead's twitter:

> Fifth, all script-writeable storage is now aligned with the 7-day expiry Safari already has for client-side cookies.

https://twitter.com/johnwilander/status/1242516001939324928

(with follow up replies on what resets the seven day clock)

You're describing behavior from 2019-09-23

I see the same "oversimplifying" in webkit's 2020-03-24 blog post linked from the original post. See "7-Day Cap on All Script-Writeable Storage" in https://webkit.org/blog/10218/full-third-party-cookie-blocki...

> website.example will be marked for non-cookie website data deletion if the user is navigated from a domain classified with cross-site tracking capabilities to a final URL with a query string and/or a fragment identifier, such as website.example?clickID=0123456789.

So my guess is you are fine most of the time, except if you allow other sites to embed your content in their page. In that case, you should:

- provide the embed on a separate subdomain

- remove features requiring identification if the content is view embedded: attempting to use them redirect to the real site.

Otherwise ITP will mark your domain as tracking and wipe you after 7 days if your user don't interact directly with the site.

I have a hard time deciding if it's a good thing or not.

I guess it has the potential to be mostly a good thing, provided that:

- I understood it correctly, which I'm not sure, as their wording is not clear

- It's implemented correctly. Once the deal is done, it's in the wild years, fix or not.

- It's implemented in good faith. Apple wants to promote the app store and has shown to neuter web apps in the past.

I still have a strange bad feeling about this.

It's very confusing...

I still don't understand if Safari will delete a JWT in localStorage used to talk to different microservices.

It is confusing indeed.

My guess would be that if your user uses service site.com, calling using microservice micro.com, then you have to store the JWT in the localstorage of site.com, but cannot store it on the localStorage of micro.com.

JWT tokens are irrevocable by design, or it would defeat the purpose. I would advise against issuing JWT token which are long-lived. Using "refresh tokens" are generally more prefered, as this gives an opportunity to revoke a stolen token in active use by the attacker. Even 7 days seems like an excessively large session time. That is 7 days a stolen token can be used to forge an authenticated session.

> So, for example, web apps that users navigate to directly will be unaffected.

I don't think that's true.

I asked the head of Webkit dev on Twitter and he said:

> This time limit affects first-party storage

https://twitter.com/othermaciej/status/1242926762029285376

I have an app which isn't offline, but I wanted to make use of IndexedDB and LocalStorage to make things faster for users. Now I wonder if it's worth the effort to even try. I think this pretty much kills the utility of all local storage initiatives.

My app is an inventory control system used by businesses that build electronics (https://partsbox.com/). Deleting client-side data after 7 days is ridiculous. You can't assume that people will always log in every week, in small businesses or design/manufacturing companies there are times when 2-3 weeks can pass without building new hardware or touching inventory.

CouchDB and Amplify Datastore do delta syncs, should this get around the problem?

If you put data in IDB, it will stay there for 7 days and then if it gets deleted the delta sync would just download it again.

I see two problems: - apps with client-side-only data, i.e PWAs served from static sites - delta sync, although useful, is little help when what the dev wanted was a fast start

Both your and Apple's concerns are valid. This change makes the fact (arguably) that these local storages are caches apparent.

Some web apps already saw the danger of having an easily purge-able storage on the client side and simply implemented an export function for their tools. I admire those tools more than the ones who overuse local storage for everything.

One such tool is draw.io, a flowchart maker. You use the app, persist everything in local storage and when you are done, you export your project into a file, all happening on the client side. When you need to edit, you import the file on launch. It's portable, it's protected from browser bugs/decisions and imho pretty user (privacy) friendly.

Your demo page is 3.23 MB. ~500KB is javascript, ~500KB is CSS and another ~400KB is web fonts. The parts database is 24 KB. That's certainly not the first place I would look for an optimization target, even for customers with very large parts databases.

With respect, I believe you are mistaken about what my important use cases are like.

Not going to go into details, but that JavaScript, CSS and fonts are all immutable assets, never to be requested again, while the database is significantly larger for clients who run their businesses using this software.

I really hope the outcry about this is big enough to get Apple / Webkit reconsider. With service workers and improvements in browsers/cpus "PWA"s (aka web apps) were just getting to the point where they could compete with native apps for a number of use cases. And they had much better privacy / security policies. This doesn't completely kill that, but it's a big setback.

> they had much better privacy / security policies

Why is a PWA better from a privacy or security perspective than a native app?

Security: it runs in the browser's sandbox. Native apps by contrast generally have (or can request) full access to your system.

> Native apps by contrast generally have full access to your system

This doesn't accurately describe iOS apps, the pertinent comparison with respect to the article.

And Privacy the same: Native apps often have access to e.g. microphone. Web apps only have that for the duration that you enable it for.

The macOS sandbox exists to mitigate this. The system also goes out of its way to let you know you're running an un-sandboxed-app.

As others have mentioned this is simply not true on MacOS/iOS.

Also would add that Apple vets native apps.

Not any more. Even the terminal needs to request access to parts of the file system.

This depends on many factors but a PWA can be inspected by third-party using the browser developer tools which makes easier to find out about its communication. You can do that with proxies and other heavier tools for native apps, but it it requires more skills than the former. Also the web platform is very private, you don't get access to files and many other features without user consent. Native apps might not be like that even though Catalina is going crazy with the permission dialogs.

I mean... hang on there.

The sandbox, while questionable at first, has slowly been improving and at this point gives the same features as the web you're describing. If anything I find the APIs more feature complete, albeit less well documented as... well, let's face it, this is Apple and macOS we're discussing here. ;P

I'll also note that "requires more skills" seems like a bit of a blanket statement to me. They're just different sets of skills.

> I really hope the outcry about this is big enough to get Apple / Webkit reconsider

I seriously doubt it. Apple has been undermining web dev for years.

I'm an engineer at a platform that makes it easier to build privacy-friendly apps. This means that all apps on our platform have app-specific private keys stored on the client side (in localStorage), and they never touch a server.

With this change, you're essentially "logged out" after 7 days of inactivity.

This is pretty a bad user experience. I honestly am not sure how to mitigate this. MacOS Safari might not be a massive market, but iOS Safari is.

Any thoughts about how we should address this change?

Being logged out after 7 days of inactivity could be a little bit annoying but I can live with that, as long as I can log in again.

I could be misinterpreting your comment but are you saying your keys are simply destroyed upon this “log out”? Then I’m not really sure why your platform was considered working in the first place, if it’s tied to a specific browser of a specific device and won’t survive a clearing of storage which any user can do at any time for a variety of reasons?

No, it's not tied to a specific device. You can of course log back in, and keys are not "destroyed". We ask users to store a 12-word seed phrase, from which all other keys are derived from.

Okay, I personally wouldn’t hate logging in to a seldom used app once a week too much.

What if you don't have connectivity when localstorage is deleted and can't log in?

Eg: in a classroom.

What if someone accidentally erases everything because that’s what they’re told when something doesn’t work right? Answer: it’s volatile storage in the first place, and a tiny one at that. Heck some browsers can be configured to erase everything when closed (when operating in non-incognito/private mode).

> What if someone accidentally erases everything because that’s what they’re told when something doesn’t work right?

The difference is that one situation is controlled by the user and the other is not.

Related discussion from earlier today: https://news.ycombinator.com/item?id=22683535

WebKit blog post from yesterday: https://news.ycombinator.com/item?id=22677605

I think we'll merge today's threads. Any reason not to? Edit: merged.

I can't think of any, they're all the same topic as far as I can see. The WebKit blog post has a little bit about third-party cookies being blocked but everyone quickly moved discussion to the script-writable storage cap.

I'm confused, or seeing confusion, over some things in the comments here. "We don't use Safari in our app..." We're talking web apps: you know, web sites with functionality. You don't exactly have control over which browser your users use. And in iOS, everyone is using 'Safari' even if it's Firefox or Chrome wrapped around the rendering control. This means you have to assume that the policy affects any visitor from any web browser on iOS. Technically, the other browser vendors can siphon the data into other storage to their users' benefit, but I don't know how likely they are to do that, nor whether Apple would approve them with such changes.

Do you mean that you deploy a 'native' app that's really just a wrapper around a web view that would also be just Safari? Same policy applies, but now, you have the option, in native code, to siphon off data and put it into Real Storage.

The argument would be stronger if the post got into what privacy protection in Safari isn’t available in the Apple News app. Instead there’s a seemingly random plug for a content blocker app I’ve never heard about, which upon further inspection happens to be sold by the author.

> What are private client-side PWAs anyway?

(proceeds to not answer the question)

Found the answer: Progressive Web Apps[1]

1: https://medium.com/@amberleyjohanna/seriously-though-what-is...

Sorry, I wrote this blog post too fast because I was/am a bit angry and didn't notice my usage of jargon without explanation.

It is a “Progressive Web App”. Sorry for the jargon usage without explanation. Basically it is a marketing term used to place some new web APIs and best practices into an umbrella of a “near native UX on a Web App”. What it usually means is that your application is:

* Served from a secure context (a requirement for the other APIs anyway).

* Has an application manifest (this contains metadata about your web app and is used by browsers and OSs to add icons, names, themes, etc)

* Has a service worker (which enables your application to potentially work offline beyond what other cache solutions did in the past)

So with these in place, browsers can offer a “Install this site and an app” feature which allows the site to open in its own window, with its own icon and name on the launchers and home screens.

Thanks for your reply :) I recognize often articles are meant for a specialized audience and shared here without the author even being aware of the site, so it's unreasonable to expect that everything be described to a total neophyte, but sometimes I have to laugh at the buzzword articles that get posted here about how to implement foo in bar on baz, using a fizzbuzz framework running blarg, and I have no idea what ANY of those things are, having worked in tech for decades :D

I going to make sure in the future that I don't fall into this behavior again. :-)

Also, I just updated the post with a definition and a link to learn more about PWAs.

It doesn't scale from device to device for settings or items that should stay for longer than a week.

Local storage should be treated as cache.. it may get refreshed.

What Apple did was fine. A backend isn't only for storage either.

It is not fine if you're creating apps that don't have a backend.

Honest question - If you're creating an app like that, is a PWA really the right way to go? Aren't there other options available (such as creating a native app with a SQLite database)?

Honest answer, it depends on the app. For some cases sure, just throw it in cordova and be happy.

It is my own personal take that PWAs are more powerful than we give them credit and that they could be used for private apps without backends where you leverage the benefits of web distribution while keeping data private. Doing the native/hybrid app forces you into dealing with gatekeepers, distributing on the web does not.

Sure you can do that. But now you need a Mac, probably an iOS device and pay $99/yr to Apple. If you're just providing a small one-off solution for a particular problem that you're not monetizing, the above may pose a serious problem.

For example, I (used to) maintain a tool that is essentially a save file viewer, but must store some data for decryption of said files. It's an Electron app, but could work as a normal website for the most part as well. I got a prototype of that up and it stores the required data in local storage. I don't want to maintain and host a backend for it, and I'm not too hot on paying Apple's developer fee for it, either.

You may say it's a fringe use case, and it probably is, but it's very much legitimate. I don't know why they couldn't have made storage for longer than 7 days with an extra permission to be requested.

What if I want to create a porn app which Apple does not allow to be present in AppStore?

Can you describe this porn app which also benefits from being a PWA and doesn’t need a backend?

Well it isn't now, no, because Apple have made the platform unsuitable for it. But it was fine.

There's swathes of apps that will never be allowed on popular app stores (gambling, porn, sometimes apps that Google or Apple doesn't want competing with their own services). You can created a native app but it'll only be usable on Android.

Native applications also require acquisition of a Mac and a $99/year membership (iOS) and $25 (one-time fee for Google Play). A web application is mostly hosting costs which can be near free if you use the right cloud services.

I don't know of an alternative that will let me develop a small tool that will be free to develop and distribute, is not subject to restrictive store policies, works on desktop and mobile and is capable of things like accessing the device's camera and location when necessary.

I'm personally a fan of PWAs because they can't secretly write identifiers to my phone's SD card, they can't extract my contracts, they can't monitor my location in the background, etc. Sure, modern smartphone operating systems allow you to set up proper restrictions, but that puts the responsibility of making applications behave on me instead of on the phone.

Sure, native applications have their place (geofencing, native performance, file system access, system APIs) but in my opinion so do PWAs.

If you don't have a backend and don't want to use sqlite or something externally you can't save your data with the expectation it won't get erased. Before this change someone could manually clear storage, running out of space could trigger erasing this, etc. Now things clear after 7 days.

If you care about saving that data forever don't use local storage. Just like don't expect cookies you set on the client not to be modified by the client.

It is fine if your apps use only 1st party scripts and not 3rd party scripts.

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

A lot of "normal" apps treat local storage this way. A lot of those apps are basically a wrapper around a WebView. Why does apple accept it there but not for PWA:s?

It’s always been impossible to rely on local storage for long-term use.

Users clear their caches. They swap browsers. They swap machines. They use their phone instead of their desktop. They use private mode, or sand boxing. They re-install their OS. They buy a new machine.

Don’t be lazy. Using local storage without a backup is not acceptable.

And what kind of ‘progressive’ web app expects all the features in every client? Have we forgotten what progressive means?

Don’t be entitled. You are not more important than your users.

Based on the blog, it sounds like he wants to downloaded RSS feeds to the user's device, and not store them on his server to speed up development (all those complaints about FAANG being able to develop at web scale and him not wanting to run a backend).

Then, if the user clears cache or changes computers, they lose the stuff they were following and have to wait for new items, but it's not the end of the world. They might even expect it if you name/describe the app a certain way.

E.g. if you download an app called "Podcast Downloader" that says it just downloads any new podcasts from feeds you follow for your later offline consumption on your current device - you might not expect a podcast on your phone to magically jump to your desktop without a re-download from the original site.

Seems like it could be a valid trade off if it lets a front end only web dev publish apps he couldn't publish otherwise because he can't/won't do backend. Storing user media on the backend is not cheap. The company I'm at has spent months of developer time moving over from Google to Amazon, for example, just for infra cost improvements that come from serving terrabytes of data off one instead of the other.

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.

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.

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

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.

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.

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?

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)

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.

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.

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.

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

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

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

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.

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

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.

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/

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.

This sounds like a death-knell for my personal project: a fully decentralized collaborative task/wiki, built on ipfs, and encrypted against your blockchain wallet. I had just migrated the backend from firebase, too, and was ready to re-launch the beta next week.

Pretty much any PWA that was using ipfs as anything but a caching/distribution layer is no longer viable. This is a huge blow to decentralization technology.

Sure, you can make a standalone app, but that is going to cripple already difficult adoption.

This sucks :(

I'm coming from a decentralization tech background as well and was working on similar stuff. That's why I'm so angry at this arbitrary decisions by Apple. This is just them breaking something that has been working well.

My comment from a similar article:

Rather than wiping local storage/indexed DB data after 7 days, could you not just make it an opt in thing, like the camera or mic? For example, ask users "Allow myapp.com to store app related data on your computer?". If they allow it, then give access to local storage APIs, otherwise don't. That way users can still have fully local PWAs if they wish.

As an ardent PWA developer, this change annoys me immensely.

From the article...

> Heck, they could even go further and ban apps from corporations like Facebook, Inc., and Alphabet, Inc., that have violating your privacy as the core tenet of their business model.

If Apple were to ban the Gmail app (and obviously block web access via iOS too because that would be a loophole otherwise), I would throw away my iPhone, swear off business with Apple, and search dearly for a way to sue them.

I don’t love the walled garden iOS represents, I merely live with it in exchange for great hardware and UX. If the bargain changes to be more restrictive, I would turn against it in a heartbeat.

Thinking about that, is no surprise Apple is striking out early to make web apps useless. If they wait too long, they will become entrenched, and people will feel like they have lost something if access is restricted. Apple really wants to jealously protect its control, and more importantly ability to take 30% tax of every transaction that they can perceive.

We use local storage for features in hubs.mozilla.com when most sites would use a database, because we want to minimize storage of data in our servers to increase privacy. This basically will now force us to store this data in our database for safari users, eroding their privacy.

This is terrible...

I have a copy of my “DAT Shopping List” demo I last opened about 6 months ago saved to my iPhone home screen... I opened it, and the data was still there. I’ll be really sad when I open it again after iOS autoupdates and the data will be nuked.

https://github.com/jimpick/dat-shopping-list-tokyo

This is a serious problem for modern web experiences.

"After seven days of Safari use without the user interacting with a webpage on website.example, all of website.example’s non-cookie website data is deleted." (https://webkit.org/blog/9521/intelligent-tracking-prevention...)

Granted, this could turn out really well if the industry adopts another standard which requires user permission, overcomes this limitation, overcomes the existing limitation of LocalStorage on iOS getting automatically cleared when a device is low on storage, and overcomes the problem of sites being able to use up a lot of storage on users' devices without their knowledge.

I'd be very welcoming of such a standard. These could be good future replacements if the industry can adopt them:

https://chromestatus.com/feature/6428344899862528

https://wicg.github.io/kv-storage/

https://chromestatus.com/feature/5715811364765696

https://storage.spec.whatwg.org/

Maybe I'm being cynical here -- I'm not a web developer but have lots of experiencing managing web-based products -- but if you want to have state you should store it in the cloud, because local devices are volatile. Xbox Live, for example, uses a fairly simple service for cloud saves for games; local saves still happen but any developer has the option to push saves to the cloud. The author definitely raises good points about how it's easier for developers to not have to worry about it, but cloud saves have some hefty benefits, like multi device support, user getting a new device, etc.

The problem is (at least for me) offline apps, or for customers who have poor or intermittent / unpredictable internet access.

They threw LocalStorage and etc out with the bathwater that are cookies.

Rightfully so. We won't have a cookieless world if the entire tracking industry basically just switches to LocalStorage when cookies finally die. Enough whack-a-mole.

Yes, you're correct, but have you ever used an app that worked offline or performed well with a poor network connection? Or a website maybe provided wicked fast data access despite only having a 2G connection?

These technologies can be leveraged to improve usability. Unfortunately, advertisers and 3rd party trackers make it so we can't have nice things.

Safari already was lagging behind Chrome, Chrome forks and Firefox in a lot of feature adoption. This will only make it more of a "new Internet Explorer", a browser that sites recommend you NOT to use.

Good luck with telling people not to use Safari (or more accurately WebKit) on iOS....

You’re right. Tell people not to use iOS

https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-io...

You Apple users will put up with anything!

(disclaimer: iOS user)

Lol, 50GB unexplained mobile data consumption. That'd be 3 months worth of rent on my mobile data plan. Good luck ever getting out of debt if that happened on some more expensive international roaming.

By Gordon Kelly, who gained notoriety for his "nasty surprise" set of iOS articles he'd put out whenever there was a new iOS update. Glad to see he's still at it.

Nothing to tell. They don't have a choice.

As a web developer, I spend as much time to fix stuff for Safari as for IE11, I consider them on a similar level.

Normally when one said "the new Internet Explorer" he meant "the browser that was always recommended to use", "the browser that stopped innovation because it was almost the only one used".

The article doesn't exactly cut to the chase. Here it is:

> "...But deleting all local storage (including Indexed DB, etc.) after 7 days..."

From the Apple announcement:

> Now ITP [Intelligent Tracking Prevention] has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site. ...

https://webkit.org/blog/10218/full-third-party-cookie-blocki...

On one hand, I don't like this direction from Apple because it's meant to boost Apple's proprietary app store business -- which directly competes with the open web -- but masquerades as a privacy issue.

On the other hand, this direction keeps web devs honest: local storage, service worker, cookies and other script-writable areas are meant to be temporary.

I see nothing in any of the specs that implies local storage was intended to be temporary? You could argue cookies, maybe, but even that I'd dispute: it is a user-agent, I should be able to tell it "don't delete my stuff". I already have browser controls over my local storage: I can go into settings in every reasonable browser and flush that down the tubes.

All moves of Apple's towards privacy are tempered with the knowledge that smooth, successful webapps hurt the iPhone's business proposition.

Apple want to move you closer into their walled garden with the prospect of enhanced privacy.

The idea that iPhone apps are more private than web app because Apple must approve your apps is troublesome.

If privacy really is the thing, why can't I have an extension on ios to let me expire various cookies/storages on a per domain name basis, eg so I can write my extension to limit some cookies/storages to minutes or even seconds depending on how hostile or blacklisted such things are.

Other domains I'd actually prefer to be indefinite. I've got a notepad thing that uses local storage and doesn't store its data on the server. There's no excuse for deleting its data since its user data. Apple therefore has no permission to delete that data. Do I have a non-cloud workaround for that?

Yeah, an App. They’re kneecapping the PWA to make apps more appealing.

I wonder whether my irritation over this is strong enough to App up JustAnotherIOSWebKitBrowser with an extra API just for per site storage explicitly controlled by user. Literally to run a notepad and some kind of extension thing.

Its likely blocked by app store rules. Supporting extensions is probably forbidden.

Anyone care to be more authoritative based on their AppStore knowledge/experience?

What are private client-side PWAs anyway?

Good question. The definition of a "progressive web app" is vague. What they seem to mean is a web page which, once you visit it, is cached locally, and thereafter runs locally. The web page accesses various servers, not necessarily ones from the same domain as the web page. Persistent state, if any, is stored locally. The page gets its own icon on the home screen somehow, so it sort of looks like an "app".

Apparently "progressive web apps" are supposed to have a browser service worker so they can get notifications pushed to them from somewhere, although it's not clear why that's essential. That would seem to depend on whether the function performed requires being notified of something happening elsewhere.

Apple apparently dislikes this because they don't get to force people to use their store, with their big cut of the revenue.

Is that about right?

Does this only apply to pages read through Apple's browser, or does it impact Firefox, too?

> Apple apparently dislikes this because they don't get to force people to use their store

This is part of the motivation. The other is advertisers using persistent local storage to track users [1].

[1] https://clearcode.cc/blog/alternatives-to-cookie-tracking/

Do they block native apps that track users?

Only if you fail to use the Apple advertising ID. Tracking users is fine as long as Apple holds the keys.

> Does this only apply to pages read through Apple's browser, or does it impact Firefox, too?

This applies to WebKit, but if that decision sticks Mozilla might follow. Who knows... I hope not. Also be aware that Firefox on iOS is WebKit.

> Is that about right?

Progressive Web Apps are strictly defined:

1. The app has an app manifest describing metadata about the web app, enabling it to be treated like an app (e.g. it can be installed)

2. The app has a service worker, enabling it to work offline like a native app.

3. It's served over HTTPS.

Those are the 3 technical requirements of a PWA.

There's also the philosophical direction of Progressive Web Apps: they're progressive, meaning they offer the app's essential experience no matter the device, but enhance progressively based on the device they're running on. That is, more capable devices let the app offer more functionality without blocking out users on lower-end devices.

> By now, most people are aware of the amount of surveillance and tracking that their web usage is subject to on a daily basis and how this data can be used in ways that do not match their own personal values.

Sorry, but no way.

The data for "Local Storage" is stored in ~/Library/Safari/Databases -- you will need to give Terminal access to the Safari directory as the current Sandboxing works both ways, Safari stores security config info in this directory and scripted malware could / can exfiltrate data and change values in this location.

To violate privacy (aka enable tracking) a sub-iFrame could be set up that uses "local storage" with a parent page security policy that allows communication across the iFrame boundary. Sorry, yes, I am being a bit vague.

Who cleans up ~/Library/Safari/Databases? I personally see crud in this directory from 2011 that has been migrated from older systems.

Almost not relevant now, but Flash also had a "local storage" system that was shared across all Flash Apps. It also allowed (before sandboxing) local apps to proxy and communicate (via shared memory) with any standalone Flash App on the system through any page that used the Flash plugin -- i.e any running web browser, violating all attempts to have web compartmentalization rules.

I think some threads have been merged. I am now seeing some posts that confirm what I say above, but were made earlier in time that I had not seen. My experience and perspective is from security and privacy defense, rather than "find the loophole". [edited for clarity]

Is there any evidence that local storage is being used as a pseudo-cookie way of tracking users? If so, keeping local storage saved while regular cookies are being deleted would defeat the purpose of deleting cookies for anti-tracking reasons.

I was in the adtech world about ten years ago, and localstorage was definitely one of the things used for "supercookie" stuff (along with Flash, etags, and probably other stuff I'm forgetting).

This is exactly what it is about. I welcome the move from Apple. Web devs can store state server side. They cry because tracking will be harder now.

I'm the OP and I'm crying because I'm working on apps that don't have backend so that your data is yours and never leave your computer. This is now impossible for WebKit users.

So you have to track Apple users now if you would implement backend storage. How ironic.

Exactly. Now I'm working on PWA that stores address data locally and now I have to have a backend db just for Apple users.

Sorry if I sound rude, but my conclusion from your article is that the problem here is you don't want to assume the costs and resources needed to build a backend and blame Apple.

Please read the HTML/Web Storage standard [0] and try to find where Apple is not honouring it.

Even before this move by Apple, you should already had to consider localStorage to be subjected to being wiped by actors not in your control.

On top of that, localStorage privacy concerns were also in the standard. See section 11.4.1 [1].

Nevertheless, I reckon Webkit should expose the option to the user.

I feel your pain, I really do, but I can't see how Apple made PWAs impossible.

[0] https://html.spec.whatwg.org/multipage/webstorage.html#webst... [1] https://html.spec.whatwg.org/multipage/webstorage.html#priva...

> Is there any evidence that local storage is being used as a pseudo-cookie way of tracking users?

Yes [1].

[1] https://clearcode.cc/blog/alternatives-to-cookie-tracking/

Our 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 our resources to try to bypass Apple's technological decisions but that they should contact Apple for further information.

We then link them to a $30-$50 Android device that they can buy on Amazon and use as a second device to use our services "if they are interested in a more powerful web experience". We provide a basic version to all users, but put a shamewall for advanced features. Best use of our time and resources.

It is time to push back, stop making Apple's problems your problems. Educate people without ranting and offer them solutions, developers have the bad habit of trying to cover up this kind of non-sense and taking the blame while really Apple are the ones who should be ashamed. If people love your product/service getting a $30 phone to be power users and make their life easier and their experience richer will not be a big deal for them. It's all about educating them the right way.

What technologies does Safari not support that you need?

That’s a genuine question by the way. I’ve been frustrated by Apple’s reluctance in the past but since they implemented Service Workers things have gotten better. I still really wish they had Web Push but I do understand at least conceptually why they’d be hesitant.

Web recording api. Only works in safari under a flag - they won't release the feature to chrome/firefox.

Obviously I have no idea what your product is but if I got that message I'd just likely go to one of your competitors (assuming they exist). I wouldn't go and buy another device unless it was for an absolutely critical application.

It's a win win.

OP doesn't need to spend excessive money on developing for a Evil company, and those who buy their products can go to a competitor with a more expensive product.

Nearly everyone has at least one non apple product, so it seems like it would be a problem for a limited number of users.

OP, you are doing God's work.

> assuming they exist

And that's the real nature of the market, isn't it? If enough third-parties aren't willing to play by Apple's rules, Apple will have to modify the rules.

They're a stubborn company, but it's happened before. They've also been burned trying to own a standard when a common consensus exists they can't control before.

Exactly. It sounds to me like websites that refuse to load in GDPR countries. Good, if you can’t support me I don’t need to support you.

90% of software engineering (or engineering in general) is finding solutions for difficult problems. Throwing up your hands and saying you refuse to support one of the most popular computing platforms is certainly a decision that any business is free to make, but then again as a consumer I’m free to make my own decisions as well.

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.

> Our company has started shaming iOS

Why isn't our product taking off?!

I would have to REALLY love your service to want to carry around an extra device to use it.

... or find it really necessary. Banks, for example, have the clout to expect this kind of behavior. The built-up reputation and long-term partnerships a company and a bank build up can out-value all kinds of IT inconveniences.

I don't know if you meant from the consumer perspective, but if my bank started telling me what kind of a phone or computer I needed to have to use their services I would definitely find another bank! I'm not sure if clout is the right word for what what banks have, it's more like a kind of lock-in because of having to sign a million pieces of paper to change banks, that makes people put up with a certain amount of IT inconvenience, coupled with the fact that usually the competition is equally inconvenient.

You might, but there's a long history of bank websites only working in Internet Explorer, and it was only in recent years that this changed.

My bank logs me out after ten minutes of idling, not seven days. Not sure what kind of crazy bank allows you to persist login session / personal data indefinitely.

I was responding specifically to the question "I would have to REALLY love your service to want to carry around an extra device to use it." Some people's banks require their users to carry around a rotating 2FA key dongle, for example.

Which is included in the cost of opening an account with the bank, you're not told to go buy this device off Amazon.

In addition to what others have said, I think the effectiveness of this likely depends heavily on the target audience - to a non-technical user, this will probably come across as lazy. From their perspective, everything else works fine on Apple, so you must be complaining about nothing.

Of course, if everyone did the same, people would start to realise the problem might be with Apple, but the chances of all (or most, or even many) big web services deciding to alienate such a large portion of their (potential) customers seem slim.

It very much depends on the market.

In the general case, almost all websites and web apps don't need offline storage at all.

But the ones that do often need it for very business-enterprise reasons, and here Apple is taking a bit of a risk. I've watched companies hang onto old versions of Flash well past the sell-by date because for quite some time, it was the most practical platform to build a cross-platform videoconferencing client in. And once it's built, the opportunity cost to throw it away and switch to [OTHER_TECHNOLOGY_X] matters.

> If people love your product/service getting a $30 phone to be power users and make their life easier and their experience richer will not be a big deal for them.

So you're suggesting shifting the development costs of you building a native / cross platform app directly to your customers? Does this work?

Are you aware of the poor security a $30 phone has?

What did we expect? I mean how long is it now that Apple refuses to implement the Push API properly (which in turn is a basic requirement for many PWA use-cases). They clearly try to use their influence to defend their App Store revenue. And to make it look good, they do it in the name of privacy.

Offline 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. PWA) that are installed on user's desktop should have a bit more permissions than websites but people in charge(google, apple etc) seems to think otherwise.

https://discourse.wicg.io/t/proposal-full-network-access-in-...

Read the article, it's not only about offline PWAs. All local storage is deleted after 7 days.

As for as "persistence" is concerned I really care only about offline PWAs. Why would a website need offline data after 7 days? It would improve performance, that's true but everything else should be "fresh" unless that said website wants to actually behave like an "app". Maybe the "website" should ask the client to be installed as "app" if the user wants to take advantage of persistent storage(and other "app" features) . Asking the user to install(which is actually just a kind of bookmarking for PWAs) isn't that much of an effort if the user is planning to use it regularly.

> Why would a website need offline data after 7 days?

JWT for example.

I made one of these. We generally expected users to be offline for at least a week. Probably using the app regularly on their respective devices (but possibly not), and syncing data again when they had a good internet connection. Uses Dexie and React, syncs with a horrible Drupal site. It's always going to be uncertain to rely on a database held at arm's length by the browser, but in practice it worked incredibly well on all manner of devices. I guess it won't anymore. (Thanks, Apple!).

This is absolutely a necessary change on some level, but I think if Apple wasn't in complete control of a web monoculture (and obviously uninterested in anything that doesn't sell more iPads), it would be possible to steer this API towards that without breaking a bunch of peoples' stuff.

I think this is a good idea. Developers should not be able to store something on my computer indefinitely without my consent. This doesn't apply to applications users add to their home screen.

This doesn't "destroy" the PWA ecosystem. Just makes a user's intention explicit when they save a PWA to their home screen, rather than continuing to use it within the browser.

From the WebKit Blog (https://webkit.org/blog/10218/full-third-party-cookie-blocki...) "Web applications added to the home screen are not part of Safari and thus have their own counter of days of use."

Your browser is already caching a whole lot of stuff that you don't know about just by visiting a site.

A little LocalStorage isn't going to hurt you.

Cookies I get, but I don't know of any dark patterns with localstorage / the benefits are pretty great.

I asked about the dark patterns above and got answers confirming it https://news.ycombinator.com/item?id=22687214

I'm not convinced that actually confirms much.

One of the pages linked there just says local storage is used to store stuff... yeah? It's still not as wide open as cookies.

You could use local storage while doing other things, but i'm not convinced it's a serious issue with tracking or etc. ... and if ANY storage is considered an issue I think we're in for a big snowball effect on what we should or shouldn't allow from ... anything, including native apps, etc.

push messaging also doesn't work for PWAs on ios

(it does on android)

I get that controlling the walled garden is apple's mobile strategy now, but this is costing developers so much blood sweat & tears.

Both xcode and android studio are heavy + horrible compared to web, and the fact that you have to use both tools to release at scale makes them worse. Shopify wrote a dev post a few months ago saying 'we're react native as much as possible now' and claiming it makes life easier, but react native is worse than PWA because you still have to build for mobile 2x and deal w/ app store nonsense.

If PWAs supported push on ios, with or without cookie expiration, they'd be the preferred launch strategy for most non-game apps.

Hasn't aggressively controlling the walled garden always been Apples strategy? I don't see them changing any time soon. iOS didn't even have an app store initially, and it took a lot of pushing for that to happen (they realized Android was going to eat their lunch if they didn't).

This "feature" also invalidates the use case for WebCrypto API, since a user's keys would be stored in IndexDB, which now means keys cannot be safely persisted.

Exactly this. Most "non-custodial" web wallets will die as a result of this change (some may even lose money/assets). Very unfortunate Apple!

Since when was software freedom synonymous with we should all want to use PWAs?

I’d be happy if Spotify gave me an API key and essentially went away except for a monthly bill.

But software has to be a product the masses get first to get made in our world.

I’m glad some folks are having their itch scratched but free streams are more than enough and I can wrap them for consumption as I choose.

Once again building your life around importing someone else’s priorities turns into an exercise of despair from not learning how reality doesn’t stand still no matter how hard you hope it will this time.

Is this really that big of a problem? You had to be expecting that local storage is deleted without any notice anyway, in every web app.

I have many useful files in my computer, which I don't want to be deleted. You are saying, that it is ok, if the OS deletes all files in my computer from time to time.

A local storage is the only way webapps can store any data in your computer (other than asking you to manually load / save some configuration file). Not all webapps can afford cloud storage for all user.

I am not saying that it is OK to delete all your files. I am saying it has always been like that in the case of a browser's local storage.

As I said, that use case was out of the window long before. From the start, as far as I know.

No browser has ever given you any definite promise on whether your local storage data will be kept. That's also true for IndexedDB. So you need a mechanism to restore that data, be it cloud storage or something else.

If you wanted to support Safari private browsing, you even had to deal with local storage not being available _at all_.

I'd love for browsers to have an opt-in mechanism to preserve that data (also snapshot/restore/import/export it).

I bet there's tickets in both Google's and Apple's bug trackers from 2012 asking for that.

There should also be an reliable upgrade mechanism, so the app alway upgrades successfully and completely, no intermediate states where a network or other error would prevent offline functionality from working.

I disagree. The IndexedDB was introduced as a permanent way to store data (which is not deleted after closing a website). As it is the only available standard for permanent storeage, I think it should be deleted only if the user asks to delete it (the same way you delete any other file in your computer).

Of course, browsers are free to do whatever they want. But the user can (and will) switch to the software, which does what he or she wants.

You disagree with the status quo implemented in browsers or you disagree with the decisions that were made years ago (by browser vendors), because you basically cannot guarantee for that (disk full, privacy settings, private browsing, etc.)?

It's different if there is a technical limitation (disk full - computer tend to barely function in this state anyway), or the user has opted in to ephemeral storage. But to not give users the choice to store things permanently is quite a severe restriction.

Browsers keep IndexedDB data indefinitely, they don't delete it.

There is no guarantee that the data will be persisted permanently. Users can erase it by mistake easily using privacy settings. There's also quite ambivalent size restrictions. And last but not least, Incognito mode, which also is implemented in a number of different ways in practice, depending on the browser.

Basically, you cannot be sure that you can use it to persist data at all.

Size restriction will cause error at write time, it won't silently delete data. User error is user error, that's it. I know user who was deleting files in his Windows directory to free some space. Incognito mode is not intended for web apps usage, it's more for porn and things like that, I don't think that it's very relevant.

It works for majority of standard cases and when it does not work, user will receive error message, so he'll be aware. Not the case for Apple devices anymore.

I absolutely don't have that expectation. I built a comic reader app that I use on my Android tablet, which saves files to IndexedDB. I've been using this for over a year and no files have ever been deleted, even after I stopped using the app for a month or so.

If Apple provided an alternative this would be ok. An alternative such as the native file access API (still a WIP). Or a prompt so that the user can allow long-term storage. Or supporting the web app manifest so that users confirm they want to "install" a web app, granting it greater permissions.

But they've offered no alternatives here, that I can see. They've determined that client-side web apps are simply not important.

Hint: they are a for profit company and want you to pay 30% of your app revenue. Don't expect any open web standard that can actually compete with native apps unless something in the market changes.

Wait, does that mean that the only way to keep a login session for more than 7 days will be by using cookies? This seems like a terrible idea. Cookie authentication doesn't make sense in several scenarios, especially when working in a CORS context.

For webapps that keep a session token stored locally, this will be inevitably wiped, so users will have to re-login after that time. I can already hear the complaints coming. Should devs now build a back end just to keep the token, and connect there with a cookie?

Actually, Apple has crippled non-PWA apps. I agree that Apple does seem to not want PWAs to succeed based on my experiences with them on my iPhone, but on the other hand this effectively does not apply to PWAs that are added to the user’s home screen since the counter only runs every day Safari runs but homescreen sites have their own counters.

I worry that 7 days is too short of a period even then, but I do agree indefinite local storage does not make sense in most cases.

How would static "single-page" apps (HTML/JS/CSS) that store session tokens in localStorage avoid 7-day auto-logout?

Perhaps using something like this: https://developer.mozilla.org/en-US/docs/Web/API/Credential_...

Anyone know of other Web APIs that could be used?

might have to use cookies

Cookies are a lot safer for authentication than localStorage. The only problem with this change is persisting data for offline use, not authenticating the user.

I'd rather use a native app than a PWA any day of the week. The experience of a mobile web app is clunky, slow, typically ugly, and just a generally bad experience.

Offline web apps are direct competitors to apps from the Google play store and Apple app store. You can't expect Apple to be fair to them if they are missing out of their 30% for every USD of revenue on those web apps.

This just sounds like a great reason to not use Safari. I switched to iOS recently, but I’m a dedicated Firefox user, so I personally don’t touch it except when I’m forced to by other apps opening links. (I was honestly REALLY disappointed in Apple when I realized that you’re not allowed to set a default browser besides safari, but that’s another story)

Forgive me, I’m a long time Android user, but do a lot of people choose to use safari as their main iOS browser, or are the usage numbers inflated because of the vendor lock in?

All browsers on iOS are webkit (read: safari) under the hood. Firefox and Chrome are just skins.

Thanks for correcting my ignorance :) that makes more sense.

np! It's quite a frustrating state of things.

To be clear, only the rendering engine is fixed on iOS. Chrome, FF get some leeway to build other bits of the browser themselves on iOS, such as the netstack and the UI. But all new web features are limited to what webkit supports bc, well, it's webkit.

"do a lot of people chose to use safari" No. On iOS, www = safari to almost all users.

Thanks for pointing this out. Always had Android before, now I see.

I don’t remember ever seeing this usage pattern in the wild? As far as I understand, it would always have resulted in data loss whenever users chose to clear browsing data. There also wouldn’t have been any natural way for backups or synchronization.

A browser plugin might be one way to achieve something like this. Personally, I really don’t care about the data my feed reader has, so I wouldn’t mind even public data storage backends, like gist. Or steganographically encoding my list of feeds and uploading it to porn sites :)

Why not let users give access to that one site use data older than 7 days? So data stays but its only being deleted if you click that it can access (first time only - next time it remembers)

I commented about this in a different thread about the same topic earlier today, but I'll post here as well.

I can understand Apple's decision to do this, as there's a lot that can be improved about offline storage on the web:

* asking for user permission (i've seen demos try to exhaust the users' storage, and trackers can use this to invade privacy) * async writes and reads

However, making a change like this with no suitable alternative leaves PWA developers stuck in a hard place. I'm not sure what can be done in the short term here.

There's a few web specs that address these issues. I'd love to see them come further along, and maybe improve things for developers and users in the long run. If anyone knows, is there anything that members of the community can do to support these efforts?

https://chromestatus.com/feature/6428344899862528

https://wicg.github.io/kv-storage/

https://chromestatus.com/feature/5715811364765696

https://storage.spec.whatwg.org/

A bit offtopic, but the following is my basis for interpreting privacy-related claims from Apple.

I noticed a text editor I bought from the Mac App Store, iA Writer, includes silent spyware that transmits your activity back to the developer without notice or consent (thank you, Little Snitch). Apparently, I "consented" to this in the Mac App Store ToS (right).

When I left a negative review on the app, their response was "we aren't doing anything not permitted by Apple in the App Store".

I don't use App Store apps any longer, and I take most of what Apple says about privacy with a huge grain of salt.

PS: OSX phones home to Apple in about a dozen different ways even with iCloud entirely disabled and all reporting/telemetry/feedback options turned off during the OOBE/setup. Try doing booting a fresh install of macOS with Little Snitch, but disable the Apple/OS exemption in Little Snitch's rules. I was astounded. Dozens of things.

I wonder if there's any major, widespread GUI OS in a default configuration that does not transmit to your ISP and third parties (including government snoops) when you open a local text file to write. I block all of these requests; most do not.

I am reminded of Winston Smith's paper journal.

There are still people who believe Apple cares about the web platform, 12 years after they forbade browser competition on iOS ?

How does this make sense logically? Obviously the websites that you use the most have the biggest potential and opportunity to track you. All local storage should be deleted for the most used websites at random times, at avg. several times a week, without any extensions caused by recent website usage.

If this is done for privacy's sake, that is.

> All local storage should be deleted for the most used websites at random times, at avg. several times a week, without any extensions caused by recent website usage.

No matter what browser vendors do, it will never be enough for "privacy" activists.

I don't understand what the problem is.

I can easily go to the settings area and delete my entire browser cache (Remove All Website Data), in fact if you are running low of space it even tells you to do it.

Why are people assuming things stored on a browser are a good place to store things. Nothing stored on a browser should be assumed to be forever.

If you read the article, that's the issue the author was talking about: it's basically impossible to make an app that can store its data locally, instead of on some web server.

All apps that you download from App Store can live offline, where they're usable without Internet or trusting some faraway web server.

You can't make a web app that can do that, and to some people it smells like Apple trying to force developers to release through App Store.

I don't really understand this. If you want to make something local, make an app and distribute through the app store, that's what it is for. A web app on the other hand is connected by definition, no?

Apple forcing local apps to distribute through the app store is a feature.

People keep wishing for a loophole. There isn’t one they won’t close sooner or later.

A feature for who?

Not for users - now there's one less avenue for developers to get them something they want.

Not for developers - now they have to jump through additional hoops to make something that works cross platform.

Who exactly does this benefit?

Users want to be able to log in and see their data from any device. If the whole idea is that there is no server that the data is stored on, then you can't have a sync function, can you?

Do any of you have an example of a good offline-only PWA that will be affected by this?

The whole point is that you don't need to download a big payload just because you haven't used it recently.

There are two ideas that go together well:

* The app can work offline

* The app doesn't need a server to function

Neither of those prevent a sync function from existing.

Right now, apps can do both of those. Why don' we want PWA's to be able to do the same? Why do I have to go through Apple's walled garden in order to so? Especially when said alternative is in a sandbox?

It means you constantly have to re-login on a PWA (e.g. Twitters web client PWA).

Constantly being weekly at most frequent in this case.

I roll my eyes every time robinhood makes me login again after an app update... though it hasn't happened in a while, so maybe they fixed that bug, but it was annoying when it's an unexpected hurdle that doesn't follow what other apps are doing.

Games with your personal high scores. Is the one that would affect me

Plus a local note-taking app I created a while ago

The whole point is that those PWAs probably never got built in the first place because the foundations were always shaky at best. It's a chilling effect.

But if you look at native apps, especially ones I use on desktop OSes, they're dominated (at least in my usage) by offline-first or offline-only apps---and for me, this is a feature, not a bug. This doesn't have to mean they don't have sync, by the way, it just means that's separate from the main functionality of the app.

A perfect example of this is Dropbox: it syncs to your local disk by default. It's easy to forget how valuable this is until you go camping (or similar) and suddenly you realize you forgot to star that one directory you care about. Now your mobile phone is useless, but your laptop works no problem. And due to this being factored out into a separate app, all my files now work regardless of file type (I don't need separate offline support in every app I use, since that's the default).

It's no less of an issue for an online-based PWA. Where do you store login credentials or session tokens? In local storage. What happens to them when Apple decides to arbitrarily throw it away? The user has to log in again and again.

This sounds like a seriously poorly thought out idea. Want to clear tracking data from random websites I've been to? That's great. But you don't mess with the data stored by apps I have specifically _chosen_ to install on _my_ device.

But only if they don’t interact with it for a week. I wouldn’t be surprised if a web app I hadn’t used for a week required me to login.

There are many apps on my phone that I only use every once in a while, yet every single one of them remembers me. No matter how long I've been gone. Technology is amazing!

Where is Apple's famous UX here? What legitimate argument is there for clearing data of an app the user has added to their home screen?

And most native apps crash one a week, we should therefore automatically crash every app once a week.

Just because current apps are buggy doesn't mean we should enforce those bugs at a platform level.

I wouldn't be surprised but I would definitely be upset.

It doesn't have to be that way though, that's the point of PWAs. A way to use web technologies for local applications.

So you can think of absolutely no situation where a user would access a web app, and might want to store state info locally?

I can personally think of cases (not that PWAs have ever been anything but fragile when it comes to locally stored data), but as a user, the occasional clearing of super cookies is a bigger boon.

I don't disagree that local data for PWAs has always been fragile. I wished browsers were taking steps to make it less fragile, as opposed to more fragile. It would allow certain use cases to become valid for PWAs, thereby circumventing the need to create a 10mb native app for something that can be deployed much more easily and quickly with 30kb of Javascript.

Respectfully, I haven't visited an online SPA with under 100kb of Javascript in a very long time. Anytime I care to look, they are almost always in the 5mb range.

So, an offline app's size, when compared to just browsing the web, isn't a compelling difference (especially since it's downloaded maybe once a month or so).

> A web app on the other hand is connected by definition, no?

No, it just has to run in a browser.

Well it needs to be downloaded from the internet at least the first time, so it's intrinsically going to be less secure than an app that you can guarantee never connects to the internet.

Your app needs to be downloaded the first time too. In fact, a downloaded app can run riot on your filesystem. A web app runs in the "cage" of the browser, and is arguably more secure and explicit about permissions it requests.

"... can run riot on your filesystem"? Citation needed because an app is as heavily sandboxed as a web page running in a browser. An ios app gets no view into anything you as a user don't choose to give it (no access to photos, etc).

I mean, if you give the app access to your filesystem (which a lot of non-tech users would, almost without thinking), it can potentially access/modify/delete your files and folders. With PWAs, that's not really a possibility.

Stock iOS doesn’t allow apps to directly access data from other apps afaik

Has to come from somewhere. A pwa might have to come via http (I'm not sure) - but html+js+css can come from the (from a) filesystem too. Like an USB-c memory stick.

Or from an extracted archive (much like a native app).

> A pwa might have to come via http

They can't, PWAs can only be served over https

Apple's app store is a walled garden. The web isn't a walled garden. TFA wants to be able to operate outside the walled garden.

EDIT: Also, it's probably cheaper to develop one PWA than a PWA + N native apps, even if N=2. Probably lots cheaper. Now, perhaps there's a way to build a native app that is just a wrapper around WebKit/Safari and a PWA, but you'd still be subject to Apple's walled garden. For example, think of Gab or some such website whose apps have been banned by the various app stores...

> A web app on the other hand is connected by definition, no?

No, not in the era of "progressive web apps", which is really just a little bit of branding around interconnected APIs. The Cache API in particular means that a webapp can be downloaded and made available offline on a permanent basis. Unless it isn't actually permanent at all, which is what Apple are doing here.

The web and the App Store are just delivery mechanisms for code with different trade-offs built into them. Apple have added an extra trade-off on the web side in the name of privacy.

Personally I would never expect a web app to be available offline on a permanent basis.

Okay?

I basically assume my phone is nearly useless without connectivity. And if I want something to work in that sort of environment, it better be a native app.

Okay?

...I guess I don't really see why the current state of things should block any future development. Browsers shouldn't ever implement new features because users today aren't expecting them to exist?

To an end user there’s an icon on their screen, they tap it, the app opens. It didn’t matter if they downloaded from the AppStore or from a website. This is no longer the case which is why the OP is upset.

Pretty sure it is still the case if they have connectivity...

I actually have an old phone that I used as a remote-control for my home-threater PC. No connectivity needed, but the phone did everything I needed. Move the mouse, act as a keyboard, and mostly raise volume / change channel.

Phones are computers. Even if you remote all connectivity to the outside world, they still function as well as any PC from the early 90s (or earlier). A huge amount of compute power, tons of storage, etc. etc.

Its not, at least not based on how the OG article is written. If you open your bank app it automatically tries to log you in if you saved your credentials in the past. This seems to say that if you don't use the app for a week it'll wipe that out. No one expects that.

That's not how I read it. Odds are my bank isn't using local storage for that.

Let's say you use an app that allows you to add Todos. You've added 30 Todos. No internet needed, it's always just worked. You go on vacation for 10 days. You get back, you open your app. No Todos...all gone. Very simple use case that is now broken.

Yes, you as the user could wipe those out. But now Apple is doing it just because you didn't use it in 7 days. And the user will not blame Apple, they won't even know Apple did that. They will blame the app developer, who in the interest of privacy didn't want to push your personal Todos to a database online.

Again, just a contrived example, please don't go down the road of why a server should have been used. Let's stick to the use case described.

That's just a failure of your imagination, though. The world was not always as it is today, and it is not bound to be so in the future.

Having worked on a cross platform application that defined the UI via HTML I'm still kinda confused about this use case - it's super trivial to wrap a set of HTML + JS in an app that's essentially just a full screen webkit/whatever window and distribute this.

The advantage of PWAs then seems to be the ability to dodge the app store certification which, while onerous, is not a bad thing for your clients.

This is equal to saying “I’m ok with Apple having a censorship monopoly of what an iPhone can run”. I don’t think the majority of people here would agree with that. I also don’t think users buying a device that is supposed to support web apps would be happy to find out that in fact it doesn’t. I’m one of those very unhappy users.

> [...] is not a bad thing for your clients

Except when you have to pass some of the 30% Apple fee on to your clients.

That's the same era as the "year of the Linux" desktop. I keep hearing "PWAs will win" for ten years now. Some people just want to use ill-fitted web tech everywhere, because that's all they know.

No, it's a grab for money. Releasing an iOS app requires Apple hardware, X-code, and an Apple developer license which is $100/yr.

Where as developing a PWA can be done on any hardware, and would be natively cross-platform. An offline PWA does not require an active connection, and in fact is the one of the reasons behind the idea of developing a PWA instead of a general webapp or website.

All other browsers allow the use of local storage to optimize and enhance your experience by allowing things like pre-loading data or storing your preferences. This disappears with the decision Apple made to clear storage.

I promise you that Apple does not give a shit about the revenue from the developer program.

Then why not make it free?

That's easy. It adds a hurdle for people who make malicious or fraudulent apps. It's not free, but neither is it MSDN levels of absurdity.

I'd counter that: make it a one time tax, like the Play Store. Is it reasonable that I need a Dun and Bradstreet number to write an application for my computer?

It's not just about the revenues of $100/year. It's also the revenue from 30% sharing of profits. And most importantly, it's the bigger revenue generated from having apps that work only on iOS, which drives users to buy iPhones and iPads.

A PWA app isn't going to generate any 30% revenue share for Apple since no one is paying for it in the PWA case and thus likely won't be paying for it in the pure app case either.

Why would no-one be paying for a PWA? There are countless paid-for services available via web apps.

Providing even a free native app via the App Store to access a service with a subscription model becomes a very risky proposition given Apple's rules, though.

Can you give a few examples of paid-for PWAs? Sure there are websites that are paid-for, but I've never seen a paid-for PWA.

I'm posting pseudonymously here, so please forgive me for not citing personal examples, but the normal web apps for accessing quite a few popular services are now PWAs. Spotify famously started looking into using a PWA after some issues with Apple regarding the cut taken with a native app. Uber is another well-known example.

Financial Times[0] is a PWA and with a paid service option.

[0]: http://app.ft.com/

(Looks at home screen) Slack, Jira, LastPass, and Netflix. All Native apps that are free via the App Store, and all with the subscription model that I pay for. And for most of those I can’t even buy the subscription from inside of the native app, so Apple gets no money from these

And for most of those I can’t even buy the subscription from inside of the native app, so Apple gets no money from these

This is where things get pretty shady with Apple's terms for native apps and the App Store. Take a look at Spotify's experience for a different version of the story.

Exactly. The app store's gross revenue was $54 billion last year. [1] Apple has a very strong incentive to make sure the only good way to deliver apps on iOS is the app store.

[1] https://www.statista.com/statistics/296226/annual-apple-app-...

Interesting numbers. I see, "gross revenue" means:

> In the last reported year, customers spent an estimated 54.2 billion U.S. dollars on on in-app purchases, subscriptions, and premium apps in the Apple App store.

So, roughly 30% cut goes to Apple - which is around 16 billion; and developers got the rest, around 38 billion.

With PWAs, 100% goes to developers. As you pointed out, that's a threat and motivation for Apple to continue racheting up their closed ecosystem, and keep PWAs crippled on Apple devices.

Yes, and they shouldn’t be taking a cut. Their services initiatives are bad for them and the users of said services. But as someone who did two tours in their services arm, it is overwhelmingly likely that the reason that WebKit is making these changes is their stated reason of making Safari more resilient to the attacks on their users vectored in by web badness.

Does Apple also not care about the huge cut it takes for everything sold via the App Store?

As lliamander said, if they don't care, why not make it free? I don't for a moment believe the argument about creating a barrier for negative actors. They could still screen apps before allowing them into the App Store, and if that mechanism is working reliably then the charge is unnecessary as a deterrent, while if it is not then the financial deterrent isn't going to be enough to stop a lot of people willing to make these kinds of apps anyway.

They care about they revenue they get by making people buy the hardware that gives them access to the developer program.

I think you missed the "requires Apple hardware". I know that rich Americans think everyone has Macbooks, but that is not the case.

You should research the original plan for "apps" on the iOS platform. There was no "native app" story originally, and Javascript-based applications were expected to be the only 3rd party platform on the OS.

As should you. It’s not that an app ecosystem was never planned, it’s that it was not an early priority. Remember they were literally defining everything at the beginning - OS, UX, APIs, core features, hardware, first party apps, market positioning, etc etc. Needs of third party developers weren’t nearly as important as nailing the basics and ensuring a risky project was a success. The html5 app bit was a way to test the waters for developer interest and demand but very much an interim solution.

How do you square that against all the reported accounts (including the Isaacson biography) of Steve Jobs saying that he was opposed to third-party native applications on the platform?

Yes, they changed direction in 2008. That's just it, though. They changed direction.

Jobs’ hot takes aren’t the end-all when it comes to product intent at Apple. He was basically an embodiment of strong opinions weakly held. His superpower was focusing teams on what the right set of features would be to create a product that made sense to the market, and ignoring everything else. The phone / iPod / internet communicator trifecta was example of this - nothing but nailing those three mattered at launch, and any effort elsewhere was wasteful. Without that kind of leadership, eng teams will often dither efforts over many things that don’t matter to success.

The history of Apple is filled with examples of this dynamic. iPhone was a group effort among many talented and influential people and I doubt Forstall and others driving software had same opinion on third party apps. They just didn’t pick that battle before it made sense to. Every other computing platform at the time (including Windows Mobile, Palm, and BlackBerry) supported third party apps, it’s not like the use case was novel or difficult to see, and the webs limitations were considerable. Adding apps was a default path temporarily set aside.

That was not the plan, that was the stopgap. Apple (and even more the networks) were very scared that native apps would have unregulated access to the radio, and would mess with the cell networks. Web apps were the quick-and-dirty way of putting third party apps into a sandbox while Apple worked on APIs that would enforce that sort of sandbox for native apps (what they have now).

> If you want to make something local, make an app and distribute through the app store, that's what it is for.

Have you ever gone through the app review process? It can be frustratingly capricious, which makes it very expensive. We've had features in our app for years, displayed in plain sight, and then all of a sudden they decide to block an update because of these utterly innocuous features. No rhyme or reason, and now we've got to spend dev time fixing a "problem" that never was a problem before. And we have to delay our entire update because of it.

PWAs offer a way around that uncertainty and added cost. There's also the cost of a developer license, and the Apple hardware you have to buy to run XCode (and probably iOS devices too, so you can test IRL).

"Apple forcing local apps to distribute through the app store is a feature."

Forcing companies to give Apple 30% is not a feature.

If companies feel they can deliver a net experience in webapp that's better than an app, then so be it, it's their choice.

App makers are smart enough to know what makes sense for them.

At one point, Apple was denying some app store reviews because they said they should be distributed through PWAs instead. If this is supposed to be a "feature", it seems like some product manager has their head up their ass.

Also, the entire point of PWAs is that they are supposed to have feature parity with local apps, but delivered via the browser. This change is obviously counter to that goal.

Who are the “some people”?

Are any of them outside of chrome’s WebWorker team, or the community of devs that were suckered into a model that really has never gained traction for iOS?

I’m sort of sympathetic to the devs who bought in to the solution, but this looks an awful lot like a pr pressure campaign that is unhappy with how this affects googles disintermediation goals.

It didn't gain traction because iOS killed it. Also "some people" includes everyone who doesn't want to make an iOS app.

If you read the update from webkit.org, you'll see that it's still quite possible to store data locally.

Link: https://webkit.org/blog/10218/full-third-party-cookie-blocki...

Relevant quote (emphasis mine):

If a website hasn't been used for 7 days, I'm happy for its data to disappear and save space on my device.

7 days is actually a really short period. There are lots of apps and websites that I only open on my phone every now and then. I would never use them if I had to log in almost every time.

If a website hasn't been used for 7 days, I'm happy for its data to disappear and save space on my device.

You might be, but maybe not everyone is. I've worked on apps based around multimedia content where downloading in advance to watch or listen later was a big deal, because a typical user also travels a lot and might well be going away for longer than a week. Even if they can get the same data again next time they're online, it might still be much slower and more expensive for them to do that on an international data plan instead of back home.

Then wouldn't it be appropriate to offer a native app to offer that functionality? A web browser in 2020 is a place to run vast swathes of untrusted code safely; it is not a digital workstation platform, that is the job of the OS. If what I am downloading from you is important enough that I want to have it even offline, then I trust you enough to install your native app.

I believe this entire statement is wrong in 2020. There are literally OSes now that are just browsers.

The fact that that is possible does not change the role of the web browser in the modern computing experience. If you want to build an entire VM that runs in Electron, be my guest, but that's orthogonal to the issue of how Safari should handle storage by default.

The fact that that is possible does not change the role of the web browser in the modern computing experience.

But why shouldn't new possibilities change the modern computing experience or the role of browsers within it? Millions of users are benefitting from new capabilities of modern browsers, even if they don't know the details any more than they know what goes into any other software they use. Why is local storage of data, or the idea of a PWA more generally, special in this respect?

That's been true for years, and yet the operating systems that aren't just browsers seem to be getting along just fine.

A web browser in 2020 is a place to run vast swathes of untrusted code safely; it is not a digital workstation platform, that is the job of the OS.

I'm not sure how much that assumption really holds any more, nor why it should necessarily continue to do so even if it has so far. Technology evolves, and so does how we use it. In the case of the web, and web apps in particular, they have evolved to satisfy a need for convenience in software distribution that many traditional desktop OSes had hopelessly neglected for a very long time and where the developer experience for native mobile apps is less than ideal.

I appreciate your comment about the trust issue, but the bottom line is that these technologies do serve a useful purpose for some people -- I have the customer feedback at my own businesses to make that clear -- and the experience web developers can offer on Android with PWAs will now be significantly better than what they can offer on iOS.

> it's basically impossible to make an app that can store its data locally, instead of on some web server.

No, that is trivial to do: just make an actual damn application.

What the author is complaining about is that it’s impossible to make a text document that pretends to be an application that stores data in ways they were never intended to be stored.

No, that is trivial to do: just make an actual damn application.

So trivial that all it needs is learning a completely new skill set and tools, signing up for a gated distribution mechanism that can kill your application on a whim if you violate any of the rules over which you have no control, and then giving a huge cut of your revenues to the rent-seeking platform owner?

The web has been more than just text documents since around the turn of the millennium. It's probably about time we stopped ignoring 20 years of very popular evolution and pretending that what might have been "intended" before a lot of people reading this comment were born should still guide what we build today.

"just write an iOS app" versus "my web application can be used on Apple devices" is a bit much, don't you think?

> What the author is complaining about is that it’s impossible to make a text document that pretends to be an application that stores data in ways they were never intended to be stored.

You must've been not following things. The web platform is an application platform and has developed to that end, for many years.

Progressive Web Apps are applications based on standard Web APIs that are designed with the intent to enable offline-capable applications with persistent offline storage of significant amounts of data.

> The web platform is an application platform and has developed to that end, for many years.

No it’s not. Using it like that is a lasagna of dirty hacks. The web is for structured text with hyperlinks, everything else is bullshit that doesn’t belong on the web.

> No it’s not. Using it like that is a lasagna of dirty hacks.

First it's a bunch of dirty hacks. Then it's an informal convention. Then it's a standard. Lots of technology evolved that way.

All the stakeholders driving the web standards forward are focusing on making it a more powerful application platform.

> The web is for structured text with hyperlinks, everything else is bullshit that doesn’t belong on the web.

That's your personal opinion on what the web platform should be, not what it is. Of course it's a crappy platform in many respects. Of course a lot of people don't like the way it goes. It doesn't matter.

I'm sorry but I find this argument utterly tedious.

A Swift file is no less a "text document" than a JavaScript file is. There are APIs available in the browser to store data offline, so I have no idea what "in ways they were never intended to be stored" means here.

A webapp is "an actual damn application". Can we just dispense with the repetitive arguments about this every time anyone so much as mentions adding interactivity to a web page?

The problem is, that it rarely happens under normal circumstances. So you might build a logic which synchronizes your data to the server but rarely has to download it as most of the time it still has a relatively current snapshot. And the few times you have to download everything, it is ok for the user to wait a while.

But if you have to wait every time your last interaction is more than 7 days ago, the whole experience will change. And supporting a reliable offline experience will be very hard to build.

I can delete data from my hard drive, why are people assuming things stored on a computer is a good place to store things. Nothing stored on a computer should assumed to be forever

If you are distribting a PWA through e.g. electron the user does not have (easily) the means to delete the cache. Web app is a misnomer in that case, they are just applications running inside a somewhat hidden browser.

I also don't understand the alarm.

There is no hard limit on how long things will be stored. Data in localStorage might still be stored for weeks/months/years, as before.

The only limit is on how long things will be stored if the user does not interact with the site/PWA.

If you are a website, not a natively-installed app, that I haven't "used" in a first-party sense for 7 days or more, I don't think your data belongs on my device.

Storage space can be limited, and any app I haven't used in 7 days should be happy to re-fetch my data from a server or convince me to install their native app.

To act like this is some nefarious plan by Apple to get people to build native apps instead of PWAs is absurd. If a PWA was written properly in the first place, this change will have basically 0 impact on it.

It is certainly a plan to further relegate PWAs because they directly challenge the monetization strategy of apple. Its an area where their interests do not align with user interests. A "properly written" PWA may offer things like not re-fetching data from the internet when you already have it locally, and / or not forcing you to create an account just to save some basic data (ex: A recipe app, a jobs search app, etc). Consider for example, saving a job search website as an app, and being able to search and save jobs without having to make an account. An account could be offered if you want cross device syncing, but is not required just to save jobs. Which is great because some users prefer to remain anonymous, and PWA's open the door to that type of thing (as a singular example).

This move is _an_ example of Apple's (understandable) hostility towards PWA's, but you must understand the context here: There is a threshold beyond which PWA's become a generally acceptable strategy, and the quality and diversity rise over time. Apple is preventing that with this move (and others). That's why people are upset. Moreover, the outcome of this will be more "native" apps that are actually just wrappers around web apps, that exist purely because some basic functionality is being actively blocked by Apple.

> Consider for example, saving a job search website as an app, and being able to search and save jobs without having to make an account. An account could be offered if you want cross device syncing, but is not required just to save jobs. Which is great because some users prefer to remain anonymous, and PWA's open the door to that type of thing (as a singular example).

Consider the use-cased of this example. If I am actively job-searching, I will probably be using the site at least once per week, and the data will be saved throughout the process. When I stop using the site, I want that data to disappear for my own privacy/security; and if users want to save the data indefinitely without signing up for an account, then offering an export (e.g. CSV) seems like a reasonable way to address that.

Furthermore, non-Apple user agents may retain data as long as they like, and PWA's (as well as web trackers) are free to utilize that. It's not like this move implements any additional vendor lock-in; people who don't like it will switch to non-Apple platforms.

> Moreover, the outcome of this will be more "native" apps that are actually just wrappers around web apps, that exist purely because some basic functionality is being actively blocked by Apple.

This doesn't seem problematic. It's great if you can reuse some code between your web and native apps. Obviously truly-native UIs will be more efficient in many cases, but perfect needn't be the enemy of good.

Aren't there websites you use less than once a week?

If one of those is using a JWT for auth in localStorage (something which is extremely common) you'd need to login every time you visit such site.

Yes, and that's fine with me. Being on an iPhone, I use the built-in cloud-backed password manager which makes generating and entering credentials near-effortless. Furthermore, by not leaving long-lived tokens in my browser's storage, I'm less vulnerable to exploits that may exfiltrate that data.

There's a big difference between a user choosing to clear their data and a browser vendor deciding to clear a user's data.

That's like asking why people store files on disks when they could store everything in the cloud.

If you want to make an app that someone can use offline on their device, why are you making it as a website at all?

While I agree with the concerns regarding arbitrary implementation of standard APIs, there are still a bunch of useful applications of PWA technology to enable temporary offline operation.

The more we use these, the more likely the APIs are to be fully implemented (and hopefully have features added to them).

Feels like Apple is just continually making the Safari browser worse.

I think they just want to push people towards native apps so they have full control. Apple always wants control.

First they prevented plugins like uBlock, made it very expensive to create your own plugins, and now they're messing up LocalStorage.

Would it be possible for Apple to relax the 7 day limit for apps that are strictly client side only? I.e. sandbox the apps to not allow access to any remote resources? It seems to me the opportunity to exploit a user's privacy would be very limited without exfil.

Maybe, but it would only apply to a subset of PWAs. For example OP's RSS reader must access remote resources.

This headline rewrite does a disservice.

It editorializes away the point of the post, which is that, according to the author, "Apple just killed offline web apps while purporting to protect your privacy [by forcing WebKit to delete all local storage after 7 days]."

I know I'm in the minority, but I'm glad this change is happening. I simply don't trust large tech companies to keep user privacy a top priority, and in my mind, this outweighs whatever UX niceties an honest company may provide.

The solution could be to give that option to users; a way to mark a website or app as trusted or not. Apple's approach on the other hand really sets the web apps back, which I (as a privacy concious individual) am more comfortable using compared to apps.

If this encourages more apps to go the native route, we've done more harm than good. Apps can gather a lot more data than websites, such as the dreaded contact list access.

Have a look at data: URI technique we developed to avoid Apple/App Store altogether for critical apps:

https://coins.github.io/secure-bookmark/

OP here, I just posted an update section there with some extra information that I decided to clarify upon after interacting with people here. Thanks a lot for the responses, this has been quite great. I wish more people that are affected by this or that have opinions about it would write more posts.

There is no change without applying pressure at Apple. If this is important, we must speak about it, all of us. And yes, I understand that some people feel that this is not important for them, that is OK, we have different values and understandings, but if you have an opinion about this, please go out and post to your blog, dev.to, medium, whatever, but post.

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

And the new title no longer has any relationship to the title of the post. And no admin (from what I can see) even bothered to let us know why he censored this.

edit: 17 minutes after posting this comment critical of moderation, I am unable to submit a new story. Coincidence?

Original article was here, in case my comment makes no sense now: https://news.ycombinator.com/item?id=22683535

I was confused as to why the page in question had changed, but I realized it was moved.

Given that PWAs don't work particularly well with iOS anyways even if you have a PWA you're probably better off deploying it to the App Store via Cordova and prompting users to install it from there.

The issue would be not that problematic if I could just run a real Firefox browser on iOS, not a skin over Safari, which leads me to a question that puzzles me for a long time.

Why Apple is not facing antitrust charges for not allowing competing browsers on their platform? Microsoft didn't SHIP competing browsers, but allowed them to run just fine on windows, and was fined nonetheless, but Apple somehow gets away with not even allowing competing browsers at all!

I'm not from the US, so maybe I'm missing something about these antitrust lawsuits. Can someone please explain?

This is a common misconception.

1. Apple is not a monopoly player in the app market.

2. Microsoft's antitrust fine was for forcing OEMs to not include any competing browsers (Netscape) on threat of losing special pricing.

> 1. Apple is not a monopoly player in the app market.

Apple has a 100% monopoly in the app market by running the only AppStore available for iOS devices, and that store review guidelines specifically prohibits use of any other web rendering engine but WebKit [1]

> 2. Microsoft's antitrust fine was for forcing OEMs to not include any competing browsers (Netscape) on threat of losing special pricing.

That's not the only lawsuit they faced. There was EU case that forced MS to make a special installer [2] for alternative browsers.

I really can't perceive the meaningful difference between these cases. And I believe it's about time to force Apple to allow installation of alternative app stores, from where users would be able to install all the apps they want, without being handcuffed by device manufacturer.

[1] https://developer.apple.com/app-store/review/guidelines/

[2] https://cutt.ly/ztn4kxr

The critical bit here is "for iOS devices". The legal definition of monopoly is interested in the broader market, not what the manufacturer of a device with comparatively tiny market share does.

iOS with a 13.4% global market share as of 2019 does not even come close to monopolist status. While I'd like to see iOS forced open as well, there is currently no legal method to do so.

This whole thing is about trade-offs.

If tracking companies cannot use cookies they can use JS and local storage instead. Then they can keep tracking people for long periods.

So, in the escalating war Apple alters local storage so that non-use for more than 7 days doesn't keep data along. It becomes less valuable for use with tracking.

The trade-off is that offline web apps become less capable and some use cases go away (e.g., completely offline).

Which trade-off is better for whom and in general? I've not thought to know. But, the trade-off is worth pondering. Whether we agree with Apple or not.

As the article explains, Offline Web App is being used to mean Progressive Web Application (the standard terminology).

(edit Turns out that's not quite right, see diggan's reply.)

From the article:

> You’d almost think they had an App Store to promote or something.

There's certainly a tension here. I'm still not sure why more vendors don't make iOS PWAs to get around the App Store payment rules.

Perhaps related: Very roughly a year ago, something changed in iOS that broke the 2048 PWA. Its swipe-detection no longer works. A pity.

offline web apps are different than PWA. A PWA doesn't necessarily work offline, but more is independent from the connection / loading of it. I do think most PWAs do work offline, but doesn't mean it's a requirement to call it a PWA.

Similarly, an offline capable web app is not necessarily a PWA, as PWA carries a lot of features to it besides being offline capable.

Good points. I've edited my comment.

What is an "off-line web app"? If an app never goes online and is sandboxed from other apps, then it never has any data at risk of exfiltration.

An offline web app is a frontend-only application (just HTML+CSS+JS or less) that can be loaded from any medium (internet, usb stick, direct TCP via netcat or any other transport) and work in your browser without requiring a remote connection to allow usage of it's features.

So yes, this would mean it doesn't run the risk of ex-filtration or snooping at the transport layer, as the data never leaves the specific website context in your browser.

> I'm still not sure why more vendors don't make iOS PWAs to get around the App Store payment rules.

Because users won't use them. For users that don't have a technical background: if it isn't in the app store then it essentially isn't an app. For techie users: lots of us don't want web apps because of the power, memory, and bandwidth usage is often higher than a well written native app. The fact that there's a gatekeeper who has some control over what shows up in the app store is usually a feature and not a bug.

If there were big parts of the app ecosystem that didn't have native apps, then eventually users would find web apps. But that isn't the case. Think of anything and search for it in the app store and there's an app for it (including 2048).

> For users that don't have a technical background: if it isn't in the app store then it essentially isn't an app

I'm not convinced of this. If it has an icon like proper apps, and feels like an app, I don't think users are going to mind if it came from the App Store.

The question is whether the unfamiliar 'installation' process is too fiddly for non-technical users. I don't think it is. I figure a 10 second How to install our app animation would do the job.

I think this is a problem of their own creation - done in the name of simplicity which has outlived its usefulness, but to take it back now would be chaos.

A closed, curated app store gave less technical users the confidence to actually download software without concern that it would screw up their device. However, things which have a different model like web apps or system extensions (read: keyboards) were also put into the same distribution mechanism.

You can see why as it removes a barrier to using them: people just go the same place they've always gone to get software on the platform. They make no distinction between the native Gmail app and GIF Keyboard because the install process is the same and each are displayed prominently.

In reality, 3rd party keyboards and the like should probably be handled - from a UI standpoint - like they are on macOS, inside System Preferences/Settings, with no app icon on the homescreen, they simply aren't as important as full blown apps.

^ People will dispute this and that's really nice...but they're wrong.

I've seen a lot of news sites and random WordPress blogs doing that.

It has become spam, just like news sites asking to send notifications.

> I'm still not sure why more vendors don't make iOS PWAs to get around the App Store payment rules.

One reason is because Apple have incentive to break PWAs and they will do it. It's not a wise business decision to act against big player.

I agree, this is really stupid. Data should only be reclaimed when requested by the user or if more storage is needed on the system on a LRU policy per site.

Could you ask all the privacy abusers to stop using them to abuse privacy?

Seriously, you should browse the web for a bit and see just how many "client side PWAs" you've used/installed, vs how many tracking identifiers have been installed.

Many web developers are turning to Electron in these cases but IMHO this is a waste of resources as the Electron runtime is not shared among the different apps running and there is only so many browser engines your computer can run before it has impact on its performance

Why? Why isn't the case that the code which runs Electron, and library code JIT-ted by Electron can't be reused by other processes on the same system?

An update from John Wilander would seem to confirm that this could happen in Safari - and they consider it a bug.

Of note, John’s replies also mention this policy does not apply to WKWebView or UIWebView, because they lack ITP.

https://twitter.com/johnwilander/status/1242882202301427712?...

People complaining about how PWAs haven't taken off yet are extremely ignorant. Go open up your dev tools and see how many websites you've visited make use of at least some PWA features (most likely cache) without you even noticing. PWA features have a lot to offer to the web experience even without installing the app. You've been enjoying these features and you don't even know it.

Can decentralized (i.e., user owned) storage help here? Instead of keeping data only at user device, it can be backed up in an encrypted and private way.

Gaia is one example: https://github.com/blockstack/gaia (I've worked on Gaia so I'm biased but there are other such decentralized options as well.)

It still comes down to the point that everyone wants you to load an app from an app store. Which drives me nuts. Just give me the web, please.

PWA is about the web.

When suppliers do this, they put customers back into a buying position. Instead of defaulting to buying another iPhone, I’m back in a buying position. So let me ask: what is a good alternative to an iPhone Xs on the market? I was also super close to buying an Apple Watch, but now I’ll defer that purchase.

I have already stopped building native apps because the App Store process is so painful.

I guess this means Safari won't support persistent storage anytime soon. I was looking forward to it becoming a standard API. https://developer.mozilla.org/en-US/docs/Web/API/StorageMana...

Based on the table there it seems Edge had but removed support anyway?

Not on the main topic, but since OP mentioned CORS being a pain: is there a reason the browser doesn't let sites do cross-origin requests, but just without any cookies etc.? Either through a separate API or just the default behavior in the absence of CORS headers, is there a reason for that not being a thing? I can't imagine nobody has thought of it?

The inability to save local files really hinders PWA and just allows all the shady large players to enforce their self-serving rules.

Unpopular opinion but this is the kind of shit that makes websites have a banner “Safari browser will experience issues, use Chrome browser for the best experience”.

I remember when Edge/IE was crap, I put up a couple of banners that Firefox/Chrome/Safari are officially supported browsers and people did move away from Edge. Had <1% of traffic from there.

Ah.. well, ok, but this is pure nonsense.

First of all, the various kinds of browser local storage have always been volatile. It has always been a bad idea to treat it as permanent storage. Maybe it's a little more obvious now? Not exactly a bad thing.

> the PWAs I was building here might just be dead for iOS users

If so, it was already dead for your users, whether you realized it or not. I guess you were going to implicitly promise something you could not deliver: that your PWA would keep track of the feeds the user was subscribed to (and perhaps also keep track of what had been read, and other user state). But you were going to screw your users, because a PWA without external persistent storage could not do that reliably. It's really luck for your users that this caught your attention and has you rethinking your app.

A partial list of things completely external to your app (not including this change) that could cause your users to lose things important to them that you stored in various local storage...

    * user switches browser
    * user has multiple devices 
    * user upgrades phone (or tablet, or workstation, or laptop)
    * phone (or other device) goes in for repair or upgrade
    * major change to browser (like Edge moving to chromium)
    * some OS updates
    * user clears browser data (as innumerable troubleshooting processes suggest)

It's wrong to think browser-based storage used to be stable but now isn't. It never was. Browser-based storage was never going to be a good place to store your user's important, persistent data.

I can't seem to find whether or not these policies and storage caps are implemented in a WkWebView context. Any idea?

Is this also going to affect web views?

For the past couple of years I worked on an education app where users are 90% of the time offline. Users can remain offline for weeks. There the is no reliable internet in most of the schools in Mexico.

I don't work on that company anymore but this is going to be a massive headache.

I find localStorage a bad crutch, when storage accessible to any browser or computer would be better. I'm totally cool with this because magical storage in your browser is just a bad idea, especially when it requires developer tools to find and see what it is doing.

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

Apple is at war against the open web and tries to kill it at all cost.

Most apple apps are privacy hogs which don't have any way to turn off tracking. In apps, Apple created a prison which noone can question and everyone will allow them to do all abuse. Look at Apple News.

What’s wrong with a “normal” app? No server required and data stays only on the device. The argument that the author is building a PWA because other people abuse privacy (with apps) doesn’t make much sense. Why not build the app, respect privacy, and be done with it?

LocalStorage is not a substitute for an actual database, it’s a cache. The problem with the author’s technique is that privacy minded users clear their browsers from time to time, so they would be inadvertently clearing data they actually wanted to keep because who uses LocalStorage as a persistent data store? Sure it could be used like that as an “off label” use, but generally it’s used to cache what is persistently stored elsewhere or used as a means to avoid multiple network calls in the process of doing something (such as saving calculations, the results of which would be eventually persisted.) Local Storage should be used as if it were a session store rather than something persistent.

The problem with a "normal" app is now you are beholden to the rules/regulations/evaluations of a third party that can easily decide without recourse that your "app" should not be in their store. Even if your app "is fine" every update and upgrade incurs a delay through the third party's reviewing process before your users receive it.

If the web browsers would provide _some API_ for persistent storage without yanking the carpet out from underneath developers this wouldn't be such a huge problem. There _used_ to be a file-access API but it was removed.

Personally, I think web browsers are too large a surface area to secure/keep secure and the world is probably going to swing the opposite direction to native, downloadable applications without the interference of a third-party store.

> Personally, I think web browsers are too large a surface area to secure/keep secure and the world is probably going to swing the opposite direction to native, downloadable applications without the interference of a third-party store.

Wait, you think downloadable native apps without any intermediary to validate them is more secure? What you're describing is basically the old shareware system, which was riddled with security issues.

A normal app requires a separate build process, users to install it, manual review for each update, perhaps the platform owner will just deny it without reason, and for Mac/iOS it also requires actually owning or "borrowing" (using another persons/companies) build machine and software.

I don't understand why an installed PWA should not be able to keep their storage just as a "normal" app can. It would clearly be better for both developers and users. There are so many apps & websites that could be more privacy friendly if they could just trust localstorage to actually be "storage".

Those sound like problems for the developer, and not the end user.

I don't think you understand what "users to install it" means for actual users.

Most users are asked to install multiple apps for the normal sites they visit (like news sites, social media, imagehosting and more). They usually don't, and that's good. Those apps should not be apps, they should be websites. Most of those apps can be a simple website. If the users want/need more functionality that can be within a installed PWA.

I think this is more people and developers fetishizing what it means to be in the app store or to be "native". If we can run it all in probably the best sandbox we have available without having vendor specific builds or vendor specific prompts why would we as users or developers want anything else?

Some apps should be native. But the majority of them would be better as webapps rather than android/iOS apps.

EDIT: Also I'd argue a lot of those problems are artificially created by the platforms, not the developers.

That is terrible if you are working on a pwa game to cache assets offline. There should be some opt-in approach similar to location tracking in the background like some apps do. That seems way worse than simply having local data be relied upon. Not cool.

What's the problem with the client having to re-download those assets if they don't play for a week? Seems long enough that I'd expect a patch download on a typical gaming platform, for example.

Offline iPad kiosks

Is there anything to stop an application from touching the cache periodically (in the Unix sense of updating modification timestamps without changing values) on load?

If so, assuming the application is used more than once every 7 days, this seems like less of an issue.

OP here, I just posted an update section on the post that touches some of the comments I've been seeing here. English is not my first language so I think that sometimes I don't make my ideas clear enough or well explained enough.

This won't accomplish much in the long term. Ads networks will simply start introducing server side SDKs. Websites that rely on ads will gladly use those to keep their revenue even if that means more load on their server.

At the time of writing, the first sentence of https://www.apple.com/privacy/ states:

"Privacy is a fundamental human right."

A previous HN discussion about PWA's replacing native apps: https://news.ycombinator.com/item?id=22554745

Well, wouldn't surprise me if Apple is now trying to kill aspects of the "open web" they dislike. Ironic because they used "upcoming" web standards as argument to kill Flash.

Apple will do whatever it takes to protect its closed ecosystem, and if that means killing PWAs built with open web technologies they'll provide any dubious excuse to justify it (security, privacy, blahblah). They did the same back in 2010, killing a perfectly valid app platform that was picking up momentum, but they didn't control. A platform that was 5-10 years ahead of the "open web".

Looks like this time they won't use HTML5 as piss-poor excuse.

https://en.wikipedia.org/wiki/Thoughts_on_Flash

Maybe I'm missing something here. Why not just build a native app instead?

Cedric Beust said on an episode of "Talking Kotlin" awhile back that he thought the Achilles' Heel for the WebAssembly cross platform story would be Apple moving to lock down their devices.

Thread about the webkit.org post from yesterday: https://news.ycombinator.com/item?id=22677605

It's not super clear but, if I'm reading it correctly, the 7 days are 7 days of use. So if you don't open the site for 3 days, the counter is still at 0.

I don't think this will help against tracking because a the tracker has no problem to refresh the identifier multiple times before the 7 day span would kick in.

Anybody have an idea what the significance of the 7 seven day cutoff is? Can’t imagine this magic number does anything to improve security. Seems kind of arbitrary.

7 days is the side loading limit I think, so they're regarding these apps as sideloaded? Everything has to go through the App Store as a guess?

So Apple can't really care about privacy because:

- They have a News app

- They haven't rejected apps from Google and Facebook

Can you imagine what would happen if Apple rejected apps from Google and Facebook? Can you even fathom the outcry?

Apple News uses differential privacy and doesn't track user history, but yes, they do provide personalized News I guess? They must not care about privacy at all then!

If you're upset about a seven-day limit on local storage, okay. I get it. It sucks. But to claim Apple's reasons for this are invalid because they allow Facebook apps to exist, that's... weird.

Pretty much an expected move from Apple in its current state, shape and form. Security is such a sweet excuse for a tyranny.

Apps added to the shelf should keep their data

I do not understand why anyone would want to store anything other than temporary/disposable data inside their browser.

Am I right in saying this prevents any embedded widgets that need to show a logged in version, i.e. comments or whatever...

Does this also mean you'll have to re-login to websites every 7 days? (Sorry, not very familiar with web tech!)

No, you'll have to re-login only if you haven't been to the site in the last 7 days.

Does this affect Cordova apps? They use WebKit and may store stuff like api tokens in local storage

Perhaps this style of app, on iOS devices, drains more battery power than deemed reasonable?

Then data will stored online on servers, i cant see how this is better for privacy.

> deleting all local storage (including Indexed DB, etc.) after 7 days effectively blocks any future decentralised apps using the browser (client side) as a trusted replication node in a peer-to-peer network

Sounds good to me, I don't want websites turning my browser into a p2p node :)

Why 7 days though? Why not 30 or 3? What are Apple basing this number on?

I have an app on the App Store that uses WKWebView, should I be worried?

Does this consider hybrid apps like ionic or Cordova to be part of this?

Will this affect all browsers that in iOS are forced to use same engine?

Supporting Safari reminds me of supporting Internet Explorer years ago.

Workaround: encode your app's state into window.location.hash

I've seen this before on an ecommerce site :sigh:

Wife: Hey, check out this! [link with embedded state]

Me: Wow, I'm logged in as you and can even see your payment information! Let's not buy from this site!

Let's not do this. Ever.

Not all data is sensitive data.

That works as long as the user keeps the tab open, but if they use a bookmark (or just remember the domain), the hash part will be lost.

The hash part is not lost to bookmarks, unless Apple broke that too. If it was, no one's MEGA bookmarks would work.

I mean, sure, the bookmark would save a snapshot, but the user would have to manually replace it every time.

Might be simpler to just give them a file to save / load.

This can't be prosecuted as anti-competitive practice?

Do any lawyers out there know if Apple's sabotage of PWA's by their inaction or "features" like this could be considered anti-competitive behavior for an anti-trust lawsuit?

Not a lawyer but probably not. There’s many ways to make an App for their platforms. Just because people want to use web technologies is an implementors decision.

It would be nice to eventually have a standard way (OS / browser specific) of asking permission to use permanent storage with restrictions. Could be locked down by domain etc.

PWA was an aberration - apple fixed it :)

People who use WebKit deserve it

Great... So all those "consent to cookie/GDPR/etc/subscribe to our newsletter" popups will now reappear every time you go 7 days without visiting a site.

I'm 100% on team privacy but this isn't the right way to do it.

I have apps using WKWebView should I be worried?

Property Wisdom Adminstration

I love that the app he wants to build is an RSS reader. I just did a post on why we should be making more use of RSS as individuals:

https://battlepenguin.com/tech/rss-the-original-federated-so...

Interesting he ran into the CORS situation with PWAs. It makes sense. It feels like even PWAs aren't that far off from Electron. Sure you're not launching another browser and can share a browser engine, but you hit other limitations.

I'd rather have a real, lightweight, stand alone app most of the times honestly. I wish people would write more stuff in Qt5. You can bundle Python+PyQt5 together for a reasonable licensing fee. A great example is the Resolve color/video editor is written in C++/Qt5.

Whoever uses local storage as persistent storage doesn't understand what local storage is. 7 days is enough. Local storage is supposed to allow your app to temporarily navigate around connection issues, to not require "always on". You can never rely on this storage to be permanent, there are just too many ways to accidentally wipe it all and for the user there is no easy way to back it up.

Your offline app should ALWAYS sync to the server whenever possible. The only bad thing I can see here is that if you can't upload the data in time and the user then doesn't use your app for 7 days, he will lose what he last worked on, but such is life and why you should rather use real apps. Offline apps needs to work differently, they need to get permanent storage just for that app but only if the user explicitly choses to install it like that. Not every random page should get permanent storage on your device. This is the right move, Apple might just lack an alternative for apps you actually chose to "install permanently" ;).

Posts like these are much more convincing when they simply make a case for some allowance or some functionality, or point out the downsides. The moment they go into whataboutism or grander claims of conspiracies or ill intentions they fall apart.

Rational readers click back and move on. You end up just preaching to the choir.

This particular complaint is paradoxical because Apple birthed web apps, and has done more than anyone to make them a reality. Unfortunately they remain a very rare beast -- extraordinarily rare -- and are dwarfed by the privacy concerns of people using iOS just to browse. So the team dealt with that. Seems a fairly obvious pros and cons analysis.

Maybe they'll add an exception for installed to desktop webapps.

it's really confusing

webkit is open source - can't this be changed (be it by fork, or a commit proposal?)

Sure it can be forked, but the problem is the millions of devices running Apple's version of Safari/WebKit on iOS without any say in it except switching to Android.

Sure, so maybe WebKitGTK will (if this applies to that version). But why would Apple choose to include this fork over their own version in their OSes? If they don't how do you plan on using it with any Apple OS?

IMHO adding more local storage via browsers was a huge step in the wrong direction from the users point of view.

It is related only to WebKit (Safari). So I think people will just switch to other browsers.

Except for iPhones/iPads where you don't really have a choice. Also most people don't give a shit which browser they use, they just use whatever browser is available when they get their device, which makes sense. But those users might soon have their data removed without really understanding why.

So I guess more people will switch from iOS to other devices.

I am the creator of a photo editor www.Photopea.com and I see, that more and more people care about their browsers. They spend a lot of time discussing the issues of their browser with me, because they need to do a serious work in it.

You can install other browser frontends on iOS. People just don't know that the backend is still Safari.

Are we absolutely sure they don't just mean the localstorage containers that aren't part of the current domain? In the same way they are clearing cookies from a different domain, and not the ones that belong to the current domain.

EDIT: Clarification from a Webkit dev https://twitter.com/alexcroox/status/1242559843354972161

Yeah, if you look at the section in question, they're talking about this: "However, as many anticipated, third-party scripts moved to other means of first-party storage such as LocalStorage."

Basically, the ad tech/tracker folks were using first-party site storage to store identifiers, which is what Apple's trying to protect against.

Perhaps the author doesn't realize that WebKit is open source. They could have used their screed to propose to the WebKit team that a first-party page loaded from a file:/// URI not have its client-side storage subject to the 7-day purge, by setting the "firstPartyWebsiteDataRemovalMode" network connection property to "none" — patch included! But they did not, which is quite disappointing.

The new change to ITP is here: https://github.com/WebKit/webkit/commit/4db42c1571d821572ea9...

The cookie filtering logic specifically is located here: https://github.com/WebKit/webkit/search?q=filtercookies

The file:/// handler is implemented here: https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

(I don't have anything to do with Apple or WebKit.)

Apple does not use that Webkit branch, however. They maintain their own branch internally that cherry picks from upstream. Webkit could very well accept a patch, and then Safari never ships that patch because they disagreed with it for use in Safari.

Also, unrelated fun fact: Did you know Webkit still uses svn? That Github repo you linked to is a clone of Webkit's own git repo (git.webkit.org), which is a mirror of their actual repo (svn.webkit.org).

I think it is worth noting that you can really say "Apple" is doing this or "Apple" is doing that with decisions at this level.

The company is just too big and not working in unison.

The Apple Safari Team is killing/hurting offline apps. The author asks why they don't take the same approach in Apple News - as if it is the same team that is in charge. Different team with different priorities and likely not talking to each-other.

I think the larger point is valid - but it better to understand that this isn't some cohesive cross-company strategy at play. Its size-able teams working on their own priorities within a larger roadmap (presumably).

As Apple is one of the most closed companies, it's hard to put blame on anything Apple-related as you don't really know who the teams are. Sure, WebKit contributors are visible as it's an open source project, but who is the "Apple Safari Team" really? And who is the "Apple News" teams?

Easiest is just to put blame on the top-level entity, which is Apple. They have control over their teams so they can redirect the blame if they feel it's needed.

And if this change is to be able to force more developers to build native apps on their platform, then it's for sure a cohesive cross-company strategy. But we don't know if that's the case.

I love these types of comments. They contrast very well with the “the reason Apple makes great products is because their hardware and software teams work so closely together to bring a cohesiveness that other companies can’t” comments.

Reply on news.ycombinator.com