xcodes: installing and switching Xcode versions from the terminal

The problem xcodes solves for Macs with more than one Xcode

Apple ships Xcode as a signed .xip archive and expects you to download it by hand, drag it into /Applications, and rename it if you keep an older copy around. The command line tool xcode-select only points at whichever copy you already have. That gap is where xcodes sits. It queries Apple's list of available releases, downloads the one you name, unarchives it, moves it to a versioned path such as /Applications/Xcode-11.2.0.app, verifies the code signature, and can then select it. The README describes the audience directly: teams that want a .xcode-version file checked into a repository so that a CI environment and every developer resolve the same Xcode. The commands split along that workflow: install, download, installed, list, select, uninstall, update, version, signout. If you run one Xcode and never change it, the tool has nothing to do for you.

How xcodes authenticates, downloads and finishes an install

The mechanism is a six-step install pipeline that the README shows as console output. xcodes authenticates against Apple with an Apple ID, then downloads the .xip, unarchives it, moves the app bundle into place, trashes the archive, checks the security assessment and code signing, and asks for superuser privileges to finish. Credentials come from a prompt, or from the XCODES_USERNAME and XCODES_PASSWORD environment variables. After a successful login the password is stored in the keychain and the username is remembered, so later runs skip the prompt unless you set XCODES_USERNAME to a different account.

Two details shape real usage. First, if aria2 is installed, the README states xcodes defaults to it for downloads and uses up to 16 connections, which it describes as 3 to 5 times faster than URLSession. Second, the install directory is configurable through --directory or XCODES_DIRECTORY, and the README notes that all commands honour it, including select and uninstall. The constraint that follows is explicit: xcodes supports having all of your Xcode versions in one directory, wherever that is. It is not a tool for versions scattered across several volumes. The list and runtimes commands also label downloads as [Universal], [Apple Silicon] or [Intel] when Apple provides that data, and --architecture filters are exact rather than inclusive, so arm64 and appleSilicon both mean Apple Silicon-only, while universal means a build that covers both.

Installing xcodes with Homebrew and installing a first Xcode

The preferred install is Homebrew, and the README notes that these builds are Developer ID-signed and notarized and do not require Xcode to already be present. That last point matters on a fresh Mac, where building from source is not an option because it needs Xcode 12.0 or later.

brew install xcodesorg/made/xcodes

Once the binary is on your PATH, list what Apple currently offers. The README shows architecture filters on this command, which is useful on Apple Silicon if you want to avoid an Intel-only build.

xcodes list --architecture arm64

Install a specific release by version string. The README uses these forms: a plain version, a beta with the word Beta, a GM seed, a local .xip via --path, or --latest and --latest-prerelease.

xcodes install 10.2.1
xcodes install --latest --directory "/Volumes/Bag Of Holding/"

Expect the six numbered progress lines, a macOS password prompt for the final step, and a closing line naming the installed path. To switch, run xcodes select against the version or path you want active. The README also recommends a .xcode-version file containing a bare version such as 13.4.1 so CI and teammates resolve the same Xcode.

Runtimes, experimental unxip and shell completion

Simulator runtimes are handled separately from Xcode itself. xcodes runtimes --include-betas lists what is available, and xcodes runtimes install "iOS 17.0-beta1" installs a named runtime. That split is worth knowing before you script anything, because a CI job that only installs Xcode will not have the runtime its tests need.

The --experimental-unxip flag replaces the default unarchiving step with work from saagarjha's unxip project. The README says it can be up to 70 percent faster on some systems, and the flag name itself signals the status: it is opt-in and not the default. Shell completion is generated by the binary rather than shipped as a file. For zsh with oh-my-zsh the README gives two commands.

mkdir ~/.oh-my-zsh/completions
xcodes --generate-completion-script > ~/.oh-my-zsh/completions/_xcodes

The README points at the swift-argument-parser documentation for other shells, since the installation steps differ per shell.

Where xcodes gets in the way

The Apple ID dependency is the sharpest edge. Downloads come from Apple's developer downloads, so an unauthenticated or rate-limited account blocks the whole pipeline. The README documents a signout command that clears the stored username and password, which implies the keychain state is something you may need to reset, but it does not document what happens when Apple rejects the credentials or when two-factor prompts arrive in an unattended job. The 2.1.0 release is titled "login fix", which suggests the authentication path has needed correction recently.

The install step also ends with a superuser prompt to finish installation. On a laptop that is a password entry; in a non-interactive CI runner it is a failure mode you have to plan around, and the README does not describe a flag that removes it. The source build path is closed to blank machines, since it requires Xcode 12.0 or later and the README warns that make install can fail with a swift build error about xcrun --sdk macosx --find xctest until you select a version of Xcode with xcode-select. And the one-directory rule is a real boundary: if your Xcode copies live in different places, xcodes is the wrong tool for managing them. Finally, the README does not document rollback or a way to undo a partial install, so a failed run leaves you inspecting /Applications yourself.

Compared with downloading Xcode by hand or scripting xcode-select

The obvious alternative is the manual route: sign in to Apple's developer downloads page, fetch the .xip, double-click to expand it, drag the app to /Applications, and rename it so multiple copies coexist. That approach needs no third-party binary and no stored credential, which some security-conscious teams prefer. The cost is that nothing records which version a project expects, and every machine drifts. A middle option is a shell script around xcode-select plus curl against Apple's download URLs, which keeps the dependency count at zero but forces you to maintain the URL list and the unarchiving logic yourself. xcodes differs by owning that list: the update command refreshes the available versions, the list command renders them with architecture labels, and the .xcode-version file turns the intended version into a committed artifact. If you want a graphical interface instead of a terminal, the README points to Xcodes.app in the same organisation, which is a separate project rather than a mode of this one.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-14, the same day as the 2.1.0 release. Earlier releases are 2.0.3 on 2026-07-08 and 2.0.2 on 2026-06-17, so the release cadence over that window is roughly monthly. The project is licensed MIT, which permits commercial and internal use and modification; the LICENSE file sits at the repository root, and as with any dependency you should read it rather than rely on a summary.

Upgrade cost is low on the Homebrew path, since brew upgrade replaces a signed binary and there is no runtime to restart. The hidden cost is the moving target underneath: Xcode releases, runtime versions and Apple's authentication behaviour change on Apple's schedule, not the project's. The 2.1.0 login fix is the concrete illustration. If you pin xcodes in CI, pin the version too, because a login change in a new release can break an unattended job. Building from source adds its own tax: the Makefile compiles with -Onone as a workaround for a Swift bug, so a source build is not the same artifact as the notarized release.

Editorial conclusion

Adopt xcodes if you keep more than one Xcode on a Mac or need a CI job to pin an exact Xcode version through a .xcode-version file, and install it with brew install xcodesorg/made/xcodes so you do not need an existing Xcode. Do not adopt it if you only ever run one Xcode, since the tool adds an Apple ID credential and a keychain entry to a job that xcode-select alone can handle. Before rolling it out, verify three things: that your Apple ID can authenticate through the tool, that your team agrees on the single directory named by XCODES_DIRECTORY, and that a fresh machine can be set up without a pre-existing Xcode, which rules out the make install path.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. XcodesOrg/xcodes on GitHub