ヘッドレスでレンタルしたクラウドMac上のiOSシミュレーター xcodebuild test（2026）
香港・日本・韓国・シンガポール・米国でベアメタルのApple SiliconクラウドMacを借りるチームは、しばしばSSHのみで自動化します。CLTとフルXcode、並列ジョブの運用の次に来るのが、実機ファームなしのiOSシミュレーターXCTestです。本稿ではヘッドレス環境でのxcodebuild test、安定した-destination、1 TB / 2 TBにおけるシミュレーターのNVMe消費、UIテストの不安定化対策をまとめます。リリースレーンはリモートArchive、依存関係はキャッシュ管理と併読してください。
専用クラウドMacでシミュレーターテストをする理由
- 並列性 — ユニット中心のスイートではUSB実機より多くの論理シミュレーターを回しやすい。
- 再現可能なOS行列 —
iOS 18.xとiOS 17.xを版ごとにハードを増やさず固定。 - 地域 — SGやUSでAPIモックやコンプライアンスに近い場所で実行。
- コスト — シミュレーター分は実機スロットを消費しないが、NVMeは計画する。
xcrun simctl list runtimesを残し、共有ビルダーで空き容量が50 GBを下回ったらアラート。
ヘッドレスの現実（VNCなし）
CoreSimulatorとXCTestはWindowServerなしで多く動きますが、メイン画面ジオメトリやSpringBoard、カメラ/マイク権限に依存するテストは診断用に短いVNCが必要になることがあります。毎晩は不要。アクセシビリティ識別子を明示し、アニメーションを止め、描画に紐づくsleepを避けます。
xcodebuild test前にsimctl bootstatusが緑になるまで待つステップを追加。
安定した-destination文字列
Xcode更新後に「最新iPhone」が変わってCIが揺れることがあります。サポートするOSのmajor/minorを固定し、任意の一致シミュレーターでよいときは汎用プラットフォームdestinationを優先：
xcodebuild test -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' -derivedDataPath /tmp/dd-$BUILD_ID
アップグレード後はxcrun simctl list devices availableを再実行し、パイプライン変数を更新。JP/KRチームもデバイス名は英語のまま（ローカライズは識別子を変えない）。
CI七ステップ
- SwiftUI Previewsや特定シミュレーターバンドルが要るならフルXcode（CLTのみでない）。
- 複数Xcodeがあるレンタル機では
DEVELOPER_DIRを明示。 - ジョブごとに新しい
-derivedDataPathで同一ユーザーのArchiveジョブと干渉させない。 - セットアップでブートするか
xcodebuildに任せる—昨日のブート状態は前提にしない。 - ダッシュボードに応じ
-resultBundlePathや-enableCodeCoverage YES。 .xcresultを圧縮して保存、14日以上はトリアージ用に保持。- ブート失敗時はアサーションではなく
simctl diagnoseを添付。
判断：シミュレーター vs 実機
| ニーズ | シミュレーター | 実機 |
|---|---|---|
| 高速なユニット/ロジック | ✓ ホストあたり高並列 | 過剰；UDID/ケーブル摩擦 |
| Metal/カメラ/プッシュの忠実度 | 限定的 | ✓ デバイスラボまたはローカルHW |
| プロビジョニング/署名 | 第一ゲートに適する | ✓ App Store前に多く必要 |
NVMe計画：1 TB と 2 TB
| 項目 | 目安 | 対策 |
|---|---|---|
| iOSランタイム1セット | メジャーあたり8–15 GB | 行列に必要なランタイムだけ残す |
| ジョブごとのDerivedData+ModuleCache | 3–25 GB | 7日より古い/tmp/dd-*を削除 |
| シミュレーターデバイスデータ | UIスイートで増加 | 週次でsimctl delete unavailable |
iOS三世代×scheme五つを1台のMac mini M4で回すなら2 TBがディスク満杯の赤ビルドを減らしやすい—Xcodeを四並列する前に料金を確認。
症状と最初の確認
| 症状 | 確認 | 対処 |
|---|---|---|
Unable to boot device |
空き容量；ゾンビCoreSimulatorService | 再起動またはkillall -9 com.apple.CoreSimulator.CoreSimulatorService |
| destinationが見つからない | パッチ後にランタイム削除 | プラットフォーム再導入；YAMLのデバイス名更新 |
| SSHホストだけUIタイムアウト | アニメーション；SpringBoard | アニメーション無効；起動タイムアウトは慎重に |
FAQ
| 質問 | 回答 |
|---|---|
| 同一ユーザーでシミュレーターとArchiveを混在？ | -derivedDataPathを分離し並列ビルドガイドのキュー規則に従えば可。 |
| 毎回VNC？ | ログがWindowServerのみの失敗のときだけ。 |
| CIを遅らせずにデバッグ？ | ステージングでSSHガイドに沿って対話的に再現。 |
MacXCodeのMac mini M4が向く理由
シミュレーター負荷はCPU・メモリ帯域・ランダムI/Oの混合。レンタルMac mini M4は統合メモリと高速NVMeを提供し、過剰割当VMより隣ノイズが少ない—HK·JP·KR·SG·USの行列に適する。UIスイートが倍になったら第二ノードを。自動化はSSH、視覚デバッグはVNCを最終手段に。
ディスク階層は保持方針と揃える：1 TBは積極削除と単一プロダクト、2 TBは共有チーム向けに余裕。ノードとストレージ、クラウドCIならGitHub Actionsランナーと併用。
まとめ：destinationを固定し、DerivedDataを分離し、シミュレーターディスクを第一級の予算と見れば、ヘッドレスxcodebuild testは本番運用可能。次はTestFlight前にリモート署名の最適化。