A step-by-step guide to installing multiple Xcode versions and switching the active one using the Xcodes command-line tool and companion app.
By the end of this guide you will have Xcodes installed, one or more Xcode versions downloaded, and a clear way to switch which version is active.
This is the single most common reason developers reach for Xcodes. Managing more than one Xcode by hand is slow, so automating it pays off immediately.
Everything here uses widely documented commands. Where exact syntax matters, always confirm against the official Xcodes documentation, since flags can evolve between releases.
Remember the boundary: this workflow gets Xcode onto your machine and selects it. Actually building and signing your app is still done inside Xcode afterward.
You need a Mac running macOS, because Xcode itself only runs on macOS. No version manager changes that requirement.
You need an Apple account to download Xcode from Apple's servers. Many downloads require an Apple Developer account, and if the account uses two-factor authentication you will complete that during sign-in.
You also need free disk space. Each Xcode install is several gigabytes, and keeping multiple versions multiplies that, so check your available storage before installing several releases.
Finally, a stable internet connection helps. Xcode archives are large, and the initial download is the slowest part of the process.
It also helps to decide in advance which exact versions you actually need. Installing every release you can is tempting, but each one consumes several gigabytes you will eventually want back.
If you already know the version your project targets, note the precise version string now. Having it ready makes the install step a single, unambiguous command.
You can install the Xcodes command-line tool through a package manager such as Homebrew, or download the companion macOS app from the official site.
Many developers prefer Homebrew for the CLI because it fits cleanly into scripts and CI. The companion app is a better fit if you want a visual list with install controls.
Both forms do the same core job. Choose based on whether you value automation or a graphical interface.
After installation, confirm the tool is available by checking its version or help output, which also verifies your shell can find it on the PATH.
If the command is not found, the usual cause is that your shell has not picked up the directory the package manager installed into. Opening a fresh terminal session or reloading your shell profile normally resolves it.
Before installing, list what is available. The CLI provides a command to show released versions, including betas and release candidates.
This matters because you want to install a specific, known version rather than guessing. Pinning an exact version keeps your team and CI consistent.
In the companion app, the same information appears as a scrollable list of versions with their status.
Take note of the exact version string you want. You will pass it to the install step, and precision avoids accidentally grabbing a different release.
Run the install command with the version you chose. Xcodes will prompt you to authenticate with your Apple account so it can download from Apple's servers.
If your account uses two-factor authentication, you will be asked for the verification code. This is expected, since Apple protects Xcode downloads behind authentication.
Xcodes then downloads the archive, unpacks it, and places the resulting `Xcode.app` where the tool manages it. This is the step that takes the longest because of the download size.
Once complete, the version is installed and ready to be selected. You can repeat this step for each additional version you need side by side.
Having multiple versions installed is only useful if you can choose which one your command-line builds and tools use. Xcodes provides a way to select the active version.
Under the hood this is the same idea as Apple's `xcode-select`, which points the developer directory at a specific Xcode. Xcodes wraps that so you can switch by version rather than by path.
After switching, verify the active version. You can check with `xcode-select -p` to see the selected developer directory, or by asking the toolchain for its version.
Do this whenever you move between projects that require different Xcode versions. A quick check prevents the classic mistake of building against the wrong toolchain.
Because changing the system-wide selection can require elevated permissions, a switch that appears to do nothing is often a silent permission issue rather than a bug. Re-running with the right privileges usually fixes it.
After switching, open the intended project and confirm it builds with the version you expect. A mismatched toolchain often shows up as unexpected compiler or SDK errors.
Over time, old Xcode versions accumulate and consume disk space. Periodically remove versions you no longer need to reclaim storage.
Keep at least your current production version and any beta you are actively testing. That balance covers most day-to-day work without hoarding installs.
Document which version your project requires, ideally in your repository. That makes it trivial for teammates and CI to install and select the same one.
Before deleting any version, make sure it is not the one currently selected. Removing the active Xcode leaves the developer directory pointing at a path that no longer exists, which produces confusing errors until you reselect a valid version.
Once you have done this once, it helps to turn it into a routine you can repeat without thinking. List, install, select, verify: those four steps cover almost every situation.
When a new project asks for a different version, list what you have or can install, install it if it is missing, select it, and verify with `xcode-select -p` before you build.
Keeping the routine identical every time is what prevents mistakes. The failure cases with Xcode versions almost always come from skipping the verify step and assuming the switch took effect.
If you work on a team, write this routine down alongside your project's required version. A shared, boring checklist beats everyone improvising their own toolchain setup.
This workflow manages Xcode; it does not build or ship apps for you. Compiling, code signing, archiving, and uploading to App Store Connect all still happen in Xcode with a valid Apple Developer setup.
Xcodes cannot make downloads faster or smaller. The size of Xcode archives is set by Apple, so first installs will always take real time and bandwidth.
It also cannot bypass Apple authentication. You need a valid Apple account, and often an Apple Developer Program membership, to download Xcode at all.
And it is macOS-only, because Xcode is macOS-only. If you are tempted to avoid Xcode with a web wrapper, be aware that wrapping a website as an app risks App Store rejection, and a real App Store release requires Xcode plus Apple Developer Program membership.
List available versions first, then run the install command with the exact version string you want. Xcodes prompts you to sign in with your Apple account, downloads the archive from Apple's servers, and unpacks it. Always confirm the current command syntax in the official Xcodes documentation.
Xcodes selects which installed Xcode is active, which is the same concept as Apple's xcode-select pointing the developer directory at a specific Xcode. After switching you can verify with xcode-select -p.
Yes, that is the main point of Xcodes. You can install several versions side by side and switch between them, which is common when you run a stable version for production and a beta for testing.
Indirectly. The selected Xcode determines which SDK and compiler your command-line builds use, and App Store submissions have minimum Xcode and SDK requirements over time. The actual build and submission still happen through Xcode and Apple's toolchain.