iPhone Duo対応テストは今何をする？2026年リモートテスト準備チェックリスト

既存のビルドが起動することと、新しい画面形状を十分に活用できることは別です。iPhone Duoの仕様、設計上の考え方、スクリーンショット要件は公開情報を基準にし、未公開ツールの動作を宣伝資料から推測しない運用にします。

Xcode 27.1 beta、iPhone Duoシミュレーター、関連資料の提供時期について、Appleは2026年9月の後半に順次提供すると案内しています。したがって、2026年9月12日時点でシミュレーターの利用可否や具体的な姿勢操作を確定事項として扱うことはできません。AppleのXcodeシステム要件も、beta導入前に対象Macの対応条件を確認する資料として使います。

既存のiOSアプリは再コンパイルせずにiPhone Duoで動かせるか

旧SDKで作成した既存ビルドが互換動作する可能性はあります。しかし、それだけでは内外画面、非対称な安全領域、ウインドウ縮小、画面状態の復元を検証したことになりません。既存ビルドの起動確認は「互換性の確認」、Xcode 27.1での再ビルドと姿勢別試験は「対応テスト」として記録を分けます。

SwiftUIでは、画面の幅を固定値で分岐している箇所から確認します。UIScreenのサイズだけを判断材料にする処理、特定のデバイス名に依存する処理、左右が必ず対称になる前提、単一のsafe areaを想定した配置は、画面領域が変わると問題になりやすい箇所です。

優先する確認項目は次のとおりです。

• size classとコンテナのサイズを使って表示を決めているか
• NavigationSplitViewが狭い幅と広い幅で適切に遷移するか
• TabViewの項目数やラベルが縮小時に破綻しないか
• SheetとPopoverの表示位置が画面端に隠れないか
• 内画面、外画面、縦向き、横向き、分割表示を同じテスト手順で再現できるか
• 画面を閉じて戻ったとき、選択状態と入力内容が失われないか

SwiftUIの修正では、iPhone Duo専用の分岐を急いで追加しないことが重要です。まず親コンテナのサイズと環境値に応答するレイアウトへ直し、通常のiPhoneで既存の表示が変わっていないことを同じテストケースで確認します。

第一段階：SwiftUIの画面台帳を作る

画面名、入口、表示方向、主要な操作、依存するサイズ条件を台帳にします。プロジェクト名、Bundle ID、アカウント、ファイルパス、ログ内の利用者情報は、共有用の記録では必ず伏せます。

UIKitや独自UIでは、固定のframe、メイン画面のサイズを直接読む処理、独自ツールバー、safe areaを無視した配置を優先して検索します。これらは、表示領域が一つの長方形として安定している前提に依存しやすいためです。

traitCollectionの変化を受け取れるか、Auto Layoutの制約が動的な幅に耐えるか、UISplitViewControllerの表示モードが変わっても状態を保てるかを確認します。独自の画面遷移を使っている場合は、遷移中にサイズが変わったときのアニメーション、入力フォーカス、戻る操作を別ケースにします。

UIKitのページだけをiPhone Duo用に分岐すべきか

原則として、特定機種の判定を最初の解決策にしません。Auto Layout、trait、コンテナサイズ、分割表示に対応できるかを先に確認し、それでも新しいAPIが必要な箇所だけ、Appleが公開した資料と実際のSDK定義に基づいて追加します。

マルチシーンのアプリは、全画面の表示だけを見てはいけません。ウインドウを縮小した状態、並べて表示した状態、バックグラウンドから戻った状態を一つの試験群として登録します。シーン識別子、選択中の項目、未送信の入力、再表示後のスクロール位置を確認対象に含めます。

カメラ、動画、ゲーム、横向き中心のツールは、さらに別の境界を持ちます。表示領域の変化、回転、入力位置、カメラ権限、メディアの向き、ハードウェア能力を分けて記録します。ヒンジ状態、複数の表示領域、新しいカメラ能力については、公開済みのApple資料に記載された範囲だけを採用します。iPhone Duo設計ガイドにない動作を、製品紹介から補って実装仕様にしないでください。

担当別の判断分岐

次の条件で、作業場所と開始時期を決めます。

• SwiftUIで固定幅や画面名による分岐があるなら、今週は画面台帳とレイアウト修正を優先します。beta公開まで姿勢の合否は付けません。
• UIKitで固定frame、直接的な画面サイズ参照、独自遷移があるなら、UIKit担当が通常のiPhone回帰を併記して修正します。
• マルチシーン、カメラ、動画、ゲームがあるなら、一般的な画面確認から分離し、回転と状態復元の試験群を作ります。
• 安定したリリース用Macをbetaで更新できないなら、正式ビルド環境を変更せず、隔離したリモートMacを検証用に選びます。
• シミュレーターだけで公開可否を判断しようとしているなら、実機回帰ができるまで適応タスクを閉じません。

Xcode 27.1でiPhone Duoシミュレーターをいつ使えるか

2026年9月12日時点では、Appleが案内するXcode 27.1 betaと対応シミュレーターの公開を待つ段階です。公開後は、対応するmacOS、Macのアーキテクチャ、空き容量、既存のXcodeとの共存可否を確認してから導入します。提供前の具体的なインストール日やツールの挙動は確定情報として扱いません。

リモートMacでiPhone DuoのDevice Hubテストを実行できるか

現時点では、対応するXcode 27.1 betaとMacの要件を満たした環境で、実際にDevice Hubのデバイス一覧、姿勢操作、プロジェクト起動を検証してから判断します。Device Hubの公式ドキュメントとWWDC26のDevice Hub紹介は操作範囲の確認に使えますが、リモート接続時の画面転送や切断復旧まで保証する資料ではありません。

リモートMacでは、次の5層を別々に保存します。

1. ビルドログと警告。
2. シミュレーターの姿勢と表示状態。
3. 主要タスクの操作記録。
4. 画面キャプチャと素材ファイル。
5. 失敗時のログ、再現手順、復旧結果。

Xcode 27.1 betaを正式な打ち上げ環境へ直接入れる運用は避けます。署名、Archive、App Store Connectへのアップロードを担う環境と、iPhone Duo対応テストを担う環境を分ければ、betaの問題で安定版の公開手順まで止まるリスクを下げられます。Xcodeのシステム要件を確認し、検証用Macの更新可否を決めます。

App Store用素材は、コード修正とは別の担当表で管理します。AppleはiPhone Duo向けの内外画面に関するスクリーンショット仕様を公開していますが、App Store Connect側の素材アップロード対応は2026年後半に提供予定です。スクリーンショット仕様と更新記録を、アップロード前に再確認します。

iPhone Duoの内画面と外画面でApp Store用スクリーンショットを別々に用意するか

公開されている仕様に対象画面ごとの素材条件が示されている場合は、内画面と外画面を混ぜず、別のテンプレートと命名規則で準備します。ただし、アップロード入口が開く前に現行版の正式素材を置き換えるのは避けます。現在は作成、校正、脱敏、レビューまでを進め、実際の提出欄が利用可能になった時点で最終確認を行います。App Store Connectのアップロード手順も担当者に共有します。

スクリーンショットをAPIで管理するチームは、App Store Connect APIのスクリーンショット仕様も確認します。ファイル名、対象画面、ロケール、審査用ビルドを紐付け、開発用のプロジェクト名や利用者情報を素材に残さない運用にします。

1. SwiftUIとUIKitの画面を一覧化し、固定幅、safe area、直接的な画面サイズ参照を検索します。
2. NavigationSplitView、TabView、Sheet、Popover、UISplitViewController、独自遷移を担当者別に割り当てます。
3. 内外画面、縦横、縮小表示、並列表示、状態復元の期待結果をテストケース化します。
4. Xcode 27.1 beta用の隔離Mac、macOS条件、既存Xcodeとの共存方法を確認します。
5. Device Hubの一覧、姿勢制御、ビルドログ、画面キャプチャ、切断後の再実行を記録する場所を決めます。
6. App Store素材の内外画面テンプレートを作り、App Store Connectの入口が開くまでは正式素材を変更しません。
7. beta公開後にシミュレーターで検証し、実機入手後に重要タスク、回転、入力、カメラ、状態復元を再実行します。

リモート環境をまだ持っていない場合は、MESHLAUNCHのMac環境を検証用の選択肢として確認できます。常時稼働が不要で、beta公開後の短期検証だけを行うなら、購入とレンタルを同じ条件で比較します。既存の安定版ビルド環境を残したまま、別環境で新しいSDKを確認できるかが判断の中心です。

現在のMacをそのまま使うか、隔離したリモートMacを追加するかは、次の条件で決めます。

• Xcode 27.1 betaを正式版と分離して導入でき、問題が起きても公開作業を止めないなら、現在のMacで検証します。
• 同じMacが署名、Archive、TestFlight提出、beta検証をすべて担っているなら、リモートMacまたは別の検証機へ分離します。
• グラフィックセッションを維持でき、切断後にログとキャプチャを回収できるなら、リモートMacを短期検証に使えます。
• 物理カメラ、特定の入力機器、実機の表示品質が合否条件なら、リモートMacだけで完了させず、実機回帰を残します。
• 長期的に毎日重いビルドを実行し、物理接続が必要なら、レンタルだけでなく自社保有Macの費用と管理負担も比較します。

結論として、今すぐ行うのはレイアウトの柔軟化、リスク画面の分類、姿勢別ケース、beta用環境の分離です。Xcode 27.1とDevice Hubが公開された後にシミュレーター検証を行い、実機とApp Store Connectの受付条件が揃って初めて、iPhone Duo対応テストを完了扱いにします。

既存のMacだけで進める場合、正式ビルド環境をbetaで汚染しやすいこと、ストレージとシミュレーター環境を共有しやすいこと、担当者が変わると再現手順を失いやすいことが実際の負担になります。購入したMacを専用化する方法もありますが、Mac miniの導入条件を確認したうえで、短期の適応確認や一時的な並行運用ならMESHLAUNCHのリモートMacを隔離環境として使うほうが、安定版を残したまま検証しやすい場合があります。

まずは対象画面と未確認項目を整理し、Xcode 27.1 beta公開後に再現できる状態を作ってください。MESHLAUNCHのリモートMacは、常設の物理機が必要ない段階的なiPhone Duo対応テストや、正式環境と分けたシミュレーター検証の候補になります。