Finder and the Applications folder: where apps really live

The Applications folder looks like the one place a Mac keeps its programs. Open it in Finder and there they are, in one list, alphabetically. That impression holds until something contradicts it: an app that is visible in Finder but missing from ls /Applications, an app that refuses to be dragged to the Trash, a downloaded tool that works fine from the Downloads folder, or a command line utility that never shows up anywhere. Each of those is the same underlying fact surfacing in a different way. Applications on a Mac live in several locations with different rules, and Finder shows a tidier picture than the disk does.

Two folders named Applications, and only one accepts writes

There are two directories with that name on a standard installation, and the difference between them is not organisational. It is enforced by the filesystem.

/System/Applications holds the apps that ship with macOS. /Applications holds everything installed afterwards. On a current Mac, the root filesystem mounts as an APFS volume marked sealed and read-only, which is Apple's Signed System Volume. Attempting to write into /System/Applications fails with Operation not permitted, and that failure comes from the volume itself rather than from a permissions setting that could be adjusted.

/Applications is not on that volume at all. The file /usr/share/firmlinks lists it as a firmlink, meaning the path appears under the read-only root but resolves onto the writable data volume. Directories reached this way include /Applications, /Library, and /Users. The seam is invisible in Finder and visible in one line of terminal output.

Location	Volume	Writable	Contents
/System/Applications	Sealed system volume	No	Apps bundled with macOS
/Applications	Data volume, via firmlink	Yes	Everything installed later
~/Applications	Home directory	Yes	Apps installed for one account only

The practical result: an app that will not move, will not rename, and will not delete is almost certainly in /System/Applications, and no amount of authenticating will change that. An app that behaves normally is in /Applications. The home directory version exists too, and some installers use it when they are told to install for the current user rather than for everyone.

Finder is an application that lives in neither folder

Finder does not appear in the Applications folder, and looking for it there is a common early dead end.

The bundle sits at /System/Library/CoreServices/Finder.app. CoreServices is where macOS keeps processes that are part of the running system rather than things a person launches deliberately. Finder is always running, restarts itself when killed, and owns the desktop and the menu bar. Treating it as an ordinary app that could be quit and reopened does not match how it works.

That placement explains a few behaviours that otherwise look arbitrary. Finder has no Quit item in its menu, only Relaunch when force quitting. Its preferences live in the Finder menu rather than in a separate settings app. It cannot be replaced in the way a browser or a mail client can, because too much of the system routes through it: the desktop, drag and drop targets, the file open panel adjacent behaviour, and connected volume mounting.

Anything described as a Finder replacement is therefore an addition rather than a substitute. The system browser keeps running underneath, and the second application takes over the work of browsing, comparing, and operating on files. That distinction matters when evaluating one, because the question is not whether it can replace Finder entirely. It is whether the tasks that currently require several windows can be done in one.

Safari is not stored where it appears to be

A single command shows how far the tidy picture is from the layout on disk.

ls -la /Applications | grep Safari

The result is a symbolic link pointing into ../System/Cryptexes/App/System/Applications/Safari.app. Safari ships inside a cryptex, a signed and separately mounted volume that Apple can update independently of the rest of macOS. The icon in the Applications folder is a pointer to that mounted image.

This is why Safari updates arrive on their own schedule, and why the app cannot be moved or deleted like a downloaded one. It also means that a script which copies the contents of /Applications to a backup drive will copy a broken link rather than the application, unless it is told to follow symbolic links.

The wider point is that the Applications folder is a presentation layer as much as a storage location. It contains real bundles, links into cryptexes, and stubs installed by package installers whose real payload lives elsewhere. Reading it as a literal inventory of what is installed produces wrong answers, and the way to get right ones is to look at the paths rather than the icons.

macOS 26 moved app browsing into Spotlight

For years, browsing installed apps meant Launchpad. On macOS Tahoe 26 that application is no longer present in CoreServices, and Apple's documentation now points somewhere else.

Spotlight is the central location where you can search, browse, and open your apps. Source: support.apple.com

Pressing Command-1 inside Spotlight opens the apps view. Categories along the top filter the list, the view can be switched between Grid and List, and iPhone apps can be included or hidden. Games downloaded from Apple Games appear under an Arcade category.

The rule for what shows up there is worth knowing, because it is the one place where the Applications folder is still authoritative.

Apps that you download from the App Store automatically appear in Spotlight. To add an app that you didn't download from the App Store, drag the app to the Applications folder in the Finder on your Mac. Source: support.apple.com

An app left in Downloads runs perfectly well. It simply does not get indexed into the app browser, which is why a tool that was installed last week cannot be found by name later. Moving the bundle into /Applications is the entire fix.

An application is a folder wearing one icon

A .app is a directory. Finder presents it as a single object because it is marked as a bundle, but the structure underneath is ordinary.

Control-clicking an app and choosing Show Package Contents opens it. Inside is a Contents directory holding Info.plist, a MacOS directory with the executable, Resources with icons and localisations, and often Frameworks with bundled libraries. In Terminal it needs no special treatment at all:

ls /Applications/Safari.app/Contents

Three consequences follow. Moving an app means moving the whole directory, so a partially completed copy produces a bundle that launches and then fails in odd ways. Backup tools that skip files by extension can mangle an app without reporting an error. And the localisations available for an app are visible directly in Contents/Resources, which is a faster answer than searching a vendor site.

The bundle format is also why apps do not scatter files across the disk the way installers on other platforms do. Most of what an app needs travels inside its own directory. The exceptions are preferences in ~/Library/Preferences, support files in ~/Library/Application Support, and caches, which is exactly the set that survives when an app is deleted.

Dragging to the Trash leaves the support files behind

Deleting an app is a two part operation, and Finder only performs the first part.

Moving the bundle to the Trash removes the executable and its resources. It does not remove preferences, application support directories, caches, saved application state, or login items. For an app that was tried once, the leftovers are a few kilobytes and irrelevant. For an app that indexed a large photo library or cached a mail archive, the leftovers can be gigabytes, and they are invisible in every disk usage view that only measures Applications.

The locations to check afterwards are ~/Library/Preferences, ~/Library/Application Support, ~/Library/Caches, and ~/Library/Containers for sandboxed apps. The Library folder in the home directory is hidden by default. Holding Option while opening the Go menu in Finder reveals it, and in Terminal it needs no revealing.

Apps distributed through the App Store are the exception in the other direction, because sandboxing keeps almost everything inside a single container directory named after the bundle identifier. Deleting that one directory removes the leftovers cleanly, which is a genuine advantage of the sandboxed distribution model and one of the few places where the App Store version of an application is easier to remove than the direct download.

Command line tools never arrive in Applications

A large amount of software on a working Mac is not an app at all, which is the last reason the Applications folder is a poor inventory.

Package managers install executables into directories on the shell path rather than into /Applications. Homebrew formulae land under /opt/homebrew on Apple silicon, while Homebrew casks, which wrap actual applications, do place bundles in /Applications and track them in a Caskroom directory. Language specific managers add their own trees. None of it appears in the app browser, and none of it appears in Finder unless the path is typed in.

Two commands settle most questions about where something ended up. Spotlight can be queried directly for every application bundle it knows about, including ones sitting in project folders and download directories:

mdfind "kMDItemContentType == 'com.apple.application-bundle'" | grep -v '^/System'

The output is usually larger than expected, because build outputs, helper apps nested inside other bundles, and old installers all match. That is the honest inventory. The second command is open -a followed by an app name, which reports Unable to find application named when the name does not resolve, and launches it when it does. Between the two, a question about whether something is installed can be answered without opening a window.

This split is the daily friction for anyone whose work spans both kinds of software. The graphical half is browsed in one window and the command line half in another, and the mapping between them is held in memory. Working in a window where the folder listing and the shell prompt share the same current directory removes that translation step, which is the argument for a file manager with a built-in terminal rather than two applications side by side. The comparison with other file managers sets out which tools include a terminal and which treat it as a paid addition.

For anyone working across languages, where an app stores its localisations and which ones it ships is a routine question, and the languages page covers how that is handled here.

Check the path before concluding anything

When an app behaves strangely, run ls -la on it before theorising. A symbolic link, a bundle in /System/Applications, and a bundle sitting in Downloads produce three different problems that look identical in Finder.

If a recently installed tool cannot be found in the app browser, move it into /Applications and it will be indexed. A window that shows the path and the shell together, so that check takes one glance, is what Atriens is built to provide, and the FAQ covers the system requirements.