In Homebrew on macOS, what is the difference between a formula and a cask, and where does each kind of package end up on disk?

## Two package types, one tool Homebrew is a third-party package manager for macOS. It is not part of the operating system and Apple ships nothing like it, which is why almost every macOS development machine has it. Homebrew manages two quite different kinds of thing, and interviewers ask about the distinction because confusing them is the first thing that trips a new macOS user. ## Formulae: software Homebrew can build A **formula** is a Ruby file that describes how to obtain and build a piece of software — its source URL, its checksum, its dependencies, and the build steps. Formulae are overwhelmingly open-source command-line software: `jq`, `wget`, `ripgrep`, `postgresql@16`, `[email protected]`. Installing a formula does not usually compile anything. Homebrew first looks for a **bottle**: a prebuilt binary tarball, built by Homebrew's own CI for a specific macOS version and CPU architecture and served from Homebrew's package registry. If a bottle exists for your platform it is downloaded and unpacked; if not, Homebrew falls back to building from source, which is when you discover you need Apple's Command Line Tools installed. The layout matters: ```bash brew --prefix # /opt/homebrew on Apple Silicon, /usr/local on Intel ls $(brew --prefix)/Cellar # one directory per installed formula ls -l $(brew --prefix)/bin/jq # a symlink into the Cellar ``` Each formula is unpacked into its own versioned directory — a *keg* — under `Cellar/<name>/<version>`, and then **linked**: Homebrew creates symlinks from the prefix's `bin`, `lib`, `include`, `share` and `share/man` into that keg. Because the prefix's `bin` is on your PATH, the command becomes available. This design is why uninstalling is clean (remove the keg, remove the symlinks) and why you can have several versions on disk while only one is linked. `brew link` and `brew unlink` flip that. Some formulae are **keg-only**: deliberately not symlinked into the prefix, because linking them would shadow a library or tool that macOS itself provides. Homebrew prints a caveat telling you the PATH or compiler-flag exports to use if you really want them, and other formulae that depend on them reference the keg path directly. ## Casks: software someone else built A **cask** describes an already-built macOS artifact: a `.app` bundle delivered in a `.dmg` or `.zip`, a `.pkg` installer, a font, a QuickLook plugin, a preference pane. Homebrew cannot build these — it downloads the vendor's file, checks it against the checksum in the cask definition, stages it under `Caskroom/<name>/<version>` in the prefix, and then moves or links the application into `/Applications`. ```bash brew install --cask firefox brew uninstall --cask firefox brew uninstall --cask --zap firefox # also remove leftover support files ``` Because the artifact is the vendor's binary, several things follow that surprise people: - **Many casks self-update.** A cask definition can declare that the app updates itself, and Homebrew then leaves it alone on `brew upgrade`; you need `brew upgrade --cask --greedy` to force those. So `brew outdated` is not a complete picture of what is stale on a Mac. - **Versions are the vendor's**, not Homebrew's. There is no build system to patch or pin against. - **`--zap` is not `uninstall`.** A plain uninstall removes the app; applications scatter preferences and support directories that only `--zap` cleans up. ## The name collision that catches people Some tokens exist as both a formula and a cask — `docker` is the classic example, where the formula is the command-line client and the cask is Docker Desktop, the full GUI application. Homebrew refuses to guess: `brew install --cask docker` and `brew install docker` do different things. `brew info <name>` tells you which type you are looking at, and `brew search` marks both lists. ## Why an interviewer cares The question is really "do you understand that Homebrew is doing two different jobs?" A candidate who thinks casks are just "formulae for GUI apps" will not understand why `brew upgrade` left an application three versions behind, why a cask cannot be built for a different architecture, or why `brew --prefix` is the right way to find a formula's files in a script while `/Applications` is where a cask's payload lives.