Making macOS Apps Uninstallable
notes.alinpanaitiu.com
notes.alinpanaitiu.com
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?
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.
I wonder how many users that have uninstalled VMware still have 30 gigs of unused VMs lying around on their disk.
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"
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.
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.
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.)
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”.
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...
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.
It means both cannot be installed and can be uninstalled, depending on context.
For example on Windows if you grab a zip for an app and just put it in Program Files (or anywhere), run it then delete it there is nothing Windows does to clean up the files in AppData or entries in the registry.
Same on Linux if you grab a tar.gz, extract it to /opt and use it then delete it. All the data in ~/.config etc remains.
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.
So if you wanted to remove Obsidian that you had manually installed using the dmg you could do `brew remove --cask --force --zap obsidian` and it will remove the Obsidian .app, plist, cache files in Application Support, etc.
You can also check the brew formula file which is just plain text to see exactly what it will remove during a zap which is quite handy.
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.
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."
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.
The OS doesn’t know what files that app created, thus can’t clean them up.
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.
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.
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/
Then just trash them.
[1] https://arstechnica.com/gadgets/2007/05/the-delicious-genera...
I wholly disagree with rogueamoeba's assessment that these were "style over substance". They were dead-simple to use, and you could always disable the smoke if you hated fun. They may not have all the bells and whistles of the bloated 40MB disc burning suite, but if all you wanted to do was burn a linux iso or transfer some songs to stick in your car stereo, this was the go-to tool for the job.
https://weblog.rogueamoeba.com/2006/11/06/
Also I find it ironic that rogueamoeba lambasts the "delicious generation" when I think their Piezo app would fit right into it.
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.
The good thing is they're not mutually exclisive, so I've been running both and seeing which one I reach for.
Raycast is the present and future that quicksilver et alfred started.
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 when 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 relatively heavy 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 git client Fork which as far as I know stop at simple 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. :(
Because it only happens when you use the specific "x" button in Launchpad
Yes.
A UX for a more civilized age…
215781406 0x00020200=[removed] /Users/alin/Library/Application Support/Lunar
215781409 0x00010200=[removed] /Users/alin/Library/Preferences/fyi.lunar.Lunar.plistFor ~/Library your application may often put its preferences in ~/Library/Preferences/ and partly in ~/Library/Application\ Support/. 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.
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.
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.
By now the filesystem permissions hierarchy really should be extended into Group → User → App.
You can see the half-baked workarounds many operating systems use like controlling access to entire folders like Documents, Downloads, Photos etc.
Why not just make it fine-grained and let us permit and deny apps' access to individual files, and see which app created which file?
Yes, but the downside is that you're now relying on an unstable interface (as I understand it, this behaviour is not documented as a contract anywhere). Apple would be free to break you at any time.
(Technically, ‘unlockable’, ‘uninstallable’ etc. don’t exemplify pure structural ambiguities because the ‘un’ prefix is used in two different senses, but the two meanings do have different structures.)
That would work reliably for me, even for installs not actually managed by Homebrew.
Such a system could also potentially be enforced. Is it a symlink? If "yes" allow the write to ~/Library or wherever else. If not, deny it.
Genuine question: is there some reason not to do this?
There’s also the matter of permissions, some apps may be installed by the admin, but the app might not run with admin permissions for some users.
> Why are an applications files physically moved elsewhere in the first place?
It’s possible there’s misunderstanding in what we both consider application files. Anything that exists in the AppName.app bundle never gets modified, deleted or moved. And it’s not possible to create any new file in that bundle, not even symlinks, without invalidating the signature.
For any files that need to be modified, my suggestion would not work at all. But I'm sure there's cases developers could symlink unmodifiable files.
I know I've seen anything and everything in the users Library folder. (Application launch splash screens for example.)
An attempt at an open source AppCleaner, I worked on a script, called zap (https://github.com/idianal/zap), that aims to replicate much of the same functionality (without a GUI). The benefit for users is they can see exactly what it is doing on their computer.
Here I outline the limitations: https://idian.io/posts/2022/writing-an-app-uninstaller-for-m....
I was tricked into selecting to install it one time installing anaconda/spyder. I’ve since removed all of that including anaconda and followed the now scrubbed uninstall instructions on their (defunct kite’s) website.
However a .kite folder keeps showing up in my ~/
I’ve deleted tons of times and searched thru /library and ~/library
I resorted to locking .kite hoping that if some hidden process were using it it won’t have write access anymore. But admittedly I have no idea what’s creating this dir and the reason for it or if I defeated it by locking that .kite folder down.
Thx
It's the second time I read about Lunar, and my curiosity led me to their impressive monitor database: https://db.lunar.fyi/
Weird, so did I! Why!?
After reading it again, there are still an ambiguity though: impossible to install, or that you can uninstall?
"Hello billion dollar company, I would like a way to install and uninstall my software in your operating system."
"No."
"Wh.... huh? Please?"
"Pay us money and go through our app store."
"Um....why? No? Please? Can't you just let me make software and give it to users, without going through you?"
"No."
"Why not?"
"We don't like it when you do that."
"So?"
"So you only get to do what we say, how we say."
"Why?"
"It makes us happy."
"And what about the users' happiness?"
*laughs in dollar bills*I can’t think of a use case where one installs apps and runs them from websites but wants to uninstall them from the modern equivalent of At Ease.
Apple’s choices may not be what everyone wants, but they’re not without upsides for those that do.
What kind of "upside" for Lunar users are you alluding to?
challenging opinions and "randomly" putting things in quotes to make them appear "fabricated" are not how you win people to your side, or even trigger them to pause and think for a moment. this is how you encourage others to develop a strong aversion to anyone talking like you or anyone having the opinion you have.
with the most positive and pure tone possible: be constructive or be quiet; you're severely hurting your own cause.
If Apple had effective processes that allowed for constructive solutions to this problem, we wouldn't be here today. Instead, we see Apple fighting regulators in Dutch court, ducking regulatory fines and funneling developers into a ancillary profit-driven toolchain. It's not just crazy crackpot opinions, it's a profit motivator and something Apple is clearly self-conscious about.
citing the flaws of a working system does not justify its destruction, either.
I'm not saying anything about Apple or its actions, either way. I am only saying that the tone and language used in the two posts I referred to will drive people away from understanding what is being said and why it is important.
Pragmatic interpretation of the issue at hand doesn't lower the quality of discourse at all. We only veer off into ivory tower territory when people claim that other people's experiences are illegitimate, and then deny the problem because they're not personally impacted.
Oh that's right, we can't control that, just have to pay the tax.
1. Drag into Applications, try to open it, get warning.
2. Open System Preferences > Security & Privacy > General, click on lock, enter admin password, allow the app to be opened.
So it's not as easy as it used to be.
If either of those aren't satisfying, you can always drop the check entirely which I can't personally recommend.
I don't think you can? Unless I am missing something?
You can add Terminal to "developer tools" so you can launch stuff from the shell without Gatekeeper interfering, but is there really a way to disable the gatekeeper warning for downloaded apps altogether?
How does that work? I use iTerm so how would I add it to "developer tools"?
If the Developer Tools section isn't visible, this command should fix it [1]:
spctl developer-mode enable-terminal
sudo spctl --master-disableExecuting the command does make the "Anywhere" option show up in System Settings, but from testing it doesn't seem that this option makes a difference.
The user gets a warning initially saying that the download is "damaged".
Isn't that what the article shows how to do?