Anaconda publishes four macOS installers for Miniconda, two architectures (arm64 and x86_64) times two formats (a graphical .pkg and a command-line .sh script), and only one of the four is right for the Mac in front of you. My advice up front: it's the .sh matching your chip. What follows covers picking it, running it, wiring conda into zsh and the Homebrew alternative, which comes with one real gotcha.
arm64 or x86_64: Check your chip first
Every Apple Silicon Mac, M1 through the current generation, takes the arm64 installer, and Intel Macs take x86_64. When you're not sure what's in the machine:
uname -m
Whatever it prints is the word that belongs in your installer filename. The x86_64 build will technically run on Apple Silicon through Rosetta 2, and this sounds harmless right up until every numpy operation is paying an emulation tax and some compiled packages won't load at all. It's the classic outcome of copying an install command from a pre-2021 blog post.
Skip the .pkg, use the .sh installer
The .pkg gives you a familiar double-click wizard, and I don't recommend it anyway, for two reasons. The first is reliability: community threads (r/learnpython has a well-worn one from the Ventura era) report the PKG dying with "This package is incompatible with this version of macOS. The package is trying to install content to the system volume" on Macs where the .sh script proceeds without complaint. The second is control, since the .pkg offers no batch flags and no scripting. The shell installer is also character-for-character what you'd run on a Linux server, so whatever you learn here transfers.
Install Miniconda with the shell installer
Download the build for your architecture (swap in x86_64 on Intel):
curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-MacOSX-arm64.sh
Check it against the SHA256 hash published beside the file on the Miniconda repo index:
shasum -a 256 Miniconda3-latest-MacOSX-arm64.sh
Then run it:
bash Miniconda3-latest-MacOSX-arm64.sh
The license shows up inside a pager: Enter opens it, q closes it, and typing yes accepts. Take the default install location of ~/miniconda3, and when the installer asks about running conda init, say yes, since that's the step that teaches your shell where conda lives.
Set up conda in zsh
macOS has defaulted to zsh since Catalina, so the installer's conda init writes its block into ~/.zshrc. Reload it:
source ~/.zshrc
Your prompt gains a (base) prefix and conda --version answers. If you declined the init question earlier, it can be run at any point:
~/miniconda3/bin/conda init zsh
The command takes any shell you name, so long-time Mac users who carried bash across upgrades run conda init bash instead. A terminal that still says "conda: command not found" after all of this usually means the init block landed in the wrong profile file; fixing that is one of the walkthroughs in the Miniconda troubleshooting guide.
Installing Miniconda with Homebrew
On a Mac that's brew-managed end to end there's a cask, and the miniconda cask currently tracks py314_26.5.3-2, the same release as the official installers:
brew install --cask miniconda
Two things before choosing this route. The cask prints a caveat after install that people routinely skip: your shell still needs initializing by hand, with
conda init "$(basename "${SHELL}")"
which on a stock Mac resolves to conda init zsh, and skipping it means new terminals never learn conda exists. And the miniconda cask conflicts with the miniforge cask, so brew won't hold both. That second point deserves more thought than it usually gets, because Miniforge is the community installer preconfigured for conda-forge, the licensing difference between the two is real, and the Miniconda vs Miniforge comparison is worth reading before you commit either way.
Between brew and the official installer, the official .sh wins for anything serious. You pick the exact version, verify the hash yourself and the install lands predictably in ~/miniconda3, where the cask puts it under Homebrew's Caskroom directory instead (brew info --cask miniconda shows the path on your machine). You also end up with two package managers holding opinions about one tool, because conda updates itself independently of whatever version brew's cask has pinned. The drift is mostly cosmetic, but "mostly" is doing some work in that sentence when a colleague asks why brew list and conda --version disagree.
Where Miniconda is installed on a Mac
With the official installer, everything, conda itself, base and every environment you create, sits under ~/miniconda3 unless you chose another prefix. Nothing touches the system Python that macOS guards, nothing sprawls into /usr/local, and removal later is essentially one directory plus the shell init block, the short procedure in the uninstall Miniconda guide.
Verify the install did what it claims:
conda --version
conda create -n test python=3.12 -y
conda activate test
On Apple Silicon, packages inside that environment resolve to native osx-arm64 builds, visible in the platform line of conda info. Current installers support macOS 12.1 and newer, per the official install documentation, and earlier releases stay downloadable from the archive section of the repo index for anyone nursing an older machine. From here the daily work is creating and managing conda environments, identical on a Mac to everywhere else.

