[GeekyBear]

When a user mode application on the Mac doesn't just allow you to drag the app into the applications folder to install, it's a red huge red flag.

Personally, I'd look for another alternative from a company that better understands the Mac.

Chrome, for instance, previously used an installer that had to run with administrative permissions and famously ended up rendering systems unbootable.

System utilities and drivers are the exception, since they have to modify system folders to install.

Partition Magic was pretty awesome, BTW.

[post-it]

I started developing for my Mac a few weeks ago and I'm blown away by how easy it is to make an app that feels Mac native and includes quality of life features like CloudKit sync across all your devices. It's become clear that most companies don't give the tiniest shit about any of that.

[xp84]

It's obvious why they wouldn't give a shit about that, though - the Mac is not their main focus. Most companies that make software for PCs are obliged to make at least Windows and Mac versions, and to build an application "The Apple Way," using SwiftUI, and things like "CloudKit" etc. would mean a whole dedicated Mac-experienced design team and Mac-experienced engineering team. This would result in an app that fundamentally works and behaves differently than their app would on Windows, because these operating systems have different conventions and standards.

Now, that would make people like you and me very happy -- but consider it from the big company's perspective. Now instead of supporting a piece of software which has a single set of features and a single consistent (and 'braaanded,' eyeroll) Electron UI (and, mostly, a single set of bugs), you're supporting two completely different apps with completely different UIs. Building a new Important Feature means building it from the ground up twice, and QAing it twice. And customer service needs to be trained to walk customers through both of these different apps which work differently, and some of the customers are so confused, they can't even tell you if they're on a Mac or not.

25 years ago, before cross-platform frameworks existed (other than Java, which wasn't often used to these ends then), that was sort of how they had to do these things, and in practice, the results were either that a ton of hardware shipped with no Mac support whatsoever (wasn't worth it) or with a bare-bones Mac version on the CD that was incredibly low-effort, and clearly still written by people who barely knew how the Mac was meant to work.

This very real phenomenon is why we are cursed with cross-platform everything. The difference between a single cross-platform codebase and even two dedicated good-citizen apps is a vast chasm.

[asdff]

>This would result in an app that fundamentally works and behaves differently than their app would on Windows, because these operating systems have different conventions and standards.

Not always the case. Sometimes the gui app is just wrapping some script written in a general purpose language. Button just calls a function. Yes writing the function to draw the ui button element might take a different syntax, but they might go on to run the same underlying function.

At least that is how I like to write my gui software.

[molszanski]

I maintain a pretty complex app to draw 2D graphics for 3D objects. For packaging productions. Basically draw your packaging design with 3D preview. So this is basically a 2d3D editor with TONS of business and material knowledge.

It’s powered by react.

But it so decoupled from react you can slap mini gui in any other form / framework in a day

[vbezhenar]

Mac apps often do various things on your computer. Just because you dragged it to Bin, doesn't mean there are no leftovers on your computer. I'd prefer proper uninstaller any day.

[collabs]

> Mac apps often do various things on your computer. Just because you dragged it to Bin, doesn't mean there are no leftovers on your computer. I'd prefer proper uninstaller any day.

I think I know what you're talking about. There are likely files inside the ~/Library/Application Support/ or ~/Library/Caches/ folders for example.

What is the proper, Apple way to make sure these get deleted when we delete apps? Because I fear there is no universal solution here. There are some files that an app creates that some of the time I would probably want to persist uninstalls. But then these files should be in a user home directory, not in application support according to XDG, right? I feel like the OS should detect dragging of an app to the trash can and clean up its app support folders? I don't think it does this today but I think it should.

[pndy]

It wouldn't be hard to display "remove configuration and cache files?" modal during uninstall/trashing process. But it would be hard to go against own simplicity of platform usage idea - that's the problem.

KDE's Discover after you uninstall a flatpak application shows small infobar (still really easy to miss) saying "appname is not installed but it still has data present." with "Delete settings and user data" button.

But then, all sort of software even on Windows leaves some kind of traces of own presence.

In a perfect world we'd have a standardized application uninstall procedure - either by dropping icon on trash (which is something still many people do - especially on Windows) or by bringing similar to mobile solution with "x" on longer click. All of this controllable by options for advanced users including optional configuration and cache files removal.

[molszanski]

Mobile apps handle app data better. They have their own well defined jail to work with. Simple to locate “stuff”

[pjmlp]

Same applies to Windows or UNIX based packages, other than systems like iDevices, Android or UWP, where applications are sandboxed.

However people around here hate sandboxing on their OSes.

[didgetmaster]

This problem has been around for decades. An application installer doesn't just copy some files to a few directories. It may put them in hundreds of different places. In addition, it adds entries to the registry or other system files. Even the best uninstallers or cleaners miss something when deleting the app.

This is one of the many issues my side project is designed to address. Imagine if installing every application meant just dropping it on the computer. The software 'package' was just a list of data objects the comprised all the files, config settings, etc. Needed to run the app. All these objects would be copied to the storage drive(s).

Imagine further, that the operating system did not have a central registry. Instead, all configuration was managed via a set of configuration objects, spread all over (preferably in the app folders). The configuration manager was just a program that could find every configuration object and make them appear to the user (and the OS) like they were in a unified file.

If a configuration object was copied anywhere in the system, it looked like its contents were just appended to the configuration store. If you deleted an object, all its settings just disappeared.

Uninstalling an application would mean just deleting all the objects in its package. The files would be gone and any configuration settings with them.

This is just one of the features my 'file system replacement' project is designed to handle.

[noAnswer]

> Uninstalling an application would mean just deleting all the objects in its package. The files would be gone and any configuration settings with them.

Applications developers of the world. Please always make "keep configuration" an option with your uninstallers! I don't like the mobilification of PCs. For example, because of some issues, I wanted to try a different version of Thunderbird. I had the Snap version. Uninstalling it meant losing all its mails. I wasn't expecting that. Like at all!

[nottorp]

I think it's a snap "feature".

[pjmlp]

The is actually what Windows App Sandboxing does for Win32, the registry is virtualised and all writes kept track from, however this needs to be explicitly enabled, e.g. using msix packages, or the application management tool.

https://learn.microsoft.com/en-us/windows/win32/secauthz/app...

[GeekyBear]

Are you under the impression that Windows uninstallers don't leave files and registry settings behind?

[vbezhenar]

They certainly can clean everything after them. And I'm pretty sure that many of them do. When macOS user drags application folder to the Bin, application does not have a chance to clean after itself.

Just because some Windows uninstaller are bad doesn't mean that all of them are bad, or that uninstaller concept is bad.

Now I'd welcome for operating system to be built in a way to let user to delete everything related to the application. Maybe android or ios are built this way, but not macos.

[gopher_space]

> And I'm pretty sure that many of them do.

My AppData disagrees with you.

[fragmede]

apt purge software on Debian does a pretty good job of that, but it's got limited adoption.

[PearlRiver]

I use this

https://github.com/Klocman/Bulk-Crap-Uninstaller

The nice thing about Windows is that people have been writing software for it for decades. A very underestimated advantage.

[GeekyBear]

> The nice thing about Windows is that people have been writing software for it for decades. A very underestimated advantage.

AppZapper has been doing the same thing on Macs for decades.

https://www.wikipedia.org/wiki/AppZapper

[SpaceNugget]

Sorry an advantage over what? What desktop operating system in common use _hasn't_ had decades of development of pet projects on obvious problems like system cleanup? Literally every operating system has these kinds of things

[jimmaswell]

The Macintosh came first, technically.

[aucisson_masque]

Yeah. But mac is still and I mean BY FAR the cleanest of all operating system when you got to uninstall stuffs.

Windows is as bad as Linux, leftovers everywhere without any sense whatsoever. Some company use a directory, other use another, makes no sense.

On Linux, at least there is some kind of uniformity but since all apps install with sudo permissions, they get put everywhere and you never really know where.

On macos, you got 2 folders to look for, all in the user directory (app, application support) and that's it.

[asdff]

If you are aware of this not hard to manage. Grep. rm -rf. Done. Usually its pretty tiny folders at least. Heavier stuff usually software makes a directory under Documents. Kinda nice in a few cases having it set up like this. For example I can delete the app but preserve my config. Drop the app right back again and no setup its turnkey and works.

[vbezhenar]

How do you know that you need to remove:

    /usr/local/bin/xxx symlinks
    /etc/hosts modifications
    /Library/PrivilegedHelperTools/com.docker.vmnetd

after you moved your Docker folder to Bin.

That's only system files, there are also dozens of other files in $HOME.

I guess you can do `find / -name 'docker'` and `grep -iR docker /` but that's a bit ridiculous.

[asdff]

You can check these things out periodically. Probably a good exercise to understand parts of the OS if any of it seems unfamiliar. At least they are there, standardized locations where these sorts of tools might leave these sorts of crumbs behind. There are reasons why things go where they do. Seems byzantine until you write your own tooling and realize a lot of it is convenience functionality.

[fragmede]

grep for what? How am I supposed to know that the Foo app installed stuff under ~/Libraries/Application Support/com.bar.corporation?

[asdff]

Sorry you'd use Find not grep and you'd search for "Foo" or "corporation".

But if you know to do this you know that these things are stored where they are under Libraries.

[fragmede]

Sorry for being nitpicky about the exact tool, my broader point is that "Foo" or "corporation" isn't always obvious and is sometimes someone/thing you've never heard of before and would never think to search off the top of your head.

[asdff]

But like where would it be found? People are saying gotchas to me but they are saying things like host files or other directories where one might find services stored on macos. These aren't in some cryptic areas is what I am saying. If you are familiar enough with the OS to understand the concept of launchd and background services you know about these directories and what they might contain. These things are where you kinda ought to put these sorts of services if you are to write that sort of service for macos.

And really, this is better than what I've seen in linux where everyone wants to be cute with their own hidden directory paradigms.

[jdeibele]

Me, too.

There is Mac Cleaner https://freemacsoft.net/appcleaner/ which does a good job of removing preferences as well as the application.

[ValentineC]

I use AppCleaner: https://freemacsoft.net/appcleaner/

Raycast has a built-in uninstaller as well.

[sunnybeetroot]

Pear cleaner is the successor, you’re welcome :)

https://github.com/alienator88/Pearcleaner

[ValentineC]

What's new with Pearcleaner? I don't see a comparison chart in the GitHub repo, and I don't care for features other than completely uninstalling an app.

AppCleaner still works fine for me in Sequoia.

[smallstepforman]

Haiku package system has an unparalleled installstion, deletion, boot into previous states, data integrity (read only packages) and dealing with conflicting library policy. Its a technical crime that other systems are not copying Haiku packages … they’re several decades behind. IOS is half way there …

[itsdesmond]

I got bigger problems.

[everdrive]

>When a user mode application on the Mac doesn't just allow you to drag the app into the applications folder to install, it's a red huge red flag.

And the companies that make such products _never_ care about making sure an uninstallation is actually clean.

[ryandrake]

"Does it have a way to uninstall, and does that uninstallation clean every application artifact?" is such a great litmus test for just how much a software company actually cares about having a proper finished product that respects the user. Nobody forces a company to do it, but when they don't do it, you can probably bet that they're cutting corners and disrespecting the user's machine in other ways, too.

It's like "Do you return your shopping cart to the cart storage or leave it in the carpark?" You're allowed to just shove your cart away and drive off, but people who do that are highly probably assholes in other ways, too.

[GeekyBear]

Well said.

I would add an appreciation for companies producing non-bloated, native software.

[al_borland]

In the file menu of the installer, there is generally an option to see all the files it is placing on the system with full system paths. I generally note this down so I can make sure to clean things up completely if/when needed.

For app that just get dragged into the Applications folder, they end up doing all this additional file creation on first-launch instead of via an installer. That actually makes it harder. For those I tend to search the ~/Library folder for the name of the app and the company that made it, hoping I find all the remnants to delete. There are apps, like AppZapper and AppCleaner, which try to automate this process. I still think it’s ridiculous that Apple never solved for this. It’s one of the reasons I always do a manual migration to a new Mac. It feels like the only real way to clean things up.

[Someone]

> I still think it’s ridiculous that Apple never solved for this.

I think that problem, in general, is unsolvable on the Mac. The OS cannot know whether a file that an application creates is a user file that should be kept on uninstall or an application one that, maybe, should be deleted on uninstall.

(Maybe because Apple’s guidelines say (or at least used to say) uninstall ers, if you have one, should keep preferences files around, in case a user reinstalls the app later. Also, applications may ship with files (e.g. fonts, sounds, picture libraries) that users may want to keep around)

> For app that just get dragged into the Applications folder, they end up doing all this additional file creation on first-launch instead of via an installer

For quite a few things that an installer can install, applications cannot do that, as they want to install them into protected directories.

I think most of the leftovers whose locations you cannot gauge from looking at the file list in the installer are for caches, preferences, logs, etc.

[al_borland]

Yeah, it's usually plist files for preferences and maybe an Application Support folder with whatever the app needed. Occasionally some other things. More recent apps end up with a container in there.

The upgrades process for some apps almost necessitates that the those files/folders are decoupled from the app and can live on, as the app upgrade ends up deleting the existing app and dropping a new one in it's place.

I get wanting to keep user preferences around in spirit, but in practice keeping them forever can sometimes be problematic. If I tried an app, then installed it again in 8 years. I usually want to start over. For users who don't know about the ~/Library, this is hard. Especially now that Apple hides it in Finder.

When having issues with an app, deleting those files (or simply moving them somewhere else like the desktop as a test) is a great troubleshooting step to see if its an app problem or something corrupt in your settings or support files. When most users reinstall an app as a troubleshooting step, they aren't doing much of anything, with all those files sticking around.

UTM buries their VM disks away in a container inside the ~/Library. I have a 20GB disk in there. It's not always trivial small files. If someone deletes UTM and forgets to check for old VMs first, that's a big hit.

What I'd like to see is a something, maybe in the Settings app, that lists all the applications on the system and 3 options.

1. Remove Application, keep Library data 2. Remove Application and Library data (have it give into on what files are in there) 3. Remove Library data only (this could be used to refresh an app to start over with it)

Maybe in addition to that, as part of the Optimize Storage feature, it could crawl through all those old orphaned application support folders and containers, and list all the ones without an app installed, show the size, and the user can choose to get rid of them.

Looking at how much junk I have out there now, I may just do a re-install of my OS to clean things up soon. I usually wait for a new system, but this M1 Pro is lasting a long time. I recently migrated off 1Password and it seems to have a bunch of junk out there, including 4 year old weekly archives of all my passwords that it took for a few months for some reason. The files are encrypted, but who knows how long that will actually be good for.

[xp84]

I'll have to check that installer trick the next time I use one.

Isn't the "Receipts" folder that so angered OP kind of that same thing? I thought those included the list of files installed.

In general, I think some worries about removing "every trace" are overblown, though. The receipts, for instance, are inert and they're not filling up the disk or consuming RAM.

Of all the things Apple does in the name of "security" it's funny to me that they've never even tried to build uninstallation functionality. Even though a majority of apps with "Installers" use, not arbitrary installer executables like Windows, but .pkg files that open with Apple's "Installer" app. That means it's Apple's code placing most of those files in place, and even if the install includes a "script" portion, it seems like a solvable problem that Installer.app could monitor the files being added or changed by the script process, to at least let you view a log of what happened if not reverse the changes.

[prerok]

There are two cases: I am uninstalling because I never want to use the app, or I am uninstalling because I know I currently don't need the app and will reinstall after 6 months when I do.

An example of first is a trial of an app but you don't like it in the end, an example of the latter is a game that you might want to play with the same settings later.

Now, I want the option. In the first case I don't want these inert files taking up disk space and in the second I want to have those files.

[al_borland]

I stopped trying new apps as often, because I don't like how I can never really go back to a state before it was installed, unless the developer actually put effort into not spraying files everything and not leaving a trace once gone. I appreciate these developers very much, and am more likely to keep using their apps. The most junk an app install puts on my system, the more likely I am to want it gone.

[gopher_space]

> In general, I think some worries about removing "every trace" are overblown, though.

It's impossible to overstate how little I want random crap on my machine.

[eviks]

Almost never, indeed, so you need some 3rd party trash utilities with databases and heuristics. Though that's also on the gardener and his bad OS design where forced compartmentalization is's trivial, the weeds will never want to root themselves out!

[sneak]

This application is a custom one to use custom features on specialized hardware. There are zero alternatives.

[Aurornis]

> When a user mode application on the Mac doesn't just allow you to drag the app into the applications folder to install, it's a red huge red flag.

The applications you drag to the Apps folder can do the same things when you run them the first time.

Being able to drag into the Apps folder doesn’t mean it won’t do things outside of that folder.

[longislandguido]

> When a user mode application on the Mac doesn't just allow you to drag the app into the applications folder to install, it's a red huge red flag

But a lot of Apple first-party applications require installation. Packages for me and not for thee.

As do Chrome/Edge/Teams/Etc

It's 2026 and Apple still doesn't have an equivalent to MSI + the Add/Remove Programs control panel Windows has had for 30+ years.

Windows always saves a copy of the uninstaller package stub so if you trash the media you can always nope out (usually—unless the developer went out of his way to break it).

And no, the App Store is not a fix-all for this.