
Do the SDK upgrade on a Figment M-series Mac (from $95/month; exact chip, RAM and disk are confirmed in the quote) if your target is Xcode 27 or any Apple-silicon-only toolchain. Stay on the Figment i3 Mac ($49/month, request-based) when your target is Xcode 26 and your project still builds cleanly under Intel. The $29 virtual Intel macOS instance is useful as a cheap second environment to keep the old Xcode 26 build alive during the transition. Configure the machine at /mac-hosting/start before you plan the cutover.
The safest way to adopt a new iOS SDK is to keep both Xcode versions on disk, run your build pipeline against each, compare the output, and retire the old toolchain only after every job is green. A rented Mac is the right place for this work: the machine you are experimenting on is not the one you ship from, so a bad upgrade cannot derail a release in flight.
An Xcode upgrade changes three things that can silently break an existing project:
@available or marked deprecated in the old SDK can turn into hard errors in the new one. A build that passed last week fails today with no code changes.The practical move is to compile against the new SDK, treat every warning as a future error, and fix entitlement and Info.plist issues before you switch the primary pipeline.
Confirm your rented Mac can run the Xcode you want before you download anything.
| Xcode | iOS SDK | Where it runs |
|---|---|---|
| Xcode 26.x | iOS 26 | Apple silicon or a supported Intel Mac; the exact macOS pair varies by minor release |
| Xcode 27 | iOS 27 | Apple silicon only; Xcode 27 can still cross-build x86_64 for macOS 27, but the IDE does not run on Intel |
Apple's porting guide says plainly: Intel Macs must use Xcode 26 or an earlier release (developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon). Xcode 26 bundles the iOS 26 SDK, which meets the App Store submission floor in force since April 28, 2026 (developer.apple.com/news/upcoming-requirements). macOS Tahoe still installs on several late-model Intel Macs per Apple's compatibility list; the Apple-silicon constraint is specific to the Xcode 27 IDE, not to Tahoe itself. Different Xcode 26 minor releases require different macOS minimums, so check the exact pair you need in the Xcode release notes.
If you are on a Figment i3 Mac, Xcode 26 is the ceiling. Moving to Xcode 27 means moving to an M-series Mac. A simple cost sketch for a two-month overlap, where you keep the old Intel toolchain running on the i3 while you validate Xcode 27 on an M-series Mac: $49 + $95 for month one, $49 + $95 for month two = $288 total, after which you retire the i3 and the M-series continues at $95/month. If you can retire the Intel host after a single month of parallel work, the one-time cost of the overlap is $49. Those numbers use Figment's listed entry prices; your quoted hardware and term may differ.
Never overwrite /Applications/Xcode.app while a build job is holding it. Rename the current install and expand the new one into a separate path.
# No build jobs should be running at this point.
# 1. Rename the current Xcode to a versioned path
sudo mv /Applications/Xcode.app /Applications/Xcode-26.app
# 2. Expand the new Xcode download (adjust the filename to match your download)
cd ~/Downloads
xip --expand Xcode_27.xip
sudo mv ~/Downloads/Xcode.app /Applications/Xcode-27.app
# 3. Accept the license for the new install
sudo /Applications/Xcode-27.app/Contents/Developer/usr/bin/xcodebuild -license accept
# 4. Register the new install with Launch Services
sudo xcode-select --switch /Applications/Xcode-27.app
sudo xcodebuild -runFirstLaunch
Both versions now coexist. xcode-select decides which toolchain xcodebuild and all xcrun invocations resolve against.
# Point the system at the new Xcode
sudo xcode-select --switch /Applications/Xcode-27.app
xcodebuild -version # should report Xcode 27.x
xcrun --sdk iphoneos --show-sdk-version # should report the iOS 27 SDK
# Back to the old Xcode when you want the shipping toolchain
sudo xcode-select --switch /Applications/Xcode-26.app
xcodebuild -version # should report 26.x
Keep the two developer directory paths in a note or in your CI job variables; typos are the most common cause of "which Xcode just built this" confusion.
Save this script as build-both-sdks.sh. It takes your own scheme and workspace as arguments; it does not invent a scheme name, and it stops the moment either build fails, so a red run cannot masquerade as a fast success.
#!/usr/bin/env bash
# build-both-sdks.sh
# Usage: ./build-both-sdks.sh MyScheme /path/to/MyApp.xcworkspace
set -euo pipefail
SCHEME="${1:?Usage: $0 SCHEME WORKSPACE}"
WORKSPACE="${2:?Usage: $0 SCHEME WORKSPACE}"
XCODE_OLD=/Applications/Xcode-26.app
XCODE_NEW=/Applications/Xcode-27.app
build_with () {
local xcode_path="$1"
local label="$2"
local log
log="$(mktemp -t xcb-"${label// /_}").log"
echo ""
echo "=== Building with ${label} ==="
sudo xcode-select --switch "${xcode_path}"
xcodebuild -version
# pipefail ensures a failing xcodebuild fails the whole pipeline
xcodebuild \
-workspace "${WORKSPACE}" \
-scheme "${SCHEME}" \
-sdk iphonesimulator \
-destination 'generic/platform=iOS Simulator' \
clean build \
CODE_SIGN_IDENTITY="" \
CODE_SIGNING_REQUIRED=NO \
CODE_SIGNING_ALLOWED=NO \
| tee "${log}"
echo "--- ${label}: build succeeded (log: ${log}) ---"
}
build_with "${XCODE_OLD}" "Xcode 26 (old SDK)"
build_with "${XCODE_NEW}" "Xcode 27 (new SDK)"
echo ""
echo "Review deprecation warnings in the Xcode 27 log before retiring Xcode 26."
The script disables signing for the validation build only. For a signed archive, drop the three CODE_SIGN* overrides and keep certificates in your CI secret manager - never in environment dumps or shell history. If you run the script from an unattended CI job, replace sudo xcode-select --switch with a passwordless sudoers rule scoped to that single command on the rented Mac.
The new Xcode ships with new simulator runtimes. Install them, then run your test suite.
# What is already installed and what is downloadable
xcrun simctl list runtimes
# Pull the matching iOS platform assets for the active Xcode
xcodebuild -downloadPlatform iOS
# Run the tests on the new runtime after switching
sudo xcode-select --switch /Applications/Xcode-27.app
xcodebuild test \
-workspace MyApp.xcworkspace \
-scheme MyScheme \
-destination 'platform=iOS Simulator,name=iPhone 16 Pro,OS=latest'
Keep the old runtime installed until the new one is green. Multiple runtimes coexist without interference, so there is no reason to delete the shipping one early.
Once every build job, CI pipeline and TestFlight submission has moved to the new SDK:
# 1. Retire the old Xcode
sudo rm -rf /Applications/Xcode-26.app
# 2. Drop simulator runtimes no longer tied to an installed Xcode
xcrun simctl delete unavailable
# 3. Clear build caches accumulated during overlap testing
rm -rf ~/Library/Developer/Xcode/DerivedData/*
A full Xcode install is typically 15-20 GB on disk, and each unused simulator runtime is several GB more. A migration cycle usually frees 25-30 GB once the cleanup above is complete; your exact savings depend on how many runtimes you kept side by side.
New SDK builds produce new dSYMs; the crash log symbolication guide covers matching them cleanly during an overlap period. Use the AddressSanitizer guide for a memory-safety pass against the new SDK before you ship, and the GitHub Actions self-hosted runner guide to drive both Xcode versions from a single staged CI pipeline.
Configure the rented Mac you will do the upgrade on at /mac-hosting, or start the order directly at /mac-hosting/start.