Run Two Xcode Versions Side by Side Remotely

Keeping two Xcode versions on one remote Mac is a three-step job: download the older .xip from the Apple Developer site, rename each app bundle in /Applications so neither overwrites the other, and use xcode-select -s to switch the active toolchain. The practical payoff is a short diff script that surfaces exactly which deprecations a newer SDK introduces without disturbing the working build. Confirm the macOS minimum for each release in the Apple Xcode release notes index; Xcode 26 ships with Intel support, while Xcode 27 is Apple-silicon-only per Apple's porting-to-Apple-silicon guide.

Why Coexist Rather Than Overwrite

Three concrete scenarios justify two installed Xcode versions on the same host:

Beta regression testing. A newer Xcode may emit stricter Swift concurrency diagnostics or new deprecation warnings. Building against both before the newer release becomes mandatory shows regressions on your schedule, not Apple's.

SDK targeting. Your app supports older iOS releases but CI has moved on. Running the same scheme against both toolchains catches API calls the older SDK flags and the newer one silences (or vice versa).

Team reference environment. When one developer is on a 26.x point release that raised its macOS floor and another is still on the previous point release, a hosted Mac that satisfies the stricter floor and carries both Xcode versions gives the team a neutral build target. Check each release's own minimum row on the release notes index before you pick the host OS.

Downloading Older Xcode Versions

The downloads page at developer.apple.com/download/all requires an Apple ID enrolled in the Apple Developer Program. Search "Xcode", grab the .xip for the version you want, and move it onto the remote Mac through your usual file transfer path (the browser session on the Figment VM works; scp works where SSH is configured on physical plans).

Expand the archive and rename it immediately so the next install does not clobber it:

cd /Applications
xip --expand Xcode_26.3.xip        # produces Xcode.app
mv /Applications/Xcode.app /Applications/Xcode26.3.app

Repeat for the second version. A healthy layout looks like:

/Applications/Xcode26.3.app
/Applications/Xcode26.6.app

Switching the Active Toolchain

xcode-select -s sets the Developer Tools path that xcodebuild, swift, and xcrun read:

sudo xcode-select -s /Applications/Xcode26.3.app/Contents/Developer
xcodebuild -version

sudo xcode-select -s /Applications/Xcode26.6.app/Contents/Developer
xcodebuild -version

For a single command, DEVELOPER_DIR overrides the global setting without a sudo call:

DEVELOPER_DIR=/Applications/Xcode26.3.app/Contents/Developer xcodebuild -version

Use DEVELOPER_DIR in the diff script below so the two invocations do not race against each other through the global xcode-select state.

The Warning-Diff Script

This example (not a benchmark) builds your project twice and diffs the warning lines. Pass your own workspace and scheme; the script will not guess them.

#!/usr/bin/env bash
# Usage: ./diff_warnings.sh MyApp.xcworkspace MyScheme
set -euo pipefail

WORKSPACE="$1"
SCHEME="$2"
DESTINATION='platform=iOS Simulator,name=iPhone 16,OS=latest'

XCODE_OLD=/Applications/Xcode26.3.app/Contents/Developer
XCODE_NEW=/Applications/Xcode26.6.app/Contents/Developer

WORK=$(mktemp -d)
trap 'rm -rf "$WORK"' EXIT

run_build() {
  local xcode_path="$1" out_file="$2"
  local raw_log="$WORK/build_$(basename "$out_file").log"
  echo "==> Building with $xcode_path"
  DEVELOPER_DIR="$xcode_path" xcodebuild \
    -workspace "$WORKSPACE" \
    -scheme "$SCHEME" \
    -destination "$DESTINATION" \
    -configuration Debug \
    build > "$raw_log" 2>&1 || {
      cat "$raw_log"
      echo "Build failed with $xcode_path"; exit 1
    }
  grep -E '(warning:|error:)' "$raw_log" | sort -u > "$out_file" || true
  echo "    $(wc -l < "$out_file") distinct diagnostic lines"
}

run_build "$XCODE_OLD" "$WORK/old.txt"
run_build "$XCODE_NEW" "$WORK/new.txt"

echo
echo "=== New in $XCODE_NEW ==="
comm -13 "$WORK/old.txt" "$WORK/new.txt"
echo
echo "=== Resolved in $XCODE_NEW ==="
comm -23 "$WORK/old.txt" "$WORK/new.txt"

The script stops on any build failure, so a broken build is never counted as data. Treat timings as rough — they are not benchmark results. Xcode already parallelises independent targets within a scheme, so the second run is often faster from warm caches rather than any toolchain difference.

Disk Space Planning

Two full Xcode installs plus simulator runtimes and DerivedData add up quickly on a hosted Mac:

The $29 Figment virtual Intel macOS plan ships with 80 GiB of disk, 2 vCPU and 8 GiB RAM — enough for two Xcode 26.x installs and one shared simulator runtime if you keep DerivedData pruned. Useful hygiene:

rm -rf ~/Library/Developer/Xcode/DerivedData/*
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/CoreSimulator
xcrun simctl list runtimes            # copy the identifier you want to remove
: "${SIM_RUNTIME_ID:?Set the exact unused runtime identifier to remove}"
xcrun simctl runtime delete "$SIM_RUNTIME_ID"

If two full Xcode versions plus several simulator runtimes need to stay resident, request a quote for a larger M-series plan — storage above the VM default is configured per order.

Pick the Right Figment Plan

The direct recommendation depends on which Xcode line you are comparing:

A fair cross-vendor sanity check: CloudMac lists an M4/16 GB/256 GB mini at $99.99/month and a $999/year prepay on cloudmac.org (effectively $83.25/month) — cheaper over twelve months than 12 × $95 if your workload fits an unmanaged M4 and the 256 GB row is still showing "Reserve now" when you order. MacStadium publishes an M2.S at $109, M4.S at $149 and M4.M at $249 with its 99.99% uptime claim and included support. Figment's $29 Intel VM is an entry-price option, not equivalent hardware to an M4; the material difference on the Managed plans is the specific CI setup, backups and monitoring work included for you. Confirm the exact chip, RAM, disk, term and any fees in the quote before you commit.

Xcode / macOS Compatibility

The Figment Intel VM is being provisioned with macOS Sequoia, which pairs with Xcode 26 and the early 26.x releases. A later 26.x point release that raises its floor to Tahoe will not install on Sequoia; Tahoe itself supports selected Intel models (see Apple support 122867), so whether a Tahoe image is available for your VM depends on plan configuration — ask when you request the quote.

Get Started

The diff script runs on any macOS host with two named Xcode installs. On a Figment Mac, the only setup cost is download time and disk space. Visit Figment Mac Hosting to see the plan line-up, or jump straight to a configuration request.

Start your configuration request →

Related guides:

• SSH-Based Xcode Workflow on Linux
• Remote Swift Development with VS Code Tunnel
• Run a GitHub Actions Self-Hosted Runner on a Remote Mac