(chalmovsky.com)
Maybe Samsung used that when naming their product.
I am old, but I miss the days when the install process was copy . to /<appFolder> and the uninstall process was delete /<appFolder>
And, I wonder if a (corporate) development organization's overall cultural friction around critical / negative feedback -- in this case integration issues in the technical sense of pulling together modules built by subteams to compose a final product -- could be worth investigating when challenging metrics like the above are identified?
This "18 steps" seems like a problem. And I wonder if it's a prioritized concern at SAM.
SNARK: The "magic" could be how corporate culture is communicated to users merely through usage of Samsung Magician.
BTW: I am currently working on a hobby project called Didgets. It is an object store that does a lot of cool file system stuff and relational table manipulation and analysis. It is available for free download at http://www.didgets.com
The install process is to unzip the downloaded file to a directory. The uninstall process is to delete that directory.
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.
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.
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.
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.
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.
Raycast has a built-in uninstaller as well.
AppCleaner still works fine for me in Sequoia.
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.
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.
AppZapper has been doing the same thing on Macs for decades.
However people around here hate sandboxing on their OSes.
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.
There is Mac Cleaner https://freemacsoft.net/appcleaner/ which does a good job of removing preferences as well as the application.
And the companies that make such products _never_ care about making sure an uninstallation is actually clean.
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.
I would add an appreciation for companies producing non-bloated, native software.
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.
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.
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.
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.
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.
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.
https://de.wikipedia.org/wiki/Norton_Partition_Magic#/media/...
Then this was the top comment.
Thanks for PartitionMagic; what a great program.
PartitionMagic was a S-Tier windows utility. Thank you.
I don't remember this ever being the case, even in times of DOS.
One quick example, offers an installer or a ZIP archive, the "installation process" for the ZIP archive is basically "copy files out from archive && ./executable", installer does a bunch of other stuff: https://www.openttd.org/downloads/openttd-releases/latest
[0] https://stackoverflow.com/questions/8680132/creating-nice-dm...
Due to "new and better" approach, each program puts its data in 5 different folders for "multi user" reasons.
What is infuriating that all those folders are hidden and all of them are on C: drive. So your C: drive gets clogged.
This makes it impossible to track how much space each program uses.
(On a side note its been years since floppy drives were the A: drive... and yet we are still stuck with the primary disk being called C:)
The logic behind that is pretty obvious isn't it?
This one is entirely on Apple. It was Apple who decided that "root isn't good enough" and that you, the user, shouldn't be able to administer your own goddamn system as root, without performing backflips while singing Happy Birthday.
Even most power users leave it on except for temporary situations like this because it’s a helpful security protection.
If you think it’s bad, you don’t know why it was built - google Chesterton’s Fence. You, the user, still have 100% ability to modify your system however you choose - if you first clearly indicate that you ARE the user, and not just some random-ass installer running under admin privs, which is a completely normal and common occurrence. A higher privilege level that is used to protect OS integrity is a wonderful thing. If you think there is a better or safer way to access it, please submit your suggestions to Apple, but don’t assume the guardrails around System Integrity Protection (1TR etc) are slapdash or unreasonable or poorly thought out.
Why? Well, at the time Windows Explorer had an API for extensions, but MacOS didn't for Finder. We needed to add some menu items to the context menu, which on MacOS required reverse engineering Finder and injecting code into it. This then meant that Finder had an open file handle into our application bundle until you either restarted Finder or restarted MacOS. Then, as long as you didn't start our application, you could cleanly delete it. (Thankfully MacOS cleaned this up with the Finder extension API about a decade ago.)
Having gotten familiar with internals of both Windows and MacOS... MacOS has its own set of gremlins too.
When you realized that Mac OS X didn’t have an equivalent API, did you perhaps consider that it was for a good reason and that you should redesign your application to fit the conventions of the system? How did you conclude that your UI was oh so special that it deserved horking up the Finder experience for your users?
Or did/does the Finder check whether to-be-deleted files are open? Or did I forget how older Mac file systems behaved?
You can't really blame macOS for this one. Interesting to hear this isn't just a Windows thing though.
I often have apps on my Mac or iPhone that ask for permission to see my camera, microphone, contacts, etc etc that I don't want it to see. But I do want other apps to be able to access those things.
Being able to stop those apps from accessing before they do instead of trying to fix it after is incredibly valuable.
Sure some users just accept everything, but that is not an argument against them existing in the first place.
Even today, any rando application I download and run can read and/or write to any file on my system that I own and have permission to read and/or write, unless I go out of my way to run it in a chroot, a container, a jail or whatever. That's just poor security in a world where nearly every commercially developed application is an attacker.
If you install random apps and it destroys your PC, you can fix that by having backups. By contrast on work computers with important data, everything is supposed to be locked down and you can't install random apps. But then we started to increasingly connect devices to the internet.
Now gaining access over a smartphone essentially means being able to send payments via the banking apps. People are sending money with crypto so they are susceptible to simple clipboard swap attacks that are almost impossible for the user to detect until it happens. Then there is all the personal data that can be stolen that can be used for other attacks in the future.
Essentially the amount of damage you can take by losing access has increased much faster than the security devices meant to prevent.
To make matters worse, the security devices that are marketed to the average user tend to be exploitative rather than trustworthy (e.g. OneDrive).
It feels like instead of protecting users developers seem more interested in creating something that only does half of the job and then blaming the user for not knowing how to do the other half, so a comprehensive solution for the problem is never created.
1. Protect users from attackers external to the computer
2. Protect users from attackers who are other users on the computer
3. Protect users from applications run by other users on the computer
4. Protect users from applications they themselves run on the computer
5. Protect unprivileged (non-root) users from their own actions
6. Protect privileged (sudo/root) users from their own actions
OSes have been historically OK at 1-3. Not great or even good. There have been a lot of remote code vulnerabilities and local vulnerabilities over the years.
OSes have pretty much ignored 4 until maybe a decade ago, and are making token progress toward it, but I don't think many of them take it very seriously.
OSes have instead started to crack down on 5-6, which I'd argue isn't even the job of an OS.
Literally all security features carry the hazard of being used for oppression and being ineffective or counter-effective. That's how constraints work.
You need two things for a security feature:
- a segmentation under which a behavior is considered unsafe / unsecure (arbitrary, subjective)
- a technical solution that constrains the behavior of <thing> in <usage context> so that the aforementioned is mitigated
So something being "a tool of oppression" or "a tool of safety" is a matter of your alignment with that segmentation. And it being a theater or not is a matter of functional soundness given a threat model. So is its tendency to become counter-effective.
Constraints are just constraints. Whether they're effective and whether you're disadvantaged by them are both separate, independent matters. Empirical too.
Sandboxing apps by default is not that. The principle of least privilege is good security. If I vibecode some quick and dirty hobby app and share it with the world, it's better if the robot's mistake can't `rm -rf ~/` or give some creep access to your webcam.
The user should be able to override that in any way they see fit of course.
I can see the rest, but why did you mix in Wayland, a open source display protocol?
Anyway, I kinda like PearCleaner for removing the cruft. It’s not perfect but it’s open source and one of the better options imo.
Then I stayed in Hawaii for a while and my rental had a Samsung washer… it had a DOWNLOAD setting on the dial so I could hook up the app… for… washing clothes… it didn’t clean anything, it had a minutes long process of shaking my clothes about to get a feel for them before it bothered adding a lady’s thimble full of water… nope. I had never missed my speed queens so much.
Then I was at a big box store and their Samsung fridge with a tablet on the door locked up and hung.
That was three personal strikes.
It makes me wonder why did large companies are investing so much in web and putting web devs to write disk utility desktop apps?
It's because in these environments where corporate cancer has metastasised, programmers are not in charge of hiring programmers, or much of anything when it comes to decision-making really. HR is composed of people who are not programmers. They are looking to hire people with a list of shiny hot new web stack keywords on a resume, because they have literally no other concept of how to filter candidate applications. So they end up with a bunch of hot React devs and nobody capable of making software that is fit for task.
Also, let's say team A (10 C app/systems programmers) in a company asks HR to look for a C developer and HR comes back to them with 10 great web developers to be grilled by the engineers of team A - what happens then? Does team A shrug and say "welcome to our C codebase, we shall now rewrite it in tailwind or whatever because you are now here!" - I really don't see how it can play out
buttons being jpegs is the norm
I agree with all your points except this. Disk utilities have a long history of magic-themed names: PartitionMagic, Disk Wizard, Magic Partition Resizer, the list goes on. Samsung is doing whatever everybody else does and is naming their tools based on user expectations.
Not being able to simply remove a program like you would any other program is next level evil in my book.
You'd get Office 2003 and it'd follow the Windows XP style with lots of blue [1] and you'd get Office 2004 for Mac with the brushed metal styling [2] - and many applications only targeted a single platform.
Whereas in the modern age you get Slack for Web, Slack for Windows, Slack for Mac, Slack for Linux, Slack for iOS and Slack for Android - and it tries to be consistent across different platforms, instead of being consistent with different platforms.
[1] https://en.wikipedia.org/wiki/Microsoft_Office_2003 [2] https://en.wikipedia.org/wiki/Microsoft_Office_2004_for_Mac
It was at win8 where everyone just noped out and just started doing whatever they wanted. XP/2000 was the last era where anyone really cared.
Since then I've been using Corsair and WD Black drives, since Samsung has gotten overpriced and hasn't seemed as reliable the past few years. That application was one of the reasons.
> So I’ve dug around and found a cleanup script buried six folders deep inside the app bundle. Let’s try to run it:
> sh ~/Library/'Application Support'/Samsung/'Samsung Magician'/SamsungMagician.app/Contents/Resources/CleanupMagician_Admin_Mac.sh
> It ran. And my kitty exploded. Sweet kitty overflowed. Hundreds - literally hundreds - of lines of chown: Operation not permitted.
I mean, if you read on, you'll find that most of the things that were removed were from system folders that are owned by root? Presumably this was run without sudo…
> I rm -rf every Samsung folder I could find. The Preferences. The Caches. The LaunchAgents. The LaunchDaemons. The kernel extensions. The crash reports.
…that's where you put your stuff on macOS. Would you prefer that they picked some non-standard location you had to dig up?
> Package receipts in /private/var/db/receipts/ (Samsung left its receipts behind like a burglar leaving a bunch of turds in the living room)
This is again for your benefit so you know what was installed on your system
> Cached processes in /private/var/folders/7v/<your username hash>/C/ (yes, Samsung is in there too)
That's getconf DARWIN_USER_CACHE_DIR
> I shut down my Mac. Held the power button. Booted into Recovery Mode. Opened Terminal. Ran csrutil disable. Rebooted. Opened Terminal. Deleted the kernel extensions.
That's just how kernel extensions are on Apple silicon
* going into some internal directory and running a script based on the name
* deleting a bunch of directories
Seem like pretty bad ideas. Especially for software provided by a hardware vendor, which is probably a little clunky and inherently touches deep stuff.
But not including a removal script seems like bad form.
Edit: On the other hand, I don’t actually know for certain that the tool doesn’t have an uninstall script. Just, that the author didn’t find it. This seems worth noting because the author really wasn’t giving them the benefit of the doubt on anything, see all of the irrelevant complaints about animations.
I don't know man, the last time I uninstalled an app on macOS, all I had to do was drag it to the trash. If you find this procedure sane, then I don't know what to tell you.
Samsung is responsible of how users interact with their app, including its install and removal.
Clearing the package receipt database of stuff you want to uninstall is fucking neurotic, I'm sorry, but it just is.
I mean, if he had read the script before deleting it (that's the third time I've mentioned reading the script, do you think I'm dropping enough hints?), he might have found a handy list of ... ALL THE FILES HE WAS LOOKING FOR. You know, all the 18 or so locations that he had to find by hand.
But nope, he didn't ... yes, I'm going to say it for the fourth time ... READ THE SCRIPT.
Especially when the outrage is that the user didn't follow instructions to use sudo on an uninstaller that needs to touch root owned files.
> Localization files for every language on Earth
Yeah because English is the only one language that matters. Let's fuck up all the non-native speakers to save, I don't know, 50kb of text files? How could one frame this as a bad thing?
> Help documentation with 40+ screenshots in 10 languages
Seriously how Anglocentric could this author be? Even physical products have multi-language manuals nowadays.
I admit that I also often deviate from installation processes, but only when I really know why I want to do that. And I tend to read the instructions first.
But I know people who are snuggly proud about not reading the manual and I really don't get it.
Agreed... but there seem to be more and more products that either don't have manuals, or whose manuals are so badly written that reading them turns out to be a waste of time. I feel like people are being trained not to read manuals anymore, so I understand the people whose first instinct is "that thing is going to be useless, I'm not going to waste my time reading it". But not the ones who are proud of not reading manuals, that doesn't make sense to me either.
That is way to simplistic to be one size fits all.
A lit of practices save you 10s each day but when they fail you lose 10 years’ worth of savings.
It was funny and helpful.
This has been how it works in the Windows world for several decades. Surprising that Apple still hasn't figured this out yet.
On this point, Windows is no better than macOS: the OS relies on the goodwill of the developers to provide working uninstallers. The only protection is a world where the OS provider does the application packaging: Linux repositories, Mac App Store, Windows Store. And even then, apps are still free to litter your filesystem at runtime, unless they're heavily sandboxed. Then FlatPak it is, or iOS apps or Android apps. Not great.
The only remaining files were the "user space" like custom preferences or files created by the user using the program. The uninstaller rightfully leaves it up to the user to decide what to do with those.
First, the criticism of Electron is moot. Yes it's not sleek, but it's sufficient. This app is not supposed to be used heavily on a daily basis. Run it once to setup your drive, run it a few months later for a firmware upgrade or a quick health check and that's all. And when you had a taste of the absolute UX monsters some hardware vendors can produce on the software side, really an Electron app feels nice.
But it gets more ridiculous. Embedded fonts? God forbid companies enforce their own design guidelines in their software. Translations? Fuck non-English speakers. User guide with screenshots? The audacity.
Well that's a novel way to gatekeep.
Stick to the part about realizing it needed sudo, because the other complaint is just ridiculous.
Why are you considering localization as bloat? I bet your reaction wouldn't be positive if your native language(s) were missing instead.