> browsers may delete your IndexedDB database under certain conditions
Safari will happily delete your IndexedDB database after 7 days of inactivity.
It deletes "all of a website’s script-writable storage after seven days of Safari use without user interaction on the site". That includes:
- Indexed DB
- LocalStorage
- Media keys
- SessionStorage
- Service Worker registrations and cache
Source: https://webkit.org/blog/10218/full-third-party-cookie-blocki...
Found via: The pain and anguish of using IndexedDB: problems, bugs and oddities - https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...
I would point out that the article you linked mentions that webapps "added to the home screen" on iOS Mobile Safari are exempt from this garbage-collection process. In such a case, the "add to the home screen" step is being taken as the user expressing the explicit desire to have that data around indefinitely. Which seems sensible to me; webapps should be treated as ephemeral-by-default, and only be allowed persistent storage if the user goes to lengths (i.e. beyond just clicking "Accept" on a modal) to express their desire to keep the data.
(And also, I've observed that webapps that notice they're on an iOS device can insist on being "added to the home screen" before they'll do anything, and so ensure their data stays around.)
The problematic aspect of this, is that there's no equivalent of this "exemption by user explicitly expressing the desire to keep the app around" for non-mobile Safari.
Maybe for desktop Safari, the data should be kept around if the web app's rel="canonical" URL is bookmarked in the browser?
Or desktop Safari could just support regular Progressive Web App standards, and so show an "Install App" indicator (like e.g. desktop Chrome does for this webapp: https://www.soundslice.com/). But I have a feeling Apple will never support this on desktop...
PWA are not a standard, they are a Google concept pushed through Chrome (OS). I’m fine with Apple never supporting it.
So long as I can also use them in firefox they're 'unstandardised but not single vendor' and at that point I'm not as troubled about it.
Firefox doesn't support PWAs...
They don't support the same precise system, but you can e.g. definitely do installable apps on Firefox for Android: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
PWA is a Google term, but the whole web app thing is older than even the native app store on iPhone.
Google may have coined the term (not sure about this), but it's far from their own thing [1]. PWA should've been a blanket term for a set of standards and guidelines for developing web apps. Those include progressive enhancement, which I don't think most people would expect.
Unfortunately, the term has been co-opted to mean "website I can install/pin as an app". Again, Google is probably to blame for this, but AFAICT it was never meant to be the meaning of the term. What it does do is create misunderstandings, like a sibling thread claiming that (desktop) Firefox doesn't support PWAs because you can't install anything.
[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
In general, the "Progressive" in "Progressive Web App" just means "progressively-enhanced." In conventional usage around most of the internet, any web app that supports any kind of progressive enhancement, is a PWA.
And "progressive enhancement" just means "being written in such a way that you'll work with a core set of APIs — all the way down to 'no javascript support' — but will take advantage of further APIs if they're available." Where the app forms a sort of Russian nesting doll of functionality, where it "launches" with just the innermost layer (e.g. just server-rendered HTML), and then in turn each new layer is enabled if possible (i.e. if Javascript is enabled, the browser will load some JS from a <script> tag that will then take over the DOM and turns the page into a SPA; etc.)
It's just a further refinement of the older concept of "graceful degradation", where the gracefully-degraded experience is delivered at the start, and then bootstrapped out into the non-degraded version.
Under this definition, the "further layers of functionality" provided to "installed" webapps in some browsers are just a specific kind of progressive enhancement. The app detects that it's being run "installed", and takes advantage of that. (And before that, the browser detects that the app has such a layer, and therefore treats the webapp as "installable.")
Thus, all "installable" apps are PWAs. (But not all PWAs are "installable"!)
I would note that webapps like Slack — i.e. webapps that have both web and "native" versions, where the "native" version is just the same remote webapp from the web version, loaded in a special browser that exposes extra capabilities that the webapp then takes advantage of — are also PWAs by this definition.
Which specific feature of PWAs is non-standard?
I wish these bookmarks extended to other browsers on iOS. It's already crazy they can't ship custom rendering engines, but basically this in and of itself could be considered anticompetitive (only Safari bookmarks can be exempted from this GC process) lol!
I think all home screen apps run on the system webview, there are no “safari bookmarks” in this context.
you can only add bookmarks from the home screen from Safari. Chrome, Firefox, etc do not have this capability
Tim Cook basically lied to Congress when he stated that developers can create web apps as an alternative to using the app store.
Edit: In order for this to be true, Apple (at the very least) needs to enable push notifications and an install prompt for progressive web apps.
I mean, he's correct in the same sense that a Buick can't be made to haul a fifth wheel trailer. It's because a modern Buick's design doesn't include the bed required to install the fifth wheel on.
Nevermind that there's nothing strictly stopping GM from changing the designs for Buicks to include a vehicle capable of a fifth wheel mount.
If you add the website to homescreen (make it an “app”) then the 7 day storage limit does not apply.
This makes total sense to me, and I’m happy Facebook can’t store tracking data in my Safari for longer than 7 days.
> I’m happy Facebook can’t store tracking data in my Safari for longer than 7 days.
They’re storing it somewhere, no? I feel like the benefit here is more so the browser file system doesn’t get bloated
Clearing site data makes total sense. Otherwise after a year of web usage you have multiple GB of stored website data that the user does not know what it is being used for or how to clear it.
And the majority of uses for local data is to cache fetched data or store temporary preferences not worthy of being in the server side database.
I'd assume Tim has a different definition of what an app is than what you're thinking of.
PWA are explicitly exempt from the data storage wipe behavior[1]. So there's that, at least. For now.
Although I agree that it's a fairly minor win in the grand scheme of how handicapped PWA's are on iOS. And like you said, the lack of install prompts and tucking away the PWA "installation" option in the share menu makes it less than intuitive and requires manual awareness efforts by devs[2].
[1] Last section of https://webkit.org/tracking-prevention/
[2] https://michaellisboa.com/blog/prompt-ios
That’s only half true. PWA are exempt from data storage wipe behaviour only if they have been added to the Home Screen. And as your second article points out:
> It’s important to ensure that our iOS visitor is using Safari because iOS doesn’t permit other browsers to install our awesome PWA’s!
So if the user is using Firefox or Chrome etc browser, they can’t do it. And since all browsers have to use WKWebView, the limitation applies to all browsers. Apple has basically crippled other browsers with this anti competitive behaviour.
I don’t get why so many tech people think that “allowing alternative browser engines” will do anything to change policy decisions made by Apple.
Like wish granted! You can now use Blink and V8 on iPhones! But…
* They still are required to delete website data after 7 days.
* They must distribute add-ones through the App Store.
* They still can’t run workers in the background because the browser is slept like any other app.
* They have to use Apple’s notification service like any other app.
* They can’t install things to the Home Screen because no other app can.
But yayyyy. Blink!
Apple did plan to make web apps first class on iPhones. But changed their minds when developers complained about not getting hard metal access. Maybe they thought that supporting web apps would get them more apps, but developers gave them apps for free and it allowed Apple to have a monopoly. Microsoft tried the same with their phones but somehow failed... Google went the web app route on ChromeOS with decent success. Mozilla tried with FirefoxOS but was too early - FirefoxOS is now very popular but under another name on low end hardware phones.
Makes sense because even my oldish Macbook Pro goes into afterburner mode trying to browse the modern Internet.
But it's totally a valid option to have an app that is a web app and does not have push notifications. For the vast majority of apps regardless of platform, I absolutely do not want push notifications. It seems bizarre to consider that feature as a litmus test for whether the web is a usable platform on iPhones. Would you also require web apps to appear in the App Store in order to consider a web as a usable platform on iPhones?
That’s a fair point, but I’d argue that for cases where the app really needs notifications (for example an alerting system) or when the users want them, building a web app is not actually an alternative even if Apple considers it one.
I don't think Apple considers the web as an alternative platform for apps that are designed to alert you at any time of day for any reason, including when you are not actively using your devices. I think this is a very, very good thing, and doesn't mean that web apps are not a viable alternative to the App Store.
I'm creating a chess pwa that should notify the user when their opponent has moved.
I don't think this web app is going to do as well on Apple devices because of the lack of notifications and also the difficulty to add to home screen.
BTW, you have to give the web app permission to notify. It's not like native apps.
Apple has clearly crippled PWAs to maintain their walled garden.
I love the truth and ain't a Apple fanboi by any means, but this is not a lie to me.
Can you run a PWA on an iPhone? Yes, you can even pin them to the start screen to keep data long term, as others have pointed out.
Are you able to use all features other browsers enable? No, only the ones Apple allows.
As a Safari user I’m really happy with that behavior, it avoids the hassle of manually purging it regularly.
Also in my opinion websites have no business storing data on my device through a browser. If I want that behavior I would use a native app.
Yep, this is the biggest problem (although I haven't seen it happen after 7 days, at least on desktop).
We will provide a new backend for the Storage Foundation API when it's available.
Clearly the solution to this is to keep a query log in an extra table and periodically stream that to the server as a form of logical replication (plus perhaps being able to load the initial database state from the server side as well, maybe even on-demand using the GH pages trickery until a write forces materialisation into IndexedDB).
As a bonus point this effectively adds yet another level of "Yo, Dawg" which I can't not love just as a matter of principle.
People are already trying to get me to hook up https://litestream.io/ to it
I wish every browser does that! Web site has no business storing data on my computer more than 4093 bytes (that is already too much) per domain in my computer just because I visited a web page. 10 MB - 10GB of data is too much.
Yes, send all your data to someone’s server instead.
If you're concerned about a web site silently having access to personal data from your phone, surely it doesn't matter whether that web site is storing it silently in your device's browser storage, or storing it on the web site's servers.
If, on the other hand, you're explicitly uploading or entering data on a web site, well then yes, the default assumption would certainly be that the data is getting saved on the web site's servers (if it's being saved at all). That's how the web has worked for a very long time, with the exception of cookies and a few other more recent but not widely known storage mechanisms which in most cases aren't considered sufficiently robust for persistent on-device storage.
I think that's a valid concern. Stuff like this should only be allowed after a prompt where the user explicitly allows it, just like any other permission
I would say it’s even more important in the case of a web app that stores data locally, because it’s imperative that the user understands that data is tied to that particular web browser and device, and that clearing site data (which I’ve known non-technical users to do periodically to reduce tracking footprint), changing devices, etc can/will result in data loss.
Oddly enough the handful of web apps I’ve known to use local storage don’t communicate this at all. Developers seemingly treat data in browser local storage as existing indefinitely and unlikely to be deleted, when in fact it’s probably the most easily accidentally lost form of storage an app can have.
So that is why a website I work on has complaints of Apple users who keep getting nagged by cookie banners - they store their settings in LocalStorage since cookies tend to have issues when the content is too long. Thank you so very much.
This is why I haven't used LocalStorage or any other browser storage solution for a long time. They seem really cool, but if they will just get wiped by some browsers, then what is the point? As of a couple of years ago, localStorage didn't work at all in a private windows in safari. Unless you have some very specific needs, I don't know how you would every use IndexedDB
But doesn't this 7 day limit only apply if you load a third party script that uses IndexedDB into your site?
Webkit says in your source:
> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.
If webSQL were a thing, that list would include webSQL data too.
I assume that also includes the Cache API's Storage?