iPhone Duoを企業iOS CIにどう組み込む？2026年の受け入れガイド

シミュレーターではテストが通るのに、実機を含むリリース判定に使えるか決められない。
iPhone Duo SimulatorはXcode 27.1のCIに代表的な構築・レイアウト検証として加えられますが、シミュレーターの成功だけを完全なリリース受け入れとは扱わないでください。制約を先に確認し、必要な実機または手動確認を別の証拠として記録します。

企業IT・CI基盤の担当者：既存のMac環境が新しいシミュレーターを実行できるか、導入前に確認したい方。
アプリチームの責任者：折りたたみ、展開、画面サイズの変化を検証対象にしたい方。
QA・リリース担当者：未確認範囲を明示し、承認記録と結びつけたい方。

最終更新：2026年10月25日。確認対象はAppleのXcode 27.1リリースノート、Xcodeのシステム要件、iPhone Duoの準備ガイドおよびデザインガイドラインです。正式版の記述と現在の対応範囲は、導入時にも再確認してください。

iPhone Duoの企業向けiOS CIテストで、最初に決めること

CIの合格条件は、「シミュレーター上で起動した」だけでは不十分です。パイプラインで確認するのがビルドの成立なのか、代表的な画面レイアウトなのか、リリースの承認条件なのかを分けて定義します。確認目的が曖昧なままだと、ビルド成功がリリース可能という意味に誤読されます。

iPhone Duo Simulatorを自動化パイプラインに含めること自体は選択肢になります。ただし、シミュレーターで再現できない挙動や対象外の機能がある場合は、CIの合格結果から除外し、別の検証担当と証拠を指定します。AppleのXcodeにおけるテスト実行と結果の解釈も参照し、結果ログを判定に使える形で保存してください。

iPhone Duo Simulatorを自動化CIに入れられますか？
代表的なビルドとレイアウト確認のジョブには組み込めます。CIエージェントが使用するXcode、対象シミュレーター、テストの起動条件を固定し、実行に失敗した場合とテストが失敗した場合を区別できるログを残します。シミュレーターの利用可否だけでなく、必要なテスト機能が動くかを先に試してください。

役割ごとに受け入れ責任を分ける

一つのCI結果に、基盤の稼働確認、画面の品質確認、リリース承認をまとめると、誰が未検証項目を引き受けるのか不明確になります。テストを同じジョブで実行しても、承認と記録は役割ごとに切り分けます。

• CI基盤担当：ビルドMacのmacOSとXcodeが要件を満たすか確認します。使用したXcodeの版、シミュレーターの構成、ジョブの実行条件を記録し、更新後も同じ条件で再現できるようにします。
• アプリチーム：アプリが対応する画面と操作を選び、外側・内側の画面や展開・折りたたみなど、実際に必要な状態をテストケースに落とします。どの状態を製品としてサポートするのかも明記します。
• QA担当：ビルド・起動確認、レイアウト回帰、操作確認、実機確認を別の検証層として管理します。シミュレーターで確認できなかった機能は、未検証のままにせず担当と追加確認方法を割り当てます。
• リリース責任者：合格条件、リリースを止める不具合、例外承認の条件、問題発生時の差し戻し先を決めます。未解決項目が残る場合に、承認できる条件も記録します。
• IT・調達担当：実際に選定したMacとアクセス方式でCIジョブを試します。遠隔環境を利用する場合も、必要なXcodeやシミュレーターが使えると事前に決めつけず、運用要件と現物の環境を照合します。

Xcode 27.1とシミュレーターの制約をどう確認するか

Xcode 27.1のiPhone Duoシミュレーターに既知の制約はありますか？
Xcode 27.1のリリースノートを確認し、シミュレーターで実行できない拡張機能など、対象テストに関わる既知の問題を洗い出します。リリース候補版のノートに記載された制限が正式版にも残っているとは限らないため、導入時点の正式な記述で確かめ、古い情報をそのままCIルールにしないでください。

CI担当は、次の順に環境を検証します。

• Appleのシステム要件で、ビルドMacのOSと利用するXcodeの組み合わせを確認します。要件に合わない場合は、シミュレーターのテスト設計に進む前にビルド環境を更新するか、別の対応環境を用意します。
• Xcode 27.1のリリースノートで、iPhone Duo Simulatorに関係する既知の問題と対象範囲を確認します。記載の有無だけで判断せず、チームのアプリが使う拡張機能、サービス、実行方法に照らします。
• Device Hubなど、Xcodeのデバイス情報や対象の選択に関係する機能を確認します。AppleのDevice Hub資料に沿って、チーム内で対象環境の特定方法をそろえます。
• CIジョブを手動実行し、ビルド、シミュレーター起動、テスト実行、結果の保存を個別に確認します。起動できない、テスト対象が見つからない、結果が取得できない問題を、一括して「テスト失敗」と扱わないようにします。
• XcodeやOSを変更した後は、同じ確認を再実行します。変更前後の環境情報と結果を関連づければ、ツールチェーン更新による失敗かアプリの回帰かを切り分けやすくなります。

リリース候補版の既知問題は調査の手掛かりにはなりますが、正式版の保証事項として扱うものではありません。正式版のノートと、チームのCI上で再現した結果を別々に記録してください。

姿勢とサイズの変化を再現可能なテストにする

画面状態を「iPhone Duo対応」という一つの項目で済ませると、どの表示を確認したのか後から検証できません。アプリがサポートする体験を基準に、画面状態、操作、期待結果を一組のテストケースとして定義します。

AppleのiPhone Duo向け準備ガイドとデザインガイドラインを開発時の根拠にし、動的レイアウトや画面サイズ変更時の更新を確認項目にします。実装の見た目を固定の寸法だけで判断せず、サイズ変化後にビューの寸法を読み直す必要があるかもテスト対象として扱います。

用意するケースには、外側と内側の画面、展開・折りたたみなど、プロダクトが対応する代表状態を含めます。すべての画面・状態を自動化できない場合は、リスクの高い画面を自動テストに残し、残りを手動確認に割り当てます。どの状態が自動化対象外なのかを、リリース記録から追えるようにしてください。

テスト結果をリリース承認の証拠にする

シミュレーターのテストが通った後、何を追加で確認しますか？
シミュレーターでカバーできる範囲と、実機または手動確認が必要な範囲を分けます。アプリの公開条件や機能要件で実機確認が必要なら、CIの成功とは別の承認項目にし、未実施のままリリースしない運用にします。

テスト報告には、使用したMac環境とXcode、対象シミュレーター、対象のテストケース、実行結果、未確認事項を含めます。失敗時に担当者が追跡できるログと、承認・例外の記録も結びつけます。実行条件や失敗結果をチーム内で共有する方法は、OrbVPSのヘルプ情報も参考に、実際の運用に合わせて確認してください。

比較表：役割別に残す記録

比較表：テスト層ごとの証拠と限界

比較表：導入判定の評価

条件分岐で導入と承認を決める

• 正式版のXcodeと対象環境でシミュレーターを実行でき、必要な機能も確認できた場合は、代表的な構築・レイアウトテストをCIに追加します。
• 一部の機能や姿勢がシミュレーターで再現できない場合は、その範囲を自動テストの合格条件から除外し、実機または手動確認の担当と証拠を指定します。
• MacのOS・Xcode要件が合わない、またはテスト結果を保存できない場合は、iPhone Duo対応の合格判定を保留します。先に環境を整え、再現可能なログを残してから評価します。
• 未確認項目がリリース要件に関わる場合は、例外承認の基準を満たすまで公開を止めます。例外を認める場合も、理由、承認者、追加確認の責任を記録します。

現在のMac CIを継続する選択は、既存環境を変えずに済む一方、環境更新や容量確保を自社で調整し、実行条件を維持する負担があります。新たにMacを購入する場合も、初期調達に加えて保守や稼働状況の管理が必要です。どちらが適するかは、CIの実行条件、運用体制、稼働の必要性で判断します。

一時的な検証環境や追加のビルド容量が必要なら、OrbVPSのMac環境を候補として、希望するXcode、シミュレーター、接続方法が実際に使えるか先に試してください。すべてのレンタル環境が同じ条件を満たすとは限らないため、契約前に作業負荷と環境要件を照合するのが安全です。日本向けのMacレンタル環境を確認し、継続的な固定負荷や物理接続が必須なら、自社保有を含めて比較してください。