Unfortunately many (most?) application developers don't know this either, and many of them go so far as to explicitly require their apps to be installed in /Applications, they simply won't work otherwise.

No comment on the overall topic, but I have long made a practice of installing into $HOME/Applications instead[1], and it's rare for me to encounter software that cares. A few apps have added popups to explain to beginners "Hey, you're running me from the Downloads folder, uhh, want me to properly move myself to /Applications/?" but that's about it.

The only apps I run from /Applications that aren't part of the OS are the ones that still use "Installers" like Adobe apps, because I assume they spew crap all over anyway. I haven't tried moving those, but I wouldn't be surprised if they deeply cared.

[1] The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.

> The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.

Unrelated, but this is what I find so interesting and cool about the drag-and-drop to install method prevalent on macOS. People complain, but what I guess they don't realize is that all they're doing is moving a folder into their `Applications` folder and that the "wizard" way they're used to is far messier.

Granted, since I think it's up to the developers, they often seem to make the user drag and drop into the root `Applications` folder.

That’s fine, but also just means the “real” installer just runs on first launch instead in those cases, whether that is to ask for permissions or setup launch scripts or copy files to more places

But just think about how much fun phone apps could have been if you first installed an installer and than than that downloaded an app to install the side components before launching a configuration program for installing that specific software suite

Just so you know, there is something about dragging that app bundle to /Applications that causes something to happen. Because if you `mv` it in the terminal, the app often doesn't work.

It's been a while since I did this, and I can't remember the details. Sorry. Someone else might.

There is a bit of magic going on in Finder with /Applications. It’s actually two folders, one in the system partition which you can’t write into and one in the data partition where anything you install goes.

There are three of them, two you've mentioned, and ~/Applications for each graphical user too.

Sadly though macOS never has and still doesn't do any magic for ~/Applications, such as showing your apps mixed in with the rest just by looking at "Applications." But yes, it does mix in the locked system apps such as Settings and Photos with the ones you have dropped into /Applications as though they're all in /Applications as they once were. I usually just add both folders to the sidebar, and forget which is which daily.

The problem with the macOS "just drag it to Applications" approach is the uninstall. Deleting the folder will not delete user data (what if it's damaged?), and it won't delete any system stuff the app created on the first run. A typical Windows installer is likely to do the former and will definitely do the latter.

I do agree that uninstallation can be hard on macOS. I think Apple just envisions a future where every app is self-contained and putting the app in the trash really does remove everything because it was all in there.

Maybe that's not realistic, though.

I still think there's something to be said about an installation/uninstallation process that relies purely on moving files around, no custom script execution.

The "drag it to Applications, move to Trash to remove" flow was invented decades ago, possibly even back in NeXTStep [0]. Application bundles are not meant to be writeable, user data cannot be written there. If Apple envisions a future change, they’re really terrible in implementing it.

[0] https://www.nextcomputers.org/files/manuals/nd/Concepts/Inst...

I suspect Apple has little incentive to fix it since if an app stores a bunch of data in ~/Library/Application Support and then you Trash the app, then your 256GB SSD (still standard even on a 'professional' laptop, in 2025) is that much more filled, eventually prompting you to curse yourself for not spending $400 in nearly-pure-profit to upgrade that to 1TB.

Now imagine that home directory was on your iPhone and you could plug it in to any Mac anywhere you went!

Now, that’s heresy! :D

(Although you could get closer to that with an iPod back in the day! Lots of my fellow Apple Store employees kept a lot of apps and things on their iPods!)

Or on your iPod. https://forums.appleinsider.com/discussion/36380/home-direct...

All my Adobe apps are fine running from /Applications/gfx; I've never tried putting them into ~/Applications. They do also dump a bunch of stuff elsewhere.

Apple themselves have a quirk in some cases where apps that aren’t in an Applications folder get mounted as read-only.

Granted I haven’t seen the bug in awhile, but I also never saw acknowledgement of it being fixed so…

That's not a bug, it's a security feature (hack?) called translocation. It happens if you run an app that was downloaded without moving it first using the Finder.

I know what the feature is called.

I would not consider something so confusing to the end user to be a security feature. This is a bug, or you could use the label "broken".

Fascinating! Personally, I need an admin account in my daily work, so I wouldn't do this, but for those it could help it definitely looks interesting.

You can still choose to install apps to ~/Applications if you are an admin.

I'll definitely start considering it.

I don't even have a ~/Applications on macOS 15.4.1.

You need to manually create it.

In the Finder it is translated to your system language. For example, „Programme“ in German. It is still Applications in the terminal.

If you install an app in ~/Applications, it can auto update without root, but any sus code can overwrite it without root rights too

Which is madly insecure, right?

I think so, somebody correct me if I'm wrong. Maybe if SIP is on and untrusted software is disabled then it would be caught, but if you have xcode then sus code can also probably sign whatever it created.

/Applications seems defense in depth for developer machines that often run untrusted code. Apps ask for admin to update & then I can deny it and go check the official site and stuff for download later

Nope, that was fixed several releases back. macOS doesn't use the concept of a root user for years. It's there in the APIs for backwards compatibility but the actual enforced permission model is nothing like UNIX.

1. Apps can't tamper with each others files. Try writing an app that writes to another app's bundle, even if it's in $HOME, and you'll find you can't. One way to test this quickly is to ensure that your terminal app doesn't have "Manage applications" privilege in the settings app, restart it, then use vim to open a file in a bundle that appears to have user write permissions. You'll find it is read only.

2. root can't make arbitrary changes to the system unless you disable SIP (requires messing around in recovery mode terminals).

I think you are wrong about Unix model only existing for compatibility

1. OK, so it requires terminal to have some entitlement first I guess. If you needed to grep some app's bundle in the past you probably gave it already.

2. many apps ask for admin user/password when updating. including say Docker. some developer software specifically says "we ask you this because we need to sudo"

stuff under SIP I think includes some stock apps, some top level /bin and the like, but everything else is fair game for root. Which is a lot. If you use MacPorts then all of that is under sudo

Grepping is always allowed because it's read only.

Yes some dev tools like Docker ask for admin passwords, but that's not typical of most Mac users experience.

Root still exists, but outside of software originally built for Linux or some odd edge cases, you won't encounter it.

> Grepping is always allowed because it's read only.

This is false on multiple levels. For a fact it is absolutely NOT "always allowed". If you ever ran a find or ls that goes into dirs like Downloads or Documents for the first time you would know you always get a prompt. But once it IS allowed, you can write there.

You're right that there is protection and verification of some signed app bundles, and I was wrong to say you can easily edit apps. For most apps even if you can edit them macos should raise a stink and say the app is damaged IF SIP is enabled and macos checks the signatures.

But I don't know if it works if the app is modified before first launch and launched without Internet because this is verified through Apple notary servers. Also I wrote files and modify plist in some signed Tauri/Deno app and spctl did show a warning but macos didn't care and launched it without any alerts.

And anyway if you have xcode set up some sus code can also sign whatever they write and good luck then;)

TL;DR as I wrote in another comment using ~/Applications is not totally insecure with SIP and all but still less secure.

This comment was edited, my original comment was too dismissive and wrong.

It's not (entirely) signature based. Try editing Chrome's Info.plist. If you can do it your terminal or editor probably has app management or full disk access permissions. Note that signatures are only checked on native code binaries every time. For data files and bundle structure, it's only checked once the first time the app is run. The signature is checked even without internet access, and normally notarization can be checked too via stapling.

> Try editing Chrome's Info.plist. If you can do it your terminal or editor probably has app management or full disk access permissions

I can edit plists for a bunch of signed and popular apps but MOST of them would be "damaged" on next launch. However a Tauri template app was launched.

and malware doesn't need to modify apps. Just rm an app and put a modified version instead. You can do this in ~/Applications without sudo or app management permissions

> as every single app installer suggests

Not every single app installer, only those app installers written by incompetent devs.

Those written by educated devlopers give you the option to install "for all users" or "just me" (or words to that effect).

Oh interesting, thank you! I wonder doing this will fix the issue where slack repeatedly asks admin password for updating.

I knew that ~/Applications exists, but never really used it until I started at my new job where I didn’t have admin permissions by default. Now I’ve configured Homebrew to install casks into ~/Applications and it works for almost all applications.