2026年8月11日現在、Xcode 27 BetaはmacOS Tahoe 26.4以降、かつAppleシリコンMacが必要です。これは「macOS 27へ更新しない」こととは両立するため、条件を満たすMacなら安定版XcodeとXcode 27 Beta 5を共存させて検証できます。まず宿主OS、アプリの保存先、開発者ディレクトリ、Simulatorランタイムを分離してください。
症状: Betaを開いたのにターミナルやCIが安定版を呼び出す。
最短解決: xcode-select または DEVELOPER_DIR で対象Xcodeを明示し、xcodebuild -version の結果を記録します。
本稿では、2026年8月10日に公開されたXcode 27 Beta 5を対象にします。公開日、最新ビルド番号、Beta 5固有の修正内容は、作業前にApple Developerのリリース一覧とXcode 27 Beta Release Notesで再確認してください。
この手順を読むべき人
安定版Xcodeで公開中のアプリを保守しながら、iOS 27対応だけを先に確認したい個人開発者向けです。チームで同じBeta環境を共有したい場合や、主力Macに大きなBetaコンポーネントを残したくない場合にも使えます。
ただし、Intel Mac、macOS Tahoe 26.3以下のMac、実機固有機能を検証する担当者は、アプリを2つ入れるだけでは条件を満たしません。
先に確認する最低条件と共存の境界
Xcode 27 BetaにはSwift 6.4とiOS 27などの27系SDKが含まれ、宿主MacにはmacOS Tahoe 26.4以降が必要です。また、Xcode 27はAppleシリコンMacにのみインストールして実行できます。したがって、主力MacをmacOS 27 Betaへ上げる必要はありませんが、macOS Tahoe 26.4への更新まで避けることはできません。(developer.apple.com)
| 確認項目 | 共存に必要な状態 | 条件を満たさない場合 |
|---|---|---|
| CPU | AppleシリコンMac | Xcode 27 Betaを本機へ導入しない |
| 宿主OS | macOS Tahoe 26.4以降 | macOSを先に更新する |
| Xcode本体 | 安定版とBetaを別アプリとして保存 | 上書き更新を避ける |
| iOS 27 Simulator | 対応ランタイムを別途導入 | ダウンロード完了まで実行不可 |
| 実機検証 | Apple Account、証明書、プロビジョニングが必要 | Simulatorだけでは判定しない |
Xcode 27 Beta 5と安定版は同時に入れられますか
可能です。ただし、共存の単位はアプリ本体だけではありません。Xcode.appのパス、現在選択されているDeveloper Directory、SDK、Simulatorランタイム、DerivedDataを別々に管理する必要があります。
安定版を/Applications/Xcode.app、Betaを/Applications/Xcode-beta.appのように識別できる名前で保存します。Betaを通常版と同じ名前に変更したり、同じ場所へ上書きしたりすると、シェルスクリプト、CI、Finderの関連付けが別バージョンを呼ぶ原因になります。
次に、現在の開発者ディレクトリを確認します。
xcode-select --print-path
xcodebuild -version
出力は次の形式で記録します。ビルド番号は作業時に表示された値をそのまま保存してください。
/Applications/Xcode.app/Contents/Developer
Xcode 26.x
Build version <安定版のビルド番号>
Betaへ一時的に切り替える場合は、管理者権限を使う方法と、現在の設定を変えない方法を使い分けます。
sudo xcode-select --switch /Applications/Xcode-beta.app
xcodebuild -version
主力環境の既定値を変更したくない場合は、DEVELOPER_DIRをコマンド単位で指定します。
env DEVELOPER_DIR="/Applications/Xcode-beta.app/Contents/Developer" \
xcodebuild -version
xcode-select --switchは既定のDeveloper Directoryを変更しますが、DEVELOPER_DIRはそのコマンドだけに適用できます。複数のXcodeを切り替える運用では、後者をCIや検証スクリプトの標準にすると、作業後に主力環境を戻し忘れる事故を抑えられます。詳細は[Apple公式のコマンドラインツール設定](https://developer.apple.com/documentation/xcode/configuring-command-line-tools-settings)で確認できます。
macOS 27 Betaへ上げずにiOS 27を検証する条件
macOS 27 Betaへ更新しなくても、macOS Tahoe 26.4以降でXcode 27 Betaを動かせる条件なら、iOS 27 Simulatorを使った基本的な互換性確認は可能です。ここで混同しやすいのは、iOS 27のSimulatorランタイムと、macOS 27そのものが別の構成要素だという点です。
Xcodeの「Settings」から「Components」を開き、iOS 27のSimulatorランタイムが導入済みかを確認します。ランタイムが一覧に出ない、ダウンロードが途中で止まる、起動対象にiOS 27が表示されない場合は、Xcode本体ではなく追加コンポーネント側の問題である可能性があります。Appleの追加コンポーネント管理手順では、設定画面から導入状態を確認できます。
| 検証対象 | iOS 27 Simulatorで確認 | 別環境が必要になりやすい項目 |
|---|---|---|
| ビルドとリンク | 可能 | 署名設定の実機差分 |
| SwiftUIの画面表示 | 可能 | 実機GPUやメモリ負荷 |
| APIの基本動作 | 可能 | カメラ、Bluetoothなどの物理機能 |
| UIテスト | 可能 | 通知、バックグラウンド、実機権限 |
| App Store提出前のアーカイブ | 条件付きで可能 | 配布証明書、チーム権限、実機確認 |
キャッシュと署名の汚染を先に止める
Xcodeを2つ入れた後に起きるトラブルは、アプリ本体よりも共有データに集中します。特にDerivedData、Archives、Simulatorのユーザーデータを最初から全消去する運用は避けてください。ログや再現状態まで失われ、原因の切り分けが難しくなります。
プロジェクトごとにDerivedDataの保存先を分ける場合は、Xcodeの設定でカスタムパスを指定するか、検証用の作業ディレクトリを明確にします。少なくともBeta検証の最初のビルドでは、安定版と同じキャッシュを使わない構成にしてください。
署名エラーが出た場合も、証明書やプロビジョニングプロファイルをすぐ削除しないでください。まず次の順番で確認します。
xcode-select --print-pathでDeveloper Directoryを確認する。xcodebuild -versionで実際のXcodeを記録する。xcodebuild -showsdksでiOS 27 SDKが見えているか確認する。- Apple Accountとチームが正しく選択されているか確認する。
- Keychainの証明書、署名対象、プロビジョニングの順に調べる。
- Beta固有の既知の問題を公式Release Notesで照合する。
CIとターミナルの呼び出し先を固定する
Xcodeの画面でBetaを開いていても、ターミナルや自動化スクリプトが安定版を使うことがあります。これは「Xcodeアプリの選択」と「コマンドラインツールの選択」が別管理だからです。
最小の検証コマンドは次のように組みます。
env DEVELOPER_DIR="/Applications/Xcode-beta.app/Contents/Developer" \
xcodebuild -resolvePackageDependencies \
-workspace Sample.xcworkspace \
-scheme Sample
env DEVELOPER_DIR="/Applications/Xcode-beta.app/Contents/Developer" \
xcodebuild build-for-testing \
-workspace Sample.xcworkspace \
-scheme Sample \
-destination 'platform=iOS Simulator,name=iPhone'
実行ログには、使用したXcode、SDK、ワークスペース、スキーム、Simulatorのランタイムを残してください。CIでは環境変数をジョブ単位で設定し、ジョブ終了後にホストの既定Developer Directoryを変更しない構成が安全です。
CI運用や複数のXcodeを使う案件では、MACGPUのMac環境利用案内も確認しておくと、検証用環境と主力環境を分ける判断材料になります。必要な環境の条件を整理した後、利用期間や接続方法を比較してください。
本機運用か独立したクラウドMacかを採点する
短期間の個人検証なら、本機の双版本が最も早く、実機接続も簡単です。一方で、複数人が同じBeta環境を使う、検証期間を延ばす、失敗時に環境を捨てて作り直すといった条件では、独立したMac環境のほうが運用上の境界を作りやすくなります。
| 判断軸 | 本機に双版本を導入 | 独立したクラウドMac |
|---|---|---|
| 個人の短期検証 | 5点 | 3点 |
| 実機への接続 | 5点 | 2点 |
| 複数人での共有 | 2点 | 5点 |
| 主力環境の汚染回避 | 2点 | 5点 |
| 検証後の破棄・再作成 | 2点 | 5点 |
| オフライン作業 | 5点 | 2点 |
回退は削除ではなく順番で行う
検証が終わったら、次の順番で戻します。
xcode-select --print-pathを実行し、Betaが既定になっていないか確認する。- 安定版へ切り替える。
sudo xcode-select --switch /Applications/Xcode.app
xcodebuild -version
- 安定版で依存関係の解決、テスト対象のコンパイル、アーカイブを実行する。
- iOS 27 SimulatorランタイムとBeta専用デバイスを停止する。
- 不要なランタイムだけを削除し、必要なDerivedDataやArchivesは保管する。
- 証明書やプロファイルを削除せず、安定版の署名結果を確認する。
本機で短期検証するなら、Xcode本体だけでなくDeveloper Directory、Simulatorランタイム、キャッシュ、CIの呼び出し先まで分離することが条件です。反対に、主力Macの条件不足、複数人での並行作業、検証後に環境をすぐ破棄したい事情があるなら、双版本を維持するより独立したクラウドMacのほうが、権限と回退の境界を作りやすい選択です。
MACGPUで一時的なiOS 27検証環境を用意する場合は、MACGPUの利用条件を確認できる案内で作業期間と接続条件を整理してください。長期の安定した重負荷開発や物理デバイス接続が中心なら自前のMacが適していますが、Betaの短期検証や主力環境を汚したくない作業では、必要な期間だけMac環境を分ける方法が現実的です。