Yeah I think the real problem is that deleting an app isn't uninstalling (which is sometimes a feature not a bug), but Apple provides no paradigm for actually uninstalling that deletes preferences too.

They do on iOS.

Unfortunately, they don’t. There are many apps which after uninstalling, and reinstalling them weeks later, prompt you with: “Hello David, welcome back”, etc. I need to login again etc. (cache was cleared) but my settings are still there.

This happens even when deleting the app from ALL devices connected to my AppleID.

On iOS the Documents and Library folders exist per application in a sandbox, so those can be deleted with the app binary. Preferences like location permissions are reset too. But some things persist, like the app's related keychain data, which might contain a user session. Apps have the choice of where they store things and therefore what behavior to give users in a delete and reinstall scenario.

Of course any files saved in iCloud Drive or "On my iPhone" stay put, which users would expect.

I think the value of retaining the keychain is related to 1. automatically deleting least recently used apps and restoring them when a user goes to launch them, and 2. restoring from encrypted backups, in which the downloaded apps are not backed up themselves, slowly install after the restore completes, and find the keychain data waiting for them.

If I recall, not all methods of backup include the keychain, which I think was the difference between having to sign into every app again or just a few due to a new device's Secure Enclave. These days if you get a new device you'll have a much better time with the phone-to-phone migration assistant then a backup and restore.

Good to know the details, thank you.

It's sounds like a good feature, however,

> "But some things persist, like the app's related keychain data, which might contain a user session."

this is also functioning as a "super cookie". Once you've installed a Google app, Google will always know it's you. Even when reinstalling/using another account.

Apple should provide a mechanism to clear these items too, and prevent tracking users.

Revo Uninstaller for windows manages to do this.

That's also Apple's fault isn't it? App data should fall into an predictable folder regardless of the location from where is ran, if for whatever reason the app needs to use a different folder it should be something developers have to go to multiple hurdles to implement (e.g. specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash)

> App data should fall into an predictable folder regardless of the location from where is ran

In fact, App Store apps are guaranteed to do that (by being in a closed sandbox); that's why Apple has an uninstallation procedure only for App Store apps.

> specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash

macOS tries to do that, and developers cry that macOS is becoming more and more closed. In fact, macOS already disallows all apps (including non-sandboxed apps) touching ~/Documents and ~/Downloads except for specific exceptions that the user grants.

Yeah the way they're doing this is a bit of a pain in the ass to be honest. Set up a new Mac and you have to do though tons of these popups. It causes popup fatigue and users start just clicking yes without even reading it. I've seen it many times. It defeats the purpose this way.

It reminds me very much of how they made fun of Windows Vista in the past: https://www.youtube.com/watch?v=MyGUrPxG1iM

I don't know what a better solution would be but I don't think this is it. And the documents and downloads folders are pretty arbitrary on Mac. Any user created folders don't get this protection.

I do love the way that sandboxed apps only store stuff in one folder in the ~/Library/Containers folder though. Even non-MAS apps that are sandboxed have to do that.

In fact the trick in this article doesn't even mention this, if you use it with a non-sandboxed app you're not guaranteed to uninstall everything for sure using this method.

"Would you like to allow your toaster to make toast?"

"Please grant your refrigerator permission to store milk."

You jest, but I think a kosher refrigerator that somehow prevented dairy from finding its way into the meat section would find customers.

Nonsense, is obvious that an smart artificial throat will be the final solution to this problem, it will use AI and lasers to dispose atoms of pork and non-kosher food before it reaches your stomach, automating God's will just like he intended.

> That's also Apple's fault isn't it?

Sure, but if they locked things down the way you’re proposing, people would absolutely lose their minds about the iOSification of macOS.

supporting uninstallation ≠ locking down

Supporting uninstallation by restricting applications to a sandbox that can be cleaned up == locking down

Yep.

To be fair, the situation isn't much better on Windows or Linux. While at least they have a concept of uninstalling an application, you're still reliant on the developer actually getting it right and not missing some tempfile or something.

The filesystem doesn’t have rich enough metadata about temporary files. At least Windows has a file attribute for temporary files (FILE_ATTRIBUTE_TEMPORARY), although I’m uncertain how many apps actually set it on their temporary files; Linux/Unix/etc appears to have no real equivalent. I think ideally temporary files would have rich metadata - the ID of the process, session, and application/package which created them, and some kind of retention policy and expiry date. Of course, one could always use xattrs for that, but unless they are standardised few would use them. C library functions such as mkstemp/mkdtemp/etc could be enhanced to set metadata on temporary files. The OS package manager (apt/rpm/etc) could put an xattr on an executable with the UUID of the package, and then mkstemp could copy that to an xattr of all temporary files. Now if the FS also indexed xattrs, we could upon uninstall find all temp files owned by a given package and remove them.

Many mainframe/minicomputer file systems support file expiry dates, which is an interesting feature which Unix missed.

Yeah and application bundle proplists could help with that too.