iPhone Duo適応はどう測る？2026企業CI受入れチェックリスト

複数のiOSアプリを管理し、iPhone Duo対応の合否基準を統一したい技術責任者向けです。シミュレーター回帰、UI自動化、実機試験を担当するQA・開発生産性チームにも適しています。

新しいMacノード、弾力的なレンタル、既存設備との混在構成を比較するIT・購買担当者は、最後の容量判断まで確認してください。

iPhone Duo対応では、すべての課題を「ビルド機不足」と扱わないことが重要です。アプリの画面適応、姿勢切替、シミュレーター回帰、実機挙動、App Store素材、正式リリースは、それぞれ必要な証拠が異なります。

Appleの設計資料と技術セッションは、外側の画面、内側の画面、展開・折りたたみ、回転などを前提に、レイアウトや画面遷移を確認する考え方を示しています。iPhone Duo向け技術セッションを基準資料にし、通常の縦横回転試験だけで合格扱いにしないでください。

判断表には、次の項目を必ず記録します。

外側・内側・展開状態ごとの棚卸し

開発チームの責任は、単にスクリーンショットを確認することではありません。ナビゲーション、モーダル、カメラ画面、シーン管理、カスタムレイアウトを、姿勢ごとに資産表へ登録します。

各高リスク画面には、次の情報を紐付けます。

• 対象画面と担当チーム
• 関連するコード位置
• 再現に必要な姿勢、状態、操作
• 既知の崩れと修正状況
• UIテストへ移行できる範囲
• QAへ渡す再現手順
• リリースを止める問題かどうか

ここでは「画面が表示された」だけでは不十分です。折りたたみから展開へ移った際に入力内容が保持されるか、ダイアログの位置が意図せず移動しないか、カメラや動画の状態が失われないかを別々に確認します。

Appleの設計更新は、iPhone Duo固有の画面構成を通常のiPhone対応と同一視しないための基準になります。Appleの設計更新資料をレビュー資料に添付し、設計上の問題とCI上の失敗を分けて管理します。

受入れ前に開発側が提出するもの

• [ ] 姿勢別の画面一覧を登録した
• [ ] 高リスク画面にコード位置と再現条件を付けた
• [ ] 状態保持、モーダル、カメラ、回転を個別に確認した
• [ ] 自動化できる試験と実機確認が必要な試験を分けた
• [ ] 未修正項目に阻断レベルと責任者を設定した

シミュレーターで先に回す範囲

シミュレーターは、決められた画面遷移、レイアウト、状態保持、基本的なUI操作を反復する用途に向いています。代表的なプロジェクトと最小姿勢回帰を先に実行し、全コミットで完全な姿勢マトリクスを走らせる設計は避けます。

一方、カメラの実挙動、性能の体感、物理的な開閉操作、センサーに依存する処理は、シミュレーターの成功だけでは合格にできません。Appleの関連技術資料も確認し、iPhone Duoの開発者向け技術セッションを試験設計の根拠として残します。

QAの結果には、試験姿勢、アプリ状態、期待結果、実際の結果、失敗画像、再現性、阻断レベルを記録します。実機がまだ用意できない場合は「未検証」と記載し、互換性確認済みとは表現しません。

iPhone Duoのシミュレーター試験だけで十分か

十分ではありません。シミュレーターは決定性の高いUI回帰を広く確認できますが、真機でしか確認できないカメラ、性能、センサー、開閉操作は別の証拠が必要です。

そのため、QAの合格状態を「シミュレーター合格」「真機未実施」「真機合格」のように分けます。未実施を合格へ繰り上げないことが、リリース判断の境界です。

Xcode 27.1の企業CIへの単独導入

Xcode 27.1は、公式ツールが利用可能になった時点で試験用ノードへ導入します。既存の安定版Xcode 27を使う本番ノードとは、Runnerタグ、ジョブキュー、作業ディレクトリ、キャッシュ、成果物の保管先を分けます。Xcodeのリリース記録とXcodeの新機能情報を、導入時のバージョン確認記録として保存してください。

実装手順は次の順番です。

1. 代表的なアプリを選び、対応するブランチと依存関係を固定します。
2. Xcode 27.1専用のMacノードを登録し、Runnerタグで対象ジョブを限定します。
3. 最小姿勢回帰、コンパイル、単体テスト、UIテストを別ジョブに分割します。
4. インストール状態、復元状態、キャッシュ、ログ保存を確認します。
5. 代表プロジェクトで失敗時の再実行とノード再構築を試します。
6. 建置時間、テスト時間、キュー待ち時間、失敗率、ディスク増加をCIログから収集します。
7. 証拠が揃うまで、正式アーカイブとApp Store公開ジョブを新ノードへ移しません。

AppleがXcode 27.1 betaや関連資料を段階的に提供している時期は、試験ノードを「正式リリース用」と呼ばないことが大切です。ツールチェーンの状態が変わったら、同じ代表プロジェクトを再実行し、前回との差分を残します。

CIプラットフォーム担当の受入れ項目

• [ ] Xcode 27とXcode 27.1のRunnerタグを分離した
• [ ] 代表プロジェクトの依存関係を固定した
• [ ] 姿勢回帰を最小セットから開始した
• [ ] ビルド、テスト、待ち時間、失敗率を原始ログで取得した
• [ ] ノード再構築後も同じジョブを再現できた
• [ ] 試験ノードから本番アーカイブを作らない制御を確認した

iPhone Duo対応の検証ノードは、正式アーカイブ、証明書、秘密鍵、App Store公開ノードから分離します。試験用ツールチェーンへ本番署名資産を渡さないことを初期条件にしてください。

ログ、内部依存、テストアカウント、ビルド成果物の保存範囲も確認します。ノードを破棄または再構築する場合は、キーチェーン、環境変数、キャッシュ、作業ディレクトリを消去した記録を残します。

App Store Connectには関連するスクリーンショット仕様が掲載されていますが、素材アップロード機能の提供時期は別途確認が必要です。App Store Connectのスクリーンショット仕様を参照し、現時点では再現可能な素材生成手順を準備します。正式なアップロード入口が使えると確認するまでは、提出済みとは扱いません。

• [ ] 試験ノードに本番秘密鍵を置いていない
• [ ] 正式アーカイブ用ノードとジョブを分離した
• [ ] テスト用アカウントの権限と有効期限を確認した
• [ ] ログと成果物の保持範囲を定義した
• [ ] ノード再構築後の資格情報消去を実行した
• [ ] 素材生成と正式アップロードを別の状態として記録した

新しい回帰ジョブを追加したからといって、直ちに固定ノードを購入する必要はありません。容量は開発者数ではなく、ジョブの発生頻度、ピーク時の待ち時間、1ジョブの占有時間、分離要件、障害時の代替経路で判断します。

安定して毎日発生する回帰負荷は固定ノードに向きます。対応初期の集中試験や短期のリリース前検証は、既存の本番ノードを汚染しないよう、隔離した遠隔Macの企業向け検証で実測する方法があります。長期にわたり高頻度で占有する場合や、物理機器、専用周辺機器が必要な場合は、自社保有の専用ノードを比較対象から外せません。

Macの調達地域や納期を比較する場合は、Mac miniの注文条件も確認対象になります。ただし、仕様表だけでCI容量を決めないでください。必要なのは、代表プロジェクトを同じ条件で走らせた建置記録、姿勢回帰の記録、キューの推移、ディスク消費、再構築結果です。

各担当から証拠を受け取った後、次の順番で判断します。

• [ ] 開発が姿勢別の互換性リスクを提出した
• [ ] QAがシミュレーターと真機の未検証範囲を分けた
• [ ] CI担当がXcode 27.1試験ノードのログを提出した
• [ ] 安全担当が署名・資格情報・成果物の境界を承認した
• [ ] IT担当が待ち時間とジョブ頻度を原始ログで提示した
• [ ] 購買担当が短期レンタルと固定増設の条件を分けた
• [ ] 否決条件、再評価日、責任者を文書化した

新形態の発表だけを根拠に増設するのではなく、まず隔離検証を行います。その後、実際の回帰頻度、ピーク待ち時間、1ジョブの占有時間が既存容量を継続的に圧迫する場合に限り、固定ノードまたは短期レンタルを選びます。

なお、企業のMac CI基盤で常時安定した高負荷を処理し、物理接続や専用管理が必要なら、遠隔Macレンタルが最適とは限りません。反対に、iPhone Duo対応のように期間と負荷がまだ確定していない段階では、購入による減価、保守、設置、余剰容量を先に抱えるより、隔離したMESHLAUNCHのMac環境で代表プロジェクトを実行し、実測データを取ってから固定設備へ進む方が判断を誤りにくくなります。

今週は、Xcode 27.1の独立ノード、姿勢回帰の最小セット、署名資産を持たない検証経路を用意してください。得られたキュー時間と試験頻度を使い、現状維持、短期レンタル、固定増設、混在構成のいずれかを再評価します。