The official platform-tools ZIP from Google works fine on macOS, but it means manually managing PATH entries and remembering to redownload the archive every time a newer ADB version is needed. Homebrew handles both problems with one package and one update command, which is why most Mac-based Android developers end up using it instead of the manual download after the first time they need to update.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
On Apple Silicon Macs, Homebrew installs to /opt/homebrew rather than /usr/local, which matters for the PATH step below. The installer prints the exact lines needed to add Homebrew to the shell's PATH at the end of the run — do not skip that output, since forgetting this step is the most common reason a freshly installed brew command is not found in a new terminal window.
brew install --cask android-platform-tools
This installs adb, fastboot, and the other platform-tools binaries and symlinks them onto the PATH automatically, without needing to manually extract a ZIP or edit a shell profile.
adb version
fastboot --version
Both should print a version number and revision hash. If command not found appears instead, the terminal session was opened before Homebrew's PATH lines were added to the shell profile; open a new terminal window (or run source ~/.zshrc) rather than assuming the installation itself failed.
brew upgrade android-platform-tools
Running this periodically matters more than it might seem: a phone running a very new Android version occasionally requires a newer ADB or Fastboot binary to recognize new protocol features, and the symptom of an outdated local ADB is often a confusing, generic error rather than an obvious "please update" message.
Rarely, macOS's Gatekeeper flags the downloaded adb or fastboot binary as being from an unidentified developer on first run, especially right after a fresh install or a macOS version upgrade. If a security dialog blocks execution:
This is a one-time confirmation per binary version; it does not need to be repeated after each Homebrew upgrade unless the binary itself changes significantly between releases.
Connecting an Android phone for the first time on a recent macOS version may trigger a system prompt asking whether the connected accessory can be used by apps on the Mac, separate from the phone's own ADB authorization dialog. Both prompts need to be accepted — approving only the phone's ADB dialog while dismissing macOS's own accessory permission prompt still results in adb devices returning an empty list.
On a locked-down managed Mac where installing Homebrew is restricted by device policy, the manual platform-tools ZIP from the Android developer site still works identically; just extract it and add the folder to the PATH manually in ~/.zshrc:
export PATH="$HOME/platform-tools:$PATH"
The functional behavior of adb and fastboot themselves is identical either way; Homebrew only changes how the binaries are installed and updated, not how they behave once running.
The android-platform-tools Homebrew cask ships native ARM64 binaries for Apple Silicon, so Rosetta is not required to run adb or fastboot on an M-series Mac. This was not always true in the early Apple Silicon transition period, when some Android tooling still shipped Intel-only binaries requiring Rosetta as a compatibility layer; current versions distributed through Homebrew do not have that limitation.
Installing Android Studio separately already places its own copy of platform-tools under ~/Library/Android/sdk/platform-tools. If both that path and Homebrew's symlinked binary are on the PATH at the same time, whichever comes first in the PATH order is the one that actually runs, and the two can silently drift to different versions over time. Checking which adb after installing both is worth doing once, just to confirm which copy any given terminal session is actually using before assuming an update via one method took effect everywhere.