MOVE files in /Applications?

The only workaround is to disable the SIP, move your files, then restore the SIP.

Turning Off Rootless System Integrity Protection in OS X El Capitan 10.11.x or Later

Again, the vast majority of Mac users should not disable rootless. Disabling rootless is aimed exclusively at advanced Mac users. Do so at your own risk, this is not specifically recommended.

1. Reboot the Mac and hold down Command + R keys after the startup chime, this will boot OS X into Recovery HD.
2. When the Utility Menu appears, select the Terminal from the Utilities menu in the menubar.
3. Paste the following command into the terminal then hit return: csrutil disable; reboot
4. You’ll see a message saying that System Integrity Protection has been disabled, and the Mac needs to restart for changes to take effect. The Mac will then reboot itself automatically.

You can also issue the command by itself without the automatic reboot like so: csrutil disable

Once the Mac boots up again, System Integrity Protection will be disabled entirely in OS X.

Checking the Status of Rootless / System Integrity Protection in OS X

If you want to know the status of rootless before rebooting or without rebooting the Mac from the Recovery HD, just paste the following command into the Terminal: csrutil status

You’ll either see one of two messages:

$ csrutil status

$ System Integrity Protection status: enabled

or

$ csrutil status

$ System Integrity Protection status: disabled

If at any time you want to change the status of rootless, another reboot from the Recovery HD is required.

How to Re-Enable Rootless System Integrity Protection in OS X

Simply reboot the Mac again from the Recovery HD as directed above, but at the command line use the following syntax instead: csrutil enable

Just as before, a reboot of the Mac is required for changes to take effect.

Well I think it has to do with the chflags 'restricted', the chmod ACL that says no one can delete the file, and most likely the xattr com.apple.rootless

If you get them out of the way using the above commands in Bold maybe you can do what you want. A bad idea, but I'm not against people learning (suggest keeping regular backups).

/bin/ls -leO@ /Applications

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 App Store.app

com.apple.rootless 0

0: group:everyone deny delete

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 Automator.app

com.apple.rootless 0

0: group:everyone deny delete

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 Books.app

com.apple.rootless 0

0: group:everyone deny delete

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 Calculator.app

com.apple.rootless 0

0: group:everyone deny delete

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 Calendar.app

com.apple.rootless 0

0: group:everyone deny delete

drwxr-xr-x@ 3 root wheel restricted 96 Apr 27 11:53 Chess.app

com.apple.rootless 0

0: group:everyone deny delete

... <see Additional Text box>...

Too many people moved apps out of Applications and then things started to break.

Moving System Preferences causes a lot of apps to fail because they cannot find System Preferences.

Or an operating system update/upgrade puts a new copy of the app in Applications, but the user has an old, now Out-of-Date app somewhere else, and when they launch the Out-of-Date app either does not work anymore or it does not contain the new and improved feature that has been all over the news, and the user writes a blog post ranting about how they dislike the product.

They move something macOS needs to do the update/upgrade, and then it fails, leaving the user with a broken system.

So basically, you can add and remove your 3rd party apps, but Apple apps are locked down by System Integrity Protection.

In the past I have helped a user that dragged lots of files out of /Applications to their desktop, and assumed it would create a shortcut like Windows.

Their system tanked. Nothing worked.

I had to talk them though the process of getting the apps back into /Applications. It has been awhile, but I think it was done in Single User Mode with mv commands.

I have seen users move System Preferences and things break. I ended up diagnosing the problem.

I have seen users remove a an app, have an updated app put in /Applications, but because they had the app on the desktop and double clicked the old app on the desktop, they did not get the functionality advertised in the new Mac OS X release (it was awhile ago). I had to figure that one out for an irate user that insisted the new app was broken.

There are real events I have seen and helped people understand what went wrong.

I'm sure Apple Support has received lots of calls with users whining that their system is broke because they moved things around inside /Applications. Either moved apps out, or created their own subfolders and moved apps into the subfolders, etc...

Feel free to educate all the developers that they cannot go looking for an app in /Applications or /Applications/Utilities and must use other means of searching. Herding "Cats" is always fun 😀

And all installers to not assume an app should reside in /Applications, but rather search the entire disk to find where it might live (or if there are multiple copies where they live) and update the app where it is, as apposed to installing a new copy in /Applications. I'll use the "Pushing a String" analogy this time 🙃

I've been a software developer for 47 years, working on platforms that boot by toggling in the boot code on the front console switches, to booting from 80 column punched cards and punched paper tape, to booting from magtape, floppy disks, hard disks, and SSDs.

I have yet to see universal consistency between developers. Not even when they are in the same group, let along different companies.

My advice. If the app installs itself in /Applications or /Applications/Utilities or even ~/Applications, let it alone and create your own folder of aliases if you just want a frequently used subset. If the application comes in a .dmg or .zip file, you can put it anywhere you like, just try to be consistent so you do not end up with a dozen copies over the years.

You may not like my advice, but your system will have fewer problems over the years if you follow it.

I've lost nothing. I don't work for Apple. I'm just a user like you.

Did you try the chflags command, the chmod command and the xattr command to remove those attributes? Once you figure it out chances are you can script it and move things to your hearts content.

And I thought it was a bad idea, but you are not doing anything "Bad" as in "Breaking Bad" or illegal.

I'm not even sure why it bothers you so much. I rarely go wondering through those directories. If I use an app enough it is on my Dock. Or I use Command-Space and let Spotlight find and launch it for me. Or I create a folder, put frequently used app Aliases in the folder, then drag the folder to the Dock for each access. Or put an Alias on the Desktop.

If your workflow has you looking in Applications, then create your own Applications, and populate and arrange it with Aliases as you desire so your workflow is how you like it. What is so special about Apple's Applications folder that you must change it.

As far as I know, then apps that are restricted in Applications are the one that came with macOS. The others are after market installs, either from the App Store or a 3rd party installer, or drag and drop from a .dmg or .zip file. They are unlikely to have restricted flags, as they are not always expected to be there.

Oh yea. Good news. Applications - Utilities -> Boot Camp Assistant will allow you to install Windows on your Mac, so you can at least get some value from your existing hardware before you get a Dell, HP, ASUS, Lenovo, etc... And I'm not trying to be funny. If you want to switch to Windows, but do not want to buy new hardware just yet, you can continue to use your Mac hardware.

Or there are Linux installs for Mac hardware, is you want to go that route. Linux lets you do just about anything your heart desires and has more customization than you can shake a stick at.