Xcode 27のビルドマシンにシミュレーターは必要？という判断には、公開用のArchive、署名、TestFlight提出だけならiOS Simulator Runtimeを先に入れない、というのが最短解です。UIテスト、SwiftUI Preview、複数OSの動作確認まで同じマシンで行う場合だけ、対象Runtimeを追加してください。

対象読者 Release Archiveと署名・アップロードだけを担当する独立開発者は、不要なコンポーネントを避ける判断に使えます。StoryboardやXIBを含むUIKitプロジェクトの担当者は、画面リソースのコンパイル条件を確認できます。Simulatorを使うテストや互換性検証を行う小規模チームは、公開用マシンとテスト環境を分ける基準を得られます。

最終更新：2026年9月5日。Xcode 27 Beta 4の掲載状況、Release NotesのInterface Builder項目、コンポーネント管理とテスト関連のApple公式資料を確認しています。Betaの挙動はRC版や正式版で変わる可能性があるため、固定仕様として扱わないでください。

まず構成を分ける

Xcode、iOS SDK、Simulator Runtime、シミュレーター上の仮想デバイスは別の要素です。SDKはアプリを対象OS向けにコンパイルするための基盤であり、RuntimeはiOS Simulator上でアプリを起動するための実行環境です。Xcode 27の対応OSや配布条件は、更新されたAppleのXcodeシステム要件で確認してください。

<
実行する仕事iOS Simulator Runtime最初の判断完了を示す証拠
Release Archive、署名、TestFlight提出原則不要最小構成から開始xcarchive、署名検証、提出前検証
SwiftやObjective-Cの通常コンパイル原則不要SDKを確認xcodebuildの成果物
Storyboard、XIBを含むArchive原則不要。ただし設定確認が必要Interface Builder toolchainを確認実際の画面リソースを含むArchive
iOS Simulator上の単体テスト必要対象OSのRuntimeを追加xcresult
XCTest UI Tests必要Schemeとdestinationを確認UIテストのxcresult
SwiftUI Preview、複数OS・端末の確認必要テスト用環境へ分離Previewまたは各検証結果
Xcode 27 Beta Release Notesでは、UIKitドキュメントのコンパイルにInterface Builder toolchainを使う動作が示されています。このため、StoryboardやXIBがあるだけでSimulator Runtimeを必ず導入する、という判断にはなりません。詳細は[AppleのXcode 27 Beta Release Notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes?changes=latest_minor)で、使用中のBetaに該当する記載を確認してください。

公開用ビルドマシンの最小構成

Release Archive、コード署名、TestFlight提出を行うだけなら、最初から全Runtimeをダウンロードする必要はありません。Appleが案内する追加Xcodeコンポーネントの管理方法に沿って、Xcode本体と対象SDKを用意し、実際のジョブで不足がないかを検証します。

「Xcode 27不インストールでArchiveできるか」という検索意図への答えは、Simulator Runtimeを入れていなくても、Archive処理自体は成立し得る、です。ただし、プロジェクトのスクリプトがsimctlを呼び出していたり、destinationをSimulatorに固定していたりする場合は別の依存関係になります。

TestFlight提出だけを担当する場合も、Simulatorを削除すれば必ず安全になるわけではありません。削除対象を決める前に、署名、Provisioning Profile、ExportOptions、App Store Connectへの転送、提出前検証が同じジョブで完了することを確認してください。配布用Archiveから提出までの流れは、AppleのBetaテストとリリース向け配布資料を基準にします。

次の条件を満たすなら、公開用マシンはRuntimeなしの構成から始められます。

  • [ ] SchemeのArchiveがSimulator destinationを指定していない
  • [ ] CIスクリプトにsimctl、Simulator起動処理、画面キャプチャ処理がない
  • [ ] Release Archiveをクリーンな作業領域から再現できる
  • [ ] 署名とExport処理を同じ条件で確認できる
  • [ ] TestFlight提出前の検証が成功し、xcarchiveを保存できる
  • [ ] Runtime不足時にテスト用マシンへ切り替える手順がある
Appleの[Xcodeコマンドラインツールリファレンス](https://developer.apple.com/documentation/xcode/xcode-command-line-tool-reference?changes=la)を見ながら、コマンドが成功したかだけでなく、生成物と署名状態まで確認してください。終了コードが成功でも、別のジョブでSimulatorを要求していれば、公開用マシン全体が最小構成で成立したとは言えません。

**注意** 空のプロジェクトがArchiveできても、実際のプロジェクトのStoryboard、XIB、Run Script、Test Planまで問題なく処理できるとは限りません。同じコミットを使い、実際のSchemeで確認してください。

UIKitプロジェクトの画面リソース

StoryboardプロジェクトのコンパイルにSimulator Runtimeが必要かどうかは、画面リソースの有無ではなく、Interface Builderのコンパイルモードとプロジェクト設定で決まります。Xcode 27では、UIKitドキュメントをInterface Builder toolchainで処理する既定の動作が案内されています。

プロジェクトやスクリプトでIBC_COCOATOUCH_COMPILER_MODEを上書きしている場合は、設定名と値をAppleのBuild Settings Referenceで確認してください。古い設定を引き継いでsimulatorモードへ戻しているなら、その変更がRuntime依存を生んでいる可能性があります。

確認は次の順番で行います。

  • 実際のStoryboardとXIBを含むRelease Archiveを作成する
  • Archive内に画面リソース由来のコンパイル成果物が含まれるか確認する
  • Build SettingsでInterface Builder関連の上書きを確認する
  • Run ScriptにSimulator専用の処理がないか検索する
  • Runtimeなしの冷起動状態で同じArchiveを再実行する
ここで重要なのは、「Storyboardプロジェクトがビルドできた」ことと、「アプリをSimulatorで起動できた」ことを分けることです。前者はInterface Builder toolchainとSDKの検証であり、後者には対応するRuntimeと仮想デバイスが必要です。

テスト担当者のRuntime依存

Simulatorを実際に起動するテストだけが、対応するiOS Simulator Runtimeを要求します。macOS上だけで完結する単体テスト、通常のコンパイル、Archiveは同じ条件ではありません。一方、iOS Simulatorをdestinationにした単体テスト、XCTest UI Tests、build-for-testing後のtest-without-buildingは、対象Runtimeと起動可能な仮想デバイスを確認する必要があります。

<
テストまたは開発作業Runtime依存確認する設定
macOSだけで動く単体テストなしSchemeのテスト対象
iOS Simulator単体テストありdestination、OS、端末
XCTest UI TestsありUIテストのSchemeとTest Plan
build-for-testingだけ実行先によるビルドとテストの分離
test-without-buildingあり既存ビルドとRuntimeの一致
SwiftUI Preview通常はありPreview対象と実行環境
テストの追加方法は[Appleのテスト作成ガイド](https://developer.apple.com/documentation/xcode/adding-tests-to-your-xcode-project?changes=_4__3)を参照し、結果は[テスト実行と結果解釈の資料](https://developer.apple.com/documentation/xcode/running-tests-and-interpreting-results?changes=_9)に沿ってxcresultを保存します。Archiveが成功しても、UIテストが完了した証拠にはなりません。

複数のiOSバージョンや端末レイアウトを確認する場合は、公開用ビルドマシンにすべてのRuntimeを常駐させるより、テスト用のMacへ分離する方が運用しやすいケースがあります。複数のSimulatorプラットフォームとバージョンを扱う方法は、AppleのSimulator環境に関する公式資料で確認してください。

チーム別の分離判断

低頻度でArchiveするだけなら、必要なRuntimeを作業時だけ追加する方法が候補になります。安定した公開を繰り返すチームは、構成変更を抑えたRuntimeなしの公開用マシンを常駐させ、Simulatorを使う作業を別環境へ移す方が、直前のリリースに影響を与えにくくなります。

<
チームの担当範囲推奨構成避けたい判断
Archive、署名、提出のみ精簡な公開用マシン将来使うかもしれないRuntimeの常駐
Storyboard/XIBを含む公開Interface Builder設定を確認した公開用マシン画面リソースだけを理由に全Runtimeを追加
UIテストとPreviewを頻繁に実行公開用マシンとテスト用マシンを分離公開直前にRuntimeを追加・削除
複数OSの回帰確認専用テスト環境一度の空プロジェクト検証で構成を固定
遠隔のMacをビルド用途に使う場合は、必要な作業を先にArchive、署名、テスト、提出へ分類してください。MACGPUの[遠隔Macの利用案内](https://macgpu.com/ja/index.html)を確認する場合も、最初から最大構成を選ぶのではなく、実際のジョブに必要な環境を基準にするのが安全です。

**運用上の経験則** Runtimeを追加する前に、Scheme、Test Plan、destination、Run Scriptを記録してください。追加後に成功しても、どの依存関係が解消されたのか分からなければ、次回の環境更新で同じ問題を再現できません。

冷起動後の最終確認では、次の順に記録を残します。
  • xcodebuildによる通常ビルドとRelease Archive
  • StoryboardまたはXIBを含む画面リソースのコンパイル
  • 署名、Export、提出前検証
  • Simulatorを使うテストの有無とxcresult
  • Runtimeがない場合の失敗箇所と復旧手順
  • Xcode 27 BetaからRC・正式版へ移行する際の再検証日
2026年9月5日時点では、Xcode 27 Beta 4に関する情報がAppleのシステム要件ページに掲載されています。ただし、BetaのInterface Builder動作を正式版の永続的な保証と見なさず、更新のたびに最小ArchiveとSimulatorテストを分けて再確認してください。

公開用ジョブが中心なら、現在の構成をそのまま大型化するより、まずRuntimeなしの遠隔Macで実プロジェクトを短期間検証する方が判断しやすいです。反対に、UIテストや複数OS検証を同じ環境で頻繁に行うなら、単一の公開マシンにすべてを詰め込むより、テスト用環境を別に用意する方が復旧経路を保ちやすくなります。

自前のMacを購入して常時稼働させる方法は、物理アクセスや長期の固定負荷には向いていますが、初期費用、保守、OS更新、空き時間の機器維持が発生します。一般的なクラウド開発環境ではmacOS専用ツールチェーンや署名環境の条件が合わないこともあり、Simulatorを使わない短期のArchive検証には構成が重くなりがちです。必要な期間だけ実機のmacOS環境を確保し、公開用とテスト用を分けたいなら、MACGPUのMac利用プランを候補にして、実際のSchemeとTest Planで適合性を確認してください。