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.
This is just unbelievable. The billion $$ company cant just automate the uninstall procedure for their users? How hard would it be to auto delete the contents of ~/Library? Or have some periodic auto clean? one can always dream, no?
I wonder how many users that have uninstalled VMware still have 30 gigs of unused VMs lying around on their disk.
No. The user data, preferences etc under ~/Library/ belong to you - whether it's 3 kB of preference toggles or 3 decades of email.
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.
Consider that sometimes people do actually want to clean up all artifacts of an installation, and don't want to go digging around in a bunch of machine-generated directories trying to guess what to delete.
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.
> 1) app is buggy and I'm trying to fix it by reinstalling from scratch
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.
> Note that if I am trying to fix an app that I want to keep using I sure as hell may want to keep the preferences.
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.
The user-specific parts of the registry are powered by files in the user‘s profile and ACLs do not normally allow other users to have access, so the same issue applies there too
lots of them leave crud in HKLM/System and HKLM/Software, as well as I think HKey_Curent_Config
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 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}/.
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.)
I think on macOS programs are able to store data "inside" themselves, because .app files are just folders. They usually shouldn't put stuff in Library.
That's wrong, of course they should put stuff in the ~/Library if necessary. That's why if you update an app it just replaces the whole .app directory, and also if you uninstall something and then install it again all your settings will still be there.
> Also, "uninstallable" means "cannot be installed"
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".
> When I delete an app on an iPhone, all its data is also deleted. Gone. Why can't it be the same for the Mac?
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.
Nope. Delete your Google apps. Reinstall one. It'll still pick up the accounts you used prior. Well, it used to anyways. It's not an iCloud keychain thing (or it wasn't).
There is an exception on iOS as well. Apps can register write access to a custom location on iCloud that will persist after the app has been deleted. You can see all the leftovers in Files.app
The helpful part would be for the huge company to give users visibility and an easy choice, not your simple "delete everything" strawman
The data doesn't "belong to me", that entirely depends on the specific app/type of data (and this concept of a few kbs of very important stuff I've carefully changed in the app's settings menu and would even like to track in vcs vs all the other junk is also largely missing, though that's also on the app devs)
In Ubuntu i can do apt remove to just uninstall the binary or i can apt purge to remove config files as well. Is there an native macOS equivalent for this?
The package manager will never attempt to clear stuff under user's home directories, just like macOS will not clear stuff under ~/Library. The package manager doesn't and cannot know what content an application has created while in use. Only the application itself knows that.
Flatpak applications under Linux get their little sandboxes under ~/.var/app/$application-id where they can create whatever they want and the user can remove it from there when needed. Except for that, any other path that the app can access is decleared in the permissions; or the user is very well aware, because he picked the file via filechooser (portal).
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.
At least provide a user friendly way to manage it. For instance, offer the option to either delete, backup, or leave in place when uninstalling. For things left in place, have a GUI to view and manage them.
This isn’t something Windows or Linux does either. If you delete an application the user data is not touched.
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.
You can also just run apps from anywhere - network drives, removable disks, disk images etc., so the system can’t just delete settings for apps it’s currently unaware of.
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.
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.
> "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.
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.
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.
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.
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.
It's by design. The files are your preferences, not the application's preferences. A lot of people throw away the old app bundle when they download a new version of it for applications that don't update themselves. It would be an infuriating user experience and absolutely absurd design choice if dropping the bundle in the trash also erased the users' preferences.
~/Library contains stuff for lots of apps and they don't necessarily have to be in a folder with the name of the same bundle ID. Only sandboxed apps are much more strict about this.
The OS also doesn’t know when you uninstall an app whether the app is really gone. You could have copied it to a network drive first, or maybe you have a different version of the app in a folder somewhere. Who knows?
Apps that install persistent services typically check if the .app bundle exists in applications so in most cases just trashing the .app is enough to stop any errant left overs from executing.
No desktop OS has uninstall procedures. Both Windows and Linux software packages often will leave trash files scattered around as well.
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.
Well, if it's a really modern application it will leave everything in only one folder in ~/Library/Containers as part of the sandbox. Besides the obvious security advantages of the sandbox this makes cleanup a lot easier too.
What I normally do is use finder to search for system files and delete them also along with the .app . You have to add system files to the search manually though.
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.
Homebrew Cask can remove application-generated files if you pass the --zap option to "brew rm". Cask definitions include a list of known paths to those.
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.
The delicious era … it was nice to “be there”, but honestly, I always felt like it was too much glossy. And I usually missed some feature there and felt back to the “boring” apps.
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.
Haha that's almost exactly the reaction I had about two weeks ago. "What is everybody talking about?" But then I tried it and yep, I think it's a bit better overall, while there are a couple of little things I'd say I sometimes miss.
The good thing is they're not mutually exclisive, so I've been running both and seeing which one I reach for.
This is complete bullshit. Alfred 5.0 was released in July last year and the last update 5.0.6 was in December. Packal is online and a couple of packages were updated 1 week 6 days ago. And not only that, but to replicate most of Alfred's functionality in Raycast, you have to rely on plugins and hope they are both secure and maintained by somebody whereas Alfred's functionality is maintained by the Alfred team. Stop spreading misinformation.
Different user, but I too “remember” first quicksilver and then Alfred shutter. Did I hallucinate that, or did it happen and later have a revival, or what?
I never had macOS remove those files automatically when dragging the app to the trash. I still have files left from 4 MacBooks ago (for apps I haven’t installed in a long time) because I’m always migrating the home folder.
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.
> 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.
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.
> 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 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.
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.
There’s one legitimate dev gripe that Apple has yet to solve properly:
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.
While I kind of agree I’m increasingly of the opinion that piracy isn’t a battle worth fighting, with pirates mostly consisting of those who wouldn’t have been customers anyway.
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.
I’m increasingly of the same opinion as well, but that choice is up to the companies and developers who make the software and if they decide to implement license verification there’s no way to do that reliably within a sandbox (unless of course it’s online-only, but then you get a whole different issue affecting offline users)
Definitely agree. Getting all the licenses in order is a huge pain when setting up a machine. I use notes in the iCloud Keychain but that’s a bit of a kludge. Some first party support would be great. The infrastructure is already there for this stuff to be encrypted and protected properly.
macOS already has a sandbox. In practice many sandboxed apps can't actually write to /Library or ~/Library. They write to a sandboxed directory that pretends to be ~/Library further containing directories like ~/Library/Application Support. The real path of that directory is generally under ~/Library/Containers.
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.
> macOS already has a sandbox. In practice many sandboxed apps can't actually write to /Library or ~/Library. They write to a sandboxed directory that pretends to be ~/Library further containing directories like ~/Library/Application Support. The real path of that directory is generally under ~/Library/Containers.
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.
> The new notifications when some software installs a background service is a step in the right direction.
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.
Autodesk Fusion 360 does this too. It's "installer" downloads the multi-GB package for it + installs the whole thing into a local user folder which the OS has no knowledge of.
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. :(
Having all those files around from an app I've used long ago feels really untindy to me. Even though, practically, it's ok. It still bothers. Feels like if you dispose of some old stuff by throwing them on the roof. Even though it works, it feels messy.
AppCleaner is no good after you deleted an app by other means and it left crap on the hd tho… as far as I recall CleanMyMac was a paid closed course app?
The UX from early Mac OS X days would actually be to either have a self-reliant app bundle that you can simply trash or a pkg-based installer which would leave a so called receipt and ideally an uninstaller.
>"I recently had to uninstall some apps and it’s common for apps to litter files throughout /Library and ~/Library."
For ~/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.
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.
Lots of apps can litter junk all through macOS that goes well beyond the ~/Library folder. To totally rid yourself of everything, just manually search for the app name using FindAnyFile [0] and trash them.
I'll help you out by offering this common scenario:
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.
I agree. How is that "helping me out?" I never said dragging stuff to the trash should do that. I said there should be an UNINSTALLER, which is the whole topic at hand here.
It helped you understand why dropping app bundles in the trash does not clean out per-user property lists.
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.
The Windows apologists are non the wiser :). Windows still has no full uninstaller that can clean the registry droppings many apps leave and other files, requiring to use specialized apps for that. And sometimes it would also fail to uninstall the binary. And Windows bizarely needs to retain the huge installers, so that part is strictly worse vs Mac
In fairness to Microsoft, that's only true for apps that don't use the official packaging format. Official packaging format? Yep, if you distribute your app as an MSIX file then you get:
• 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):
How is this fair at all?
1. This is "only true" for almost all the apps
2. A much better alternative without that waste already exists in 3rd-party apps, so no new packaging format is needed to fix it
3. Is this new shiny toy MSIX the one that doesn't even allow changing installation path?
The problems you're describing are technically problems of apps, not really problems of Windows (any more). Yes arguably the line is blurred, you can say this is a pedantic distinction because Windows = the apps that people use. But the tech is there.
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.
The old tech is also the official OS one, so all the responsibility for not fixing it lies with the OS, can't blur it with the apps
Having a better alternative while still not fixing the old system does not shield the OS from this.
Neither does the existence of other bad apps like Chrome shield the new system from the blame for making the same obvious mistake, especially when the example of macOS with its simple bundled app folders that you can just drag&drop around has been right there the whole time
Your post went dead for some reason, but that seemed unfair so I vouched for you and upvoted it. We may not fully agree on this, but your discussion is civilized and should not have been flagged.
I think we can choose between either full managed app store mode like on ios (no low-level control but full automatic uninstallation + synced settings and such) or Unix-style where you have full control.
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).
You're not supposed to speak unkind of Apple products [0] or its peripherals North Face, Patagonia.
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?
It isn't supposed to, of course. But there should be a standard facility offered by the OS that well-behaved apps can use to install components, through which the OS WILL log each of them and be able to remove them later.
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.
What bothers me even more is the fact that nowadays newly installed apps even need to "ask user for permission to access the {Documents, Downloads, Desktop, ...} folders". This is especially true when using a new terminal emulator like iTerm or Alacritty
If you mean it bothers you because you just want it to work then you’re arguing for apps to be able to litter and scrape however they want and I disagree. If it bothers you because good-faith applications are asking for permission as they’re supposed to but bad-faith ones are getting around those permissions and doing what they want anyway, I agree.
> Well, looks like we got a working uninstaller with a good user experience for free.
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.
The article doesn’t explain how to install an application that can be uninstalled using the "X" button in the Mac Apple Store (MAS). Instead, it explains how to activate the button in apps that are already installed. So, your theory that Apple might eventually prevent the installation of an app is not relevant here, as the article isn’t discussing that at all. However, it’s possible that Apple could update the verification process for the MAS app to check for an empty "receipt" file and then prevent the application from starting until the user deletes that file. This seems like a reasonable expectation to me.
Same here. It made me realise that un- is the wrong prefix for what we mean by uninstall. It should probably be de-, as in "I deinstalled the program" or "This app is deinstallable".
It’s not the wrong prefix. It’s the same ‘un’ you get in e.g. ‘unlock’ or ‘untie’. The ambiguity of words like ‘unlockable’ or ‘untieable’ is a standard exercise for morphological tree drawing in Linguistics 101 ([un [lock able]] or [[un lock] able]). The existence of structural ambiguities in words isn’t really any more disturbing or problematic than the existence of structural ambiguities in sentences (e.g. ‘John saw the man with a telescope’).
(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.)
Why are an applications files physically moved elsewhere in the first place? Simply leave everything in the app bundle, and put symlinks for anything the OS is expecting elsewhere. Cleaning up app deletion would then be pruning dead symlinks.
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?
Those aren’t app files, they are user configuration files. They can’t be created inside the app bundle because the app is signed, and any modification will invalidate the signature.
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.
Also having your app data stored within a bundle that (during updates) is literally just removed and replaced would lead to data loss. I don’t think there is any system that actually stores app data within/next to the binary itself.
That was quite common during the Windows 9x days, leading to that long period of time of problems later under XP with old apps only running under an admin account.
In my experience there are both a users config files and an applications support files strewn all over the place with abandon. Maybe I wasn't clear, I'm suggesting distinguishing out-of-bundle application files by making them symlinks:
> Why are an applications files physically moved elsewhere in the first place?
Application support files are still new files that get created from scratch, not moved from the application bundle.
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.
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.
That's neat! Recently I've been looking for resources on getting a py2app MacOS app notarized by Apple but haven't been able to find any precedent. Would love to see a tutorial for that too since you guys seems to be domain experts in this
question:has anyone succeeded in uninstalling kite (python autocomplete for spyder) at all locations.
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.
If only we used the de- prefix rather than un- we would be safer from ambiguities: "I saw the app was deinstallable so I deinstalled it, but now I cannot install it back as it is totally uninstallable!"
The thing I hate more than anything else about technology is when people make things that are intentionally shitty, for no other reason than they want it to be shitty.
"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*
Prior to the MAS it was well understood that moving an app to the trash was roughly equivalent to “uninstall”. With the introduction of MAS, no one actually looked for this X button. Exactly zero billions were made safeguarding it. If it’s so trivial to make appear, it’s because it’s a convenience specifically afforded to people who use Launchpad.
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.
you know, when you and the throwaway account at the top of this thread talk in the ways you have here, you make it extremely easy to simply dismiss your opinions as those of a crazy crackpot.
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.
Conversely, citing the benefits of a broken system does not justify it's existence. Thousands of good things happen in broken systems, but that doesn't justify their failure points.
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 benefits of a broken system does not justify it's existence.
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.
It isn’t broken. The fact is that you and the other posters simply don’t like or even don’t grok it. So you climb your ivory tower to declare that emperor is not wearing any clothes. It’s trite, and it’s boring and it’s lowering the quality of discourse.
The broken system is not the uninstall process, it's the rift between Apple's services (the App Store) and MacOS as a development target. It extends to the iPhone, and it's such a restrictive and arbitrary process that Apple is being forced to reconsider it in Europe. You cannot sustain a system where you neglect OS-level features like software management to prop-up your SaaS distribution service.
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.
You’d have a point if the status quo had changed since the introduction of the MAS, but it hasn’t. As explained in other threads, in order to offer the same functionality, Apple would need to implement tighter controls, similar to those found in iOS; you yourself have complained about these restrictions, and we'd hear the same trite iOSification nonsense, or someone blathering about user freedom, when what they really mean is freedom for developers to fuck with other peoples machines. So this appears to be yet another shitty stick with which to beat Apple, especially given that it is really no better anywhere else on the desktop.
"right" click the app and select "Open" creates the same exception without the need to open settings. There's also an equivalent terminal command for the exception I can't remember.
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?
I've just tried that, and I still get the gatekeeper warning, so it doesn't seem to work anymore on macOS Ventura.
Executing 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.
> Uninstallable is nice, but how about something on making apps not in the app store trivially installable without developers paying Apple a ransom fee?
No, it doesn't. It only shows how your app's data can be deleted if you uninstall your app in a certain way. The scary warnings for apps that aren't notarized are still there.
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?