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.
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?