AppleはXcode 27 Beta 6のリリースノートで、Xcode 27がApple Silicon Macのみで動作し、UIKitのInterface Builder文書をtoolchainモードでコンパイルできることを確認しています。Xcode 27の公式リリースノートに基づく判断は明確です。すべてのCIノードからSimulatorを削除してはいけません。構築専用ノードは軽量化し、アプリ起動やUI試験を行うノードにはSimulatorまたは実機を残し、まず同じプロジェクトで二重実行してください。
[ SECTION_01 ] この記事を読む対象
純粋なコンパイル、静的解析、成果物生成からSimulator依存を減らしたい構築担当者向けです。
XCTestやUI自動化を管理し、実行時のiOS互換性を確認する試験チームにも適しています。
リモートMacのノード構成、キャッシュ、再起動時の復旧方法を見直すDevOps担当者や開発基盤責任者にも役立ちます。
[ SECTION_02 ] 先に分けるべき5つの依存関係
「ビルドが通る」と「アプリが実行できる」は同じ結果ではありません。CIでは、次の要素を別々に記録します。
| 要素 | 役割 | Simulatorの判断 |
|---|---|---|
| SDK | API、ヘッダー、リンク対象を提供 | SDKだけならruntimeとは別です |
| Simulator runtime | iOSを仮想実行する環境 | アプリ起動やUI試験で必要です |
| 仮想デバイス | runtime上の試験対象 | destination指定時に必要です |
| Interface Builderコンパイル方式 | StoryboardやXIBの変換方式 | Xcode 27ではtoolchain方式を確認します |
| Test destination | どの環境で試験するか | 実行系テストでは必ず確認します |
Xcode 27とiOS 27は、2026年9月8日時点ではBeta資料を基準に扱うべき段階です。正式版での挙動、既知の不具合、最終的な対応範囲を先回りして断定することはできません。Xcodeの対応OSとハードウェア条件は、作業前にAppleのシステム要件表で確認します。
構築担当者が判断する境界
コードのコンパイル、静的解析、依存関係の解決、アーカイブ前の成果物生成は、Simulatorを起動しない構成へ移せる可能性があります。一方、アプリプロセスを起動する処理や、iOSフレームワークの実行時挙動を確認する処理は、単なるコンパイルではありません。
最初に現在のCIで、次の3種類を分けて実行します。
- 通常のビルド。
build-for-testingによる試験成果物の生成。test-without-buildingおよびUI自動化。
xcodebuildの引数や処理の役割は、AppleのXcodeコマンドラインツールリファレンスと照合します。ログには、destination、SDK、runtime名、仮想デバイスの識別子を残してください。
[ SECTION_03 ] 第一歩：Interface Builder文書を新方式で検証する
Xcode 27では、UIKitのInterface Builder文書をtoolchainモードで扱える設定が示されています。対象はStoryboardやXIBなどの文書であり、アプリを実行する環境そのものが不要になるという意味ではありません。
既存プロジェクトで見るべき点は3つです。
- デフォルト設定でtoolchain方式が選ばれているか。
- 独自のビルド設定でsimulator方式に固定されていないか。
- スクリプトが
ibtoolを直接呼び出し、別の引数を渡していないか。
設定名や値は、プロジェクトのBuild SettingsとAppleのBuild Settings Referenceで確認します。IBC_COCOATOUCH_COMPILER_MODEの値だけを見るのでは不十分です。生成されたStoryboard関連の成果物、警告、参照切れ、画面表示の差も比較します。
toolchain方式で成功しても、移行完了とは判定しません。旧プロジェクト、自作スクリプト、特定ターゲットだけがsimulator方式を要求するケースがあります。回退する場合は、発生条件、対象ターゲット、復旧する設定値をCIの記録に残します。
[ SECTION_04 ] 第二歩：単体試験を宿主アプリで分類する
Unit Testsという名称だけで、すべてを軽量ノードへ移すのは危険です。純粋なSwiftロジックだけを検証するテストと、アプリやiOSフレームワークを必要とするテストでは、実行環境が異なります。
| 試験の種類 | 主な依存関係 | 配置の候補 | 判定 |
|---|---|---|---|
| 純粋なSwiftロジック | 言語処理系、ライブラリ | 軽量な構築ノード | Simulatorなしを検証しやすい |
| アプリ宿主付き単体試験 | Test Host、アプリプロセス | 完全な試験ノード | Simulatorまたは実機を残します |
| iOS統合試験 | 権限、OS API、実行時状態 | 完全な試験ノード | 実行環境の確認が必要です |
| UI自動化 | 被試験アプリ、画面、入力 | Simulatorまたは実機ノード | 構築ノードへ移せません |
テストターゲットごとに、Test Host、SDK、destination、生成されたテスト成果物を確認します。テスト実行と結果の解釈に関する公式資料では、実行結果と失敗情報を分けて扱う方法が説明されています。
宿主アプリを必要としないテストでも、依存ライブラリがOSの挙動に触れるなら、軽量ノードだけで合格にしない方が安全です。軽量ノードはフィードバックを速くする場所、完全ノードは互換性を証明する場所、と役割を分けます。
[ SECTION_05 ] 第三歩：UI自動化は完全な試験ノードに残す
XCTest UI Testsは、被試験アプリを起動し、画面要素を探し、操作結果を確認します。Interface Builder文書をSimulatorなしでコンパイルできても、画面を実行するruntimeは代替されません。
Test Planでは、対象デバイス、試験対象、並列化の条件を明示します。Test Planの整理方法に関するAppleの資料に沿って、結果パッケージを保存してください。ログに「コンパイル成功」とあっても、アプリが起動していなければUI試験の成功ではありません。
並列化する場合は、Simulatorの複製、ノード内のCPU・メモリ競合、画面録画や診断ファイルの保存失敗を確認します。容量や処理時間について、公式資料または自社の実測なしに固定値を置くべきではありません。
[ SECTION_06 ] 3つのCI構成を比較する
構築ノードと試験ノードを分けるかどうかは、プロジェクトの試験内容で決まります。次の表は、導入判断を短く整理したものです。評価は一般的な運用上の判断であり、Appleが保証する性能値ではありません。
| 構成 | 向いている状況 | Simulator依存 | 運用評価 |
|---|---|---|---|
| 単一ノード | 小規模で全工程を同じ環境で実行 | 常時保持 | 移行リスクは低いが、資源の分離度は低い |
| 二層ノード | 構築とUI試験の待ち時間・権限を分けたい | 試験側だけ保持 | 最も検証しやすい構成です |
| 移行保留 | 旧設定や直接呼び出しが多い | 既存環境を維持 | 失敗原因を先に整理できます |
| CI工程 | 軽量構築ノード | 完全試験ノード |
|---|---|---|
| 静的解析 | 実行 | 必要に応じて実行 |
| 通常のコンパイル | 実行 | 比較用に実行 |
build-for-testing |
実行 | 比較用に実行 |
test-without-building |
原則配置しない | 実行 |
| UI自動化 | 配置しない | 実行 |
| 実行時互換性確認 | 配置しない | 実行 |
Appleの技術ノートでは、build-for-testingで試験用成果物を作り、別工程でtest-without-buildingを実行する流れが説明されています。Build For TestingとTest Without Buildingの技術ノートを使えば、同じ成果物を別ノードで実行する設計を検討できます。
[ SECTION_07 ] 第四歩：同一コミットで二重実行する
候補ノードへ移す前に、次の順序で確認します。
- 同じコミット、同じXcode 27のBeta、同じSDKで通常ビルドを実行します。
- StoryboardとXIBを含むターゲットの生成物と警告を比較します。
build-for-testingで試験成果物を作ります。- 完全な試験ノードで
test-without-buildingを実行します。 - UI自動化をTest Planの対象デバイスで実行します。
- ノードを再起動し、キャッシュ、runtime、署名情報、成果物の復旧を確認します。
- Simulatorのdestinationやruntimeが暗黙に呼ばれていないかログを検索します。
ビルド成功だけで判定しないことが重要です。App Store Connectへアップロードする成果物では、ビルドのアップロード手順に沿って、成果物の形式と処理状態も確認します。
[ SECTION_08 ] リリース責任者が見る合格条件
リリース担当者は、単純な成功回数ではなく、失敗時の戻し方を比較します。StoryboardまたはXIB、アプリ宿主付き試験、UI自動化を含む現実のプロジェクトを選び、従来ノードと候補ノードで同じパイプラインを走らせます。
次の条件を満たした工程だけ、軽量ノードへの正式移行候補にします。
- 純粋な構築が継続して成功する。
- Simulator runtimeやdestinationを暗黙に要求しない。
- 生成物が従来ノードと比較できる。
- 失敗後の再実行と再起動復旧を確認できる。
- UI試験と実行時互換性確認を完全な試験ノードへ残している。
移行後も、Beta 7、RC、正式版、Interface Builderの既知の問題が出た時点で再検証します。Xcode 27とiOS 27の最終仕様を、Beta時点の結果だけで固定しないでください。
[ SECTION_09 ] よくある判断を短く整理する
Xcode 27の構築からSimulatorを外せる場合
UIKitのStoryboardやXIBを含む場合でも、toolchainモードが適用され、独自設定や直接呼び出しが妨げていなければ、構築専用ノードからruntimeを外せる可能性があります。まず通常ビルドとbuild-for-testingを分け、ログに実行先が残っていないことを確認します。
Simulator runtimeを残すべきCI
アプリ宿主付き試験、UI自動化、OS APIの実行時挙動、複数のiOSバージョン確認では、Simulatorまたは実機を使います。SDKをインストールしただけでは、アプリを起動する環境や仮想デバイスは用意されません。
StoryboardとXIBの移行判断
toolchain方式への切り替えは、既存文書を自動的に無条件で安全にする機能ではありません。生成物、警告、画面表示、独自のibtool呼び出しを比較し、問題が出たターゲットだけsimulator方式へ戻せる設計にします。
リモートMacの分割方法
静的解析、通常ビルド、成果物生成は構築用リモートMacへ集約します。Simulatorを使う試験は完全な試験用リモートMacへ分け、build-for-testingとtest-without-buildingの成果物受け渡しを検証します。構成変更の前に、NOVAKVMのMacレンタル案内で必要な利用形態を確認する方法もあります。
[ SECTION_10 ] NOVAKVMを使った移行前の現実的な進め方
現在の単一Mac構成をいきなり分割すると、失敗時に原因が分かりにくくなります。まず回退可能なリモートMacへ実プロジェクトを複製し、構築専用の処理と完全な試験処理を別々に実行します。その後、必要な期間だけ構築池または試験池を用意する方が、固定ハードウェアを先に購入するより判断しやすい場合があります。
自社のMac miniを常時稼働させる方式は、電源、回線、保守、再起動、ストレージ障害を自社で担う必要があります。購入方式の運用条件を比較する場合は、Mac miniの導入判断ガイドで初期導入と継続運用の分担も確認できます。
Linux中心のクラウド構成は、macOS専用のXcode、Simulator、署名工程をそのまま置き換えられません。NOVAKVMのリモートMacレンタルなら、短期の検証用ノードと継続試験用ノードを工程ごとに分けて試せます。長期に高稼働で物理ポートや専用機器が必要なチームには購入が適し、まずCIの境界を確かめたいチームにはレンタルが現実的です。