折りたたみ状態では画面が整っていても、展開後の主要操作までCIで確認できているか判断しにくいことがあります。
結論は、iPhone Duo企業CIテストマトリクスを全姿勢の総当たりにせず、Xcode 27.1のシミュレーターで代表的な折りたたみ・展開状態と重要画面を確認し、リスクに応じて自動回帰や実機確認を足すことです。
企業IT責任者：iPhone Duoの検収をリリース手順に加える範囲を決めたい方。
プラットフォームエンジニア：既存のMac CIでシミュレーター検査をどう動かし、結果を保存するか検討する方。
QA責任者：姿勢とユーザーパスを、再利用できる確認項目にしたい方。
最終更新：2026年10月28日。Apple Developerの準備・提出案内、Xcode 27.1のリリースノート、関連する設計資料を確認しています。
企業IT責任者が検収範囲を切り分ける
Appleは、iPhone Duoの発売日を2026年10月23日と案内し、Xcode 27.1で対応する開発機能と、姿勢や向きによる表示を確認する手段を説明しています。したがって、リリース計画には新しい画面状態の確認を加えつつ、すべての状態を独立したリリース門番にする必要はありません。Appleの案内とXcode 27.1の公開情報を、対象バージョンの根拠として記録してください。
まず、検収対象を混同しないことが重要です。画面のレイアウト確認はアプリの品質検証、CI自動化は繰り返し実行する回帰、App Storeのスクリーンショット準備は提出素材の作成です。素材がそろっていても、操作経路やレイアウトの合格を示す証拠にはなりません。素材の仕様はApp Store Connectのスクリーンショット要件で別に確認します。
アプリ担当者がサイズ変化に弱い画面を選ぶ
固定の画面寸法を前提にした配置、向きの固定、左右非対称のセーフエリア、自作ナビゲーションは、表示領域が変わると崩れやすい候補です。全画面を同じ深さで調べるのではなく、ログイン、主要な業務操作、メディア表示など、失敗時の影響が大きい画面から対象にします。
どの姿勢を優先して確認すればよいですか？
折りたたみと展開のうち、実際の機能やレイアウトが変わる状態を優先します。さらに、向きの変更が操作や表示に影響する画面だけを追加し、アプリで意味のない状態は対象外として理由を記録します。iPhone Duoの設計ガイドとAppleのレイアウト適応に関する技術講演は、画面構成を検討する際の参照資料になります。
プラットフォーム担当者が手動確認とCI自動化を分ける
Device Hubで行う姿勢の切り替えや画面の探索は、開発者が表示を確認する手動検査です。これに対し、CIの自動テストは、指定したシミュレーターとテストプランで同じ確認を再実行し、その結果をビルドにひも付ける仕組みです。Device Hubの公式資料で操作対象を確認し、AppleのiPhone Duo適応に関する技術講演も、シミュレーターでの確認範囲を把握する参考にできます。
Xcode 27.1のシミュレーターでは、どの界面問題を確認できますか？
姿勢や向きの変化に伴う表示、レイアウトの適応、主要画面の操作を確認する用途に使えます。ただし、シミュレーターを起動できたことや、Device Hubで手動確認したことだけでは、自動テストが通過した証拠になりません。Appleが公開するバージョン要件はXcode 27.1のリリースノートと照合してください。
QA担当者が代表状態を再現できる形にする
以下の表はAppleが定めた必須マトリクスではなく、チームが検収範囲を選ぶための案です。各行に対象画面、操作、期待結果を割り当て、アプリの機能とリスクに関係しない組み合わせは増やさないようにします。
| 確認手段 | 主な用途 | 合格証拠として残すもの | 単独では証明できないこと |
|---|---|---|---|
| Device Hubの手動姿勢確認 | 状態を切り替え、表示や操作を探索 | 状態、画面、指摘内容を含む記録 | CI自動テストの通過 |
| シミュレーター自動テスト | 重要操作を繰り返し回帰 | Xcode、対象シミュレーター、テスト結果 | 実機固有の挙動すべて |
| 実機確認 | リスクが残る表示・操作の確認 | 対象機器、手順、結果、証跡 | 対象外の機器や状態 |
| App Store素材確認 | 提出用画像の準備 | 素材と提出要件の照合結果 | アプリの機能・レイアウト試験 |
折りたたみと展開を自動回帰に含めるには、どう設計しますか？
状態を変えた後、重要な画面を表示し、主要操作と期待結果をテストケースにします。状態切り替えを自動化できないケースは、無理にCIの合格条件へ含めず、手動確認として担当者と証跡を明記します。自動化できる範囲は、CIで同じテストプランを再実行できるかをチーム環境で確かめてから門番に設定します。
QAとリリース担当者が放行証拠をそろえる
運用に移す前に、次の項目をチェックします。失敗時の停止条件と例外の扱いも決めておけば、手動確認の完了をCI合格と取り違えにくくなります。
- [ ] CIジョブが意図したXcode 27.1を使っていることをログで確認します。
- [ ] 対象のシミュレーターとテストプランをジョブ設定および実行結果に記録します。
- [ ] 代表的な折りたたみ・展開状態ごとに、対象画面、操作、期待結果を定義します。
- [ ] ビルド結果とテスト結果を、対象コミットや実行記録とひも付けて保存します。
- [ ] 手動のDevice Hub確認と自動テストを別の項目として記録します。
- [ ] 実機で補う必要のある画面や操作、担当者、実施条件を明示します。
- [ ] 失敗、未実施、例外を区別し、リリース停止または回帰のやり直し条件を定めます。
- [ ] App Store素材の準備状況を、機能テストの合否とは別に判定します。
自動テストが通っても、テストケースに含めていない姿勢や画面まで合格したことにはなりません。結果には検証した状態と対象画面を含め、未確認の範囲を残してください。
チーム横断で検収を運用に定着させる
新しい状態を加えた直後から全組み合わせを門番にすると、実際のリスクと無関係な検査まで増えるおそれがあります。一方、手動で一度表示しただけでは、変更後に同じ問題を検出できるとは限りません。まず代表状態を選び、繰り返す価値のある操作を自動化し、実機で確かめる必要性はリスクとチームの実測で判断します。
iPhone Duoシミュレーターの確認後も、実機での検収は必要ですか？
シミュレーターで確認できる範囲と、アプリの機能・表示リスクに照らして実機確認が必要な範囲を分けます。シミュレーターの合格だけから、すべての実機条件で問題がないとは判断できません。実機確認を省く場合も、その判断理由と対象外のリスクをリリース記録に残します。
CIの実行環境を見直す際は、既存のMacを継続利用する方法と、必要な期間だけリモートMacを用意する方法を比較してください。自社保有は調達・保守・稼働場所の調整が必要になり、共有機ではジョブの競合が起きることがあります。短期の検証環境や一時的な容量が必要なら、Macのリモートレンタルも候補です。RUVCLOUDの利用を検討する場合は、料金と利用条件および日本向けの申込み案内で実際の提供内容を確認し、対象のXcodeやシミュレーターが動くかは導入前に照合してください。恒常的な高負荷運用や物理機器への接続が欠かせない場合は、専有の実機環境を含めて比較するのが適切です。