I’ve been using AppCleaner (https://freemacsoft.net/appcleaner/) for years now and it’s a real neat (and free) app that’ll do a pretty decent job of cleaning up crud.
https://apps.tempel.org/FindAnyFile/
Then just trash them.
[1] https://arstechnica.com/gadgets/2007/05/the-delicious-genera...
And I mean, Delicious Library… it looks good, but… why would I scan everything I have, to look at it on my Mac? What’s the point. I never understood it even back then.
But yeah, GUIs from that era were amazing, and then moved to iOS in the first iterations, with all the skeuomorphism. It all died with the move to the new flat designs I guess.
Today Mac apps are just mostly Electron/swiftui and boring.
I wonder how many users that have uninstalled VMware still have 30 gigs of unused VMs lying around on their disk.
Sure, but if they locked things down the way you’re proposing, people would absolutely lose their minds about the iOSification of macOS.
Many mainframe/minicomputer file systems support file expiry dates, which is an interesting feature which Unix missed.
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.
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.
"Please grant your refrigerator permission to store milk."
This happens even when deleting the app from ALL devices connected to my AppleID.
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.
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.
It would be "unbelievable" if a multibillion company decided to be helpful and erase your data just because you deleted the binary that created them (actually, it wouldn't, but let's not digress into how those companies are stripping away our agency by mobile-ossifying everything).
The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.
Turns out your UNIX with a human face ate its children afterall. With relish.
Also, "uninstallable" means "cannot be installed"
Thanks for demonstrating your lack of credibility.
Uninstallers by and large only do the reverse of what an installer did by going through the install log and undoing what it did.
This means any additional files made after the the installation that weren't properly appended to the log, any additional information added to the Registry that weren't properly appended to the log, and any user files created after installation (eg: save files) will not be touched by the uninstaller.
Should everything be properly logged for clean uninstalling? Yes; Linux package managers are a decent example. But reality is not ideal, so we have to deal with practicality. This presumably is the case whether it's Windows, Mac, or Linux.
Nor do most linux programs remove dot files when they go away.
Reaching into another account‘s home directory to remove stuff feels very intrusive.
Which would mean that any uninstall trying to also clean out library data is going to be incomplete.
I think the consistent behavior of always keeping it is a win
I dont mind the per user settings crud, I do mind the system wide crud, because it can make reinstating the app to resolve an issue fraught, and I have to go manually find whatever opaque keys were set and remove them.
I think I agree that the default behavior should be to leave all that data on the user's system. But I also think that apps should have some kind of associated file manifest, which you can use to automatically clean up after the app, or at minimum get a definitive list that you can go through manually or with a script.
It turns out that Apple installer packages do include a manifest (cutely called a BOM) of package contents, but users don't typically keep package installers around after completing installation successfully, and it says nothing about files that may be written by the app itself while in use.
I don't see how you could possibly claim that the user library "ruined" anything. Most apps need to save some kind of settings and/or transient data files. Where else would they go?
There are two scenarios I want the cleanup to happen: 1) app is buggy and I'm trying to fix it by reinstalling from scratch, 2) I need to free disk space. Both are pretty rare, and in the second case I am already using a specialized utility like DaisyDisk to see where my space has gone.
> transient data files
/tmp? That gets actually auto cleaned up!
> settings
Maybe. Do we want macOS to introduce the concept of uninstall to shave a few of those kilobytes? Hoping programmers do not screw up with rm -rf /? I already hate it when I have to use an installer so that's a no from me.
You don't specify and it's highly dependent but in most cases when an app is misbehaving it's an issue with preferences. You can reset most apps with `defaults` without blowing away all its data. There are some intricacies with how macOS handles preferences, so you should avoid manually editing related .plist.
The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.
Of course, `man defaults`. You can modify the preferences and potentially fix it, backup preferences, etc. Again I must stress that you use `defaults`, the .plist on disk isn't always accurate even if you terminate the app and reboot the machine.
> The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.
There isn't really a one size fits all perfect automatic solution. Not all apps are good macOS citizens.
That's what the average end-user understands by removing an app from the system nowadays.
Because on iPhone the app is completely sandboxed. Think Docker, with virtualised OS paths, but on OS level. When Apple tried to introduce a very light version of sandboxing, the world was ablaze in pitchforks and torches.
When I delete an app on an iPhone, all its data is also deleted. Gone.
https://apple.stackexchange.com/questions/441112/how-can-i-r...
https://apple.stackexchange.com/questions/332574/deleting-an...
It means both cannot be installed and can be uninstalled, depending on context.
Unless they want to create an interesting headline or quirk in their writing, which is also a relatable thing to do.
The Windows registry is a simple key-value store, just like the macOS defaults system. Windows installers/uninstallers may create/remove some registry entries, but those are typically entries for file associations and the installed program list, and perhaps some global settings. But then the app is free to write its configuration data to any registry key it likes (usually ones named after the app), or to files in ~\AppData, or perhaps C:\ProgramData. It’s not much different to macOS in that regard. The uninstaller may offer to remove the stuff in AppData, or it might keep it as-is.
(~\AppData is a bit less messy than ~/Library, because there are only three folders in AppData where application folders could go, but Library has all these folders with various meanings.)
Soma macOS applications can use similar scheme, under ~/Library/Containers/$application-id, but for the user more difficult to know which one is supposed to and which isn't.
Nope. In writing, it's technically ambiguous -- it could mean both "can't be installed" or "can't be uninstalled" but to me it means "can't be uninstalled". In spoken language, it depends how you stress the first syllable and both could be used, I guess.
That's why if you want to denote the installability of something, you should use the nonambiguous installable-noninstallable pair and leave the word "uninstallable" for the "can't be uninstalled" meaning. AFAICT, whether you should spell it as "non-installable" or "noninstallable" (note the hyphen) is up to you.
Again, in my personal experience, uninstallable definitely means 2 in [1]: "uninstall-able". Pretty sure I never saw that word used as "un-installable".
* cannot be installed
* can be uninstalled
The Wikipedia link you posted agrees with that interpretation.
I think “can’t be uninstalled” would be “non-uninstallable”.
This makes it clear (or at least clearer) that “able” is the modifying suffix to the root concept “uninstall”.
The OS doesn’t know what files that app created, thus can’t clean them up.
Eg on Windows if you grab a zip of an app and just put it in Program Files and run it there is nothing in Windows does to clean up the files in AppData or data in the registry if you just delete the exe etc you extracted from the zip file.
If the app developer providers an uninstaller it may clean up such data but that isn’t an OS feature.
There are many macOS apps that come with a pkg installer and uninstaller that cleans up in much the same way as an installer on Windows.
A little tip: if you use homebrew on macos you can use brew to force uninstall any application along with the zap argument and it will clean up most things. The app doesn’t have to have been installed via homebrew for this to work.
The only sane way to use desktop OS that I've found is to reinstall everything every 6-12 months and having some backup procedures to speed up configuration process.
Raycast is the present and future that quicksilver et alfred started.
The good thing is they're not mutually exclisive, so I've been running both and seeing which one I reach for.
When you search there is a + next to save in finder, click that, have name and matcha, + another option, choose other and scroll down to System Files, then set to are included.
https://apps.tempel.org/FindAnyFile/
I used it recently get rid of a bunch of Wacom garbage that was littered throughout my system and causing the mac to crash.
I guess they’re just expected to be left behind in case you change your mind and want to reinstall the app later. That way you’ll still continue where you left with the same settings.
They’re inert files and very small usually, comparative to our current SSD offerings.
And if apps are well behaved, only writing tiny config files in ~/Library/Preferences/ and the like, it’s not really a problem. The amount of space taken up in that situation was tiny even OS X 10.0 was brand new and 10GB was a common HDD size.
On the other hand if the app pulls an Adobe and leaves tons of crap strewn about, yeah it should probably come with an uninstaller.
Google is guilty of this sort of things as well. Well, it was anyway at some point. I somehow managed to get rid of everything, including their updater that re-installs itself regardless of what you do to remove it.
I wish we had more control over sandboxes so we could put some software in solitary confinement with no possibility to write anything anywhere without asking.
The new notifications when some software installs a background service is a step in the right direction.
I’d like this a lot as well, but expect it to come with the usual griping from devs about desktop OSes improving their security models and/or giving the user more control over what third party software can do. Anything short of full access to everything seems to be seen as tyranny.
Storage of (paid) license data.
Apple deals with it for first party apps by tying licenses to the App Store, but for any company who chooses to distribute themselves a true sandbox means they cannot store license data or even worse: they have to store it “out in the open” (which is to say: in a location that’s obvious and where piraters can start to reverse-engineer it).
Now, to be clear: I’m very much on the camp of “security through obscurity is not security at all”, but what I am saying is that there’s a significant and legitimate unsolved problem for devs to gripe about when it comes to sandboxes and restrictions.
I have yet to publish any commercial software, but if I were I think I’d go the route of Sublime Text and the fit client Fork which as far as I know stop at local license verification. If my business were so sensitive to piracy that its existence were threatened by it I’d probably make my main product an online-only subscription instead.
Now for obvious reasons Apple cannot force all macOS apps to be sandboxed. It was already a PR hit when they required Mac App Store apps to be sandboxed.
I know that: what I would like is more ways for the users to control this. I expect these companies to do everything they can to evade restrictions, and I’d like some ways to tighten the rules more than the defaults for some applications. I think from the OS perspective everything is there already, just not accessible through any UI.
> Now for obvious reasons Apple cannot force all macOS apps to be sandboxed. It was already a PR hit when they required Mac App Store apps to be sandboxed.
Indeed. But overall it’s an improvement for user security, just like SIP and the read-only system image.
I like that, too! Except that, at least for me, the bug is still present that I get notified of a background service that was added days, weeks, or years ago … over and over and over and over and over, even if I have turned it off.
Apparently they do this so they can control when it's updated, without having to go through any OS controls.
Needless to say, when people "delete" it they often are just deleting a stub rather than the actual multi-GB file set. :(
Yes.
Because it only happens when you use the specific "x" button in Launchpad
215781406 0x00020200=[removed] /Users/alin/Library/Application Support/Lunar
215781409 0x00010200=[removed] /Users/alin/Library/Preferences/fyi.lunar.Lunar.plistThese are the same apologists that mocked Windows for needing device drivers, as if the Mac didn't. Since Windows 95, when you plug a new printer into a Windows machine, it detects it and offers to look for a driver. What did OS X do for, oh, half its existence? NOTHING. You'd plug a peripheral in and nothing would happen. It was up to you to scrounge around for a driver disk and explore it for an installer. THAT one, at least, Apple has remedied.
But to go 20+ years since the OS X transition without an uninstaller is absurd. Then again, Apple is the company that forced you to manage all the content on your handheld Unix computer with a POS jukebox application... which it didn't even write.
So macOS is as shitty as Windows in terms of app install?
Anyway, accepted wisdom now is that applications should only run containerized, which would make uninstall as simple as deleting the container.
The stuff in ~/Library is caches + preferences + any other data. Deleting an app on macOS, even back in the day, did not delete the preferences.
The problems with Windows is that you needed an installer in the first place, and then an uninstaller, and then you couldn’t move an application to a different location. On a Mac, you can still just drag the application to the /Applications folder, or somewhere else, and then delete it later. The user data remains.
Though, it depends on the software of course. I’ve seen some bad-faith macOS installs that easily compete with bad-faith Windows installs.
These are the same apologists that mocked Windows for needing device drivers, as if the Mac didn't. Since Windows 95, when you plug a new printer into a Windows machine, it detects it and offers to look for a driver. What did OS X do for, oh, half its existence? Nothing. You'd plug a peripheral in and nothing would happen. It was up to you to scrounge around for a driver disk and explore it for an installer. THAT one, at least, Apple has remedied.
But to go 20+ years since the OS X transition without an uninstaller is absurd.
And sure enough one of said apologists down-modded and FLAGGED these simple observations. Then ran back to Reddit, I hope.
Something inbetween the two is worse, you get installers and uninstallers that are half-broken because they can never assume stuff about your system and just be broken but you never know exactly what they're doing.
Windows and macOS are both inbetween to various degrees, but I think macOS is a bit closer to Unix style (excluding App Store apps).
• Integrated automatic uninstall (which is fast).
• Automatic online updates.
• Apps have their registry and AppData writes redirected to a private location, which Windows can then clean up. It's a bit like the macOS app sandbox but the app isn't actually sandboxed, it's much lighter than that and there only for clean uninstalls.
• No need to retain downloaded packages or installers.
• If you use the .appinstaller feature, only the parts of the package that the user doesn't already have are downloaded so apps that use big runtimes (electron, jvm, flutter etc) can turn into small downloads if the user already has such an app.
• Don't need admin rights to install.
• Integration with Windows network admin tools. MSIX is declarative so Windows can do things like make apps appear without them being actually installed.
• There's a tool that monitors other installers and converts them into MSIX files.
So Windows has solutions for a lot of these problems. Unfortunately developers don't know about it and that's partly because Windows has a lot of bugs, especially in Windows 10 (which hasn't been receiving bug backports for a long time now). The best way to get these features is to use Conveyor which is a tool that abstracts you from the packaging tech and automatically works around the bugs (Disclosure: I wrote Conveyor). It also extends it with other useful features like checking for and automatically applying updates every time the app is run (if you want that):
MSIX indeed picks the install path for you but very few users want to change it these days. Chrome installer doesn't let you pick either.
How is any operating system supposed to log everything an application does and then remove it? If it's allowed to add data beyond its birth directory, would not an "uninstaller" only remove whatever the devs chose to and not 100% of its effect on the OS?
[0] https://stuffwhitepeoplelike.com/2008/01/30/39-apple-product...
Sent from my MacBook Pro
The main challenge is shared libraries; these are hard to delete reliably, even if the installer keeps a "use count" that it can increment and decrement. Just one non-compliant dependency will be broken if you remove all the compliant ones and a lib it needs gets blown away.
You have an application which is a normal app bundle. It doesn't update itself because, well, few developers have bothered taking this route, so you download a new version of it and you throw the old one in the trash. Now all of your preferences are gone and you have to set everything up again.
That would not be a pleasant user experience, would it. Dropping the bundle in the trash doesn't remove your preferences because it would be an idiotic thing to do.
App bundles are never installed anywhere as they are self-contained products, hence they cannot be uninstalled. For applications that actually come in the form of package installers which may place files in "annoying" locations like /usr/local/, you also get the functionality of uninstalling the software, because these packages contain manifests describing what files go in what locations.
You must be replying to the wrong person.
A UX for a more civilized age…
For ~/Library your application may often put its preferences there. That's entirely normal and expected. But, no, for /Library that's absolutely not common. Very few applications run as an actual "installer" and even fewer of those request admin privileges. But it is annoying those few times some software actually does it. At the least you can always tidy it up yourself on the command line.
The UX from early MacOS days is you can drag/drop the App to the Trash Can to uninstall it.
Does MacOS actually clean up the misc. files applications leave at some point?