> 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.
> 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.
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.
You can't really have "seven days of application use without visiting the site".
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.
Data isn’t deleted after 7 days for home screen web apps.
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.
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.)
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.
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.
Also what about desktop?
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.
But said timer... does nothing? Why does it exist?
Also, it's simpler to have a timer that effectively does nothing than having extra logic to suppress it.
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.
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.
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.
That's where this is going.
> "first they came for localStorage and I did nothing"
 - https://www.theverge.com/2020/1/14/21064698/google-third-par...
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?
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.
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/
"impose" is the wrong word. I think you mean they are "trying to understand you and do the best thing"
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.
- 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.
- 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.
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.
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?)
I'm just gonna link to a small subset of failures we've documented: https://www.google.se/search?q=twitter+site:grumpy.website
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 
> 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.
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.
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.
The example at
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.
Blog post of the announcement: https://blog.chromium.org/2017/10/building-unified-documenta...
Web.dev is not an MDN replacement.
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.
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?
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.
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.
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.
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.
Wouldn't it make more sense, to display this info before you install a pwa?
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
You blame Apple, Google and your consumers, instead of just making native apps. Why?
Either Apple should stop being the gate keeper or stop making life harder for web devs.
And improve their documentation to lower the barriers to native development.
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.
Why should users suffer the lowest common denominator because of lazy developers?
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.
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.
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?
You mean, like the Internet. The App Store is a nice, safe walled garden, like AOL.
Please read the following:
> 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.
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.
I have argued that a close reading of the TOS currently seems to allow GPL: https://news.ycombinator.com/item?id=21943994
Again, this is super old. Do you have anything newer?
Now we store the account token in iOS keyring and that works.
It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.
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.
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.
Not if the features allow for increased web tracking.
Fixed it for you. It's all about profit.
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.
Storing JWTs, game state data, etc.
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).
Server side, or if you need privacy, have the user export to / import from a local file.
If browsers asked approval before using localstorage, we wouldn’t have this decision.
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.
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.
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?"
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.
> 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!
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.
Sisyphus says 'Hi!'
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.
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 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.
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)
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.
> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.)
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.
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.
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.
I wouldn’t be surprised if Safari/WebKit was one of the larger teams within Apple dedicated to a single app.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Web push is better than native app push when it comes to power consumption as web push is stricter on what you can do.
IE6 must have been a great inspiration for Apple judging by their behaviour when it comes to Web.
Personally, not having web app storing large amount of data is a good thing.
It is still a significant restriction, but it is rather understandable. Without it it could be just Blink everywhere at this point.
On the other hand, the web is mostly open for all, so most people benefit from it, not just Google.
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.]
In what reality-distortioned universe is that worse than having a crippled web?
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.
Isn't the new policy for local storage being copied from an existing policy for cookies? How can they switch to cookies?
In the linked article it actually mentions that this policy is being widened from cookies to the rest of script-writable storage.
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.
It actually works quite well offline
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.
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.
Apple just added new APIs to support these.
We don't want filthy legacy webapp shit, but 2020 high quality user experiences.
What does the "i" mean in that case???
I had never thought of that!! I wonder if that same idea came into naming the iMac then??
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.