Live data from Hacker News

Making macOS Apps Uninstallable

notes.alinpanaitiu.com

131–140 of 208 posts

Re: Making macOS Apps Uninstallable

#131
post #4

Earlier quoted context omitted.

Nope, still leaves them behind. 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.

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.

Re: Making macOS Apps Uninstallable

#132
post #125

Somehow I misread the title as making apps impossible to remove, glad to see it was the opposite. It's the second time I read about Lunar, and my curiosity led me to their impressive monitor database: https://db.lunar.fyi/

Feel free to smoke sir, the Hindenburg is completely inflammable.

In French, "inflammable" means "that can catch fire" (flammable in English), which leads to the monstrous opposite: ininflammable.

Re: Making macOS Apps Uninstallable

#133

This actually points to an underlying weakness of the Unix/macOS permissions system: There is no concept of apps. By now the filesystem permissions hierarchy really should be extended into Group → User → App. You can see the half-baked workarounds many operating systems use like controlling access to entire folders like Documents, Downloads, Photos etc. Why not just make it fine-grained and let us permit and deny app…

Sounds similar to Fuchsia and how it’s filesystem access is based on capabilities, unforgeable tokens assigned to each process

Re: Making macOS Apps Uninstallable

#135

I was disappointed by not finding a tutorial on how to create an app that no user could ever install successfully.

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

Re: Making macOS Apps Uninstallable

#136
post #33

Earlier quoted context omitted.

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 wh…

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? That's what the average end-user understands by removing an app from the system nowadays.

iOS apps usually store all user data in the cloud, so you can delete their data without much risk.

Re: Making macOS Apps Uninstallable

#137

Earlier quoted context omitted.

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 dev…

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 ancill…

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.

Re: Making macOS Apps Uninstallable

#138
post #121

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 reaso…

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.
Post reply on HN