iPhone Duoは本日予約開始、アプリ開発者はどれだけコードを変更する？折りたたみ対応の費用は？

Appleの予約告知ページは2026年10月付で公開されていますが、予約開始の告知だけでは、iPhone Duoの画面寸法や開発インターフェースまで確定したとは判断できません。Appleの予約告知を踏まえた今週の推奨は、全面改修の予算を先に取らず、既存画面とレイアウトの棚卸しから始めることです。折りたたみ対応は通常、アプリの書き直しを意味しません。画面サイズ変化への対応、レイアウト、状態保持、回帰テストを確認し、公式仕様を照合してから費用を算出してください。

この記事は、iPhone Duoへの対応範囲を見極めたいiOS開発者、改修の工数と予算を組み立てる技術責任者向けです。プロダクトマネージャーがリリース計画にテスト資源を含める際にも使えます。

最終更新：2026年10月。確認資料はAppleの予約告知、製品紹介、および開発者向けレイアウト・UIKit・SwiftUI文書です。製品紹介と各開発文書を参照し、未確認の端末仕様を見積もりの前提にはしていません。

折りたたみ対応の判断基準を先に決める

既存の画面が利用可能な領域に合わせて伸縮し、固定幅や固定位置に依存していないなら、まず必要なのはアプリ全体の再設計ではなく、画面変化時の挙動確認です。Appleのレイアウト設計ガイドも、画面領域に応じてコンテンツを構成する考え方を示しています。

一方、固定サイズを前提にした画面、複雑な独自ナビゲーション、入力途中の状態を保持しない画面は、個別の改修が必要になる可能性があります。画面の開閉に伴う正確な挙動や利用可能なAPIは、製品仕様と開発資料で確認できるまで前提に置かないでください。

自動レイアウト中心の画面：適応性の評価は高めです。サイズ変更時に制約が破綻しないかを確認します。
固定寸法や独自描画に依存する画面：リスク評価は高めです。実装箇所と表示条件をコード検索で特定します。
入力・処理中の状態を持つ画面：状態保持の評価は要確認です。画面遷移やアプリの中断・復帰後に入力内容が残るかを検証します。

これは端末の性能評価ではなく、改修の優先順位を付けるためのチーム内評価です。Appleのtrait環境の説明を使えば、画面環境に応じた条件分岐がどこにあるかを調べる手掛かりになります。

画面とコードの変更箇所をモジュール別に洗い出す

iPhone Duoの折りたたみ対応でApp開発者が確認する対象は、画面の見た目だけではありません。画面一覧と画面遷移を起点に、次の領域をコードレビューで追います。

画面レイアウト：固定幅・固定高・固定位置、画面端を前提にした配置を検索します。SwiftUIではGeometryReaderの仕様、UIKitではセーフエリアに対する配置を確認し、使える領域の変化で表示が崩れないかを見ます。
ウィンドウや画面サイズの変化：サイズ変更の通知やレイアウト更新処理があるか確認します。UIKitのUIWindowScene geometryに関する文書を参照し、アプリが取得できるシーン情報と実装を照合します。
ナビゲーションと複数作業の操作：戻る操作、画面切り替え、ダイアログ、キーボード表示時に、操作対象が隠れたり移動したりしないかを確認します。これは端末の未確認動作を決めつけず、既存UIの可変サイズ耐性を調べる作業です。
入力と状態復元：フォーム、編集中の内容、進行中の処理について、中断後にどこまで復元する設計かを確認します。AppleのUI状態保存の説明を、現行実装の照合資料として使えます。

注意：機種名だけから画面の開閉動作やアプリの再レイアウト条件を推測しないでください。Appleが公開した仕様と実機・シミュレーターで確認できた挙動を、見積もりの前提として記録します。

開発工数を左右する項目に証拠を結び付ける

見積もりを左右するのは、コード行数ではなく、修正対象の範囲と検証の難しさです。画面数は画面一覧、複雑なレイアウトの割合は画面ごとの実装方式、固定寸法の有無はコード検索、外部コンポーネントへの依存は依存関係一覧、テストの不足は既存の自動テスト結果で確かめます。

とくに、同じ画面数でも、共通コンポーネントで一括調整できる構成と、画面ごとに独自実装された構成では作業が異なります。自動テストが少ない場合は、実装の確認だけでなく、手動回帰テストの設計と実施も見積もりに加えてください。

評価の目安は、共通レイアウトを再利用できるなら「改修リスク低」、画面固有の固定寸法が複数あるなら「中〜高」、状態復元が不明で主要操作のテストもないなら「高」です。これは業界一律の工数ではありません。該当箇所、画面一覧、テスト記録を添えて、チームが判定を再現できる形にします。

改修費を人力・テスト・環境に分けて計算する

折りたたみ対応の開発費は、画面を数えて一律単価を掛けるだけでは算出できません。コード改修の費用は、各作業の見積もり時間に社内の人件費単価を掛けて積み上げます。単価や作業時間が未確定なら、金額を断定せず、前提を付けた見積もり幅として扱ってください。

調査：画面一覧の作成、レイアウト実装の確認、依存コンポーネントの調査。
改修：共通レイアウト、個別画面、状態保持、ナビゲーションの調整。
回帰テスト：画面サイズ変化、画面遷移、入力・復帰、主要業務フローの確認。
公開前検証：公式仕様との照合、対象OS・端末条件の確認、リリース判定の記録。

費用計算は「調査時間＋改修時間＋テスト時間＋公開前検証時間」に、各工程に対応する実際の人件費単価を適用します。遠隔のビルド環境やテスト環境を使う場合は、適応作業の人件費と混ぜず、利用条件に応じた環境費として別枠にしてください。VPSSparkの日本向け環境の案内で現行条件を確認し、必要な場合だけ見積もりに加えます。

必須テストと追加テストを切り分ける

テスト対象は、サイズが変わったときに画面が再配置されるかだけではありません。Appleの開発資料にあるシーン情報やセーフエリアの扱いを実装と照合し、画面切り替えやアプリ復帰後も操作と状態が保たれるかを確認します。

必須にしたいのは、主要業務フロー、フォーム入力、画面遷移、サイズ変化時のレイアウト、前面・背面の切り替え後の状態です。 製品仕様に折りたたみ状態に関する操作が明記された場合は、その条件をテストケースに追加します。仕様が未確認の段階では、開閉方法や表示サイズを仮定したテストを確定しないでください。

複数作業の表示、補助的な画面、利用頻度の低い導線は、製品の使い方とリスクに応じて追加します。画面ごとに「期待結果」「実施条件」「結果」「不具合時の担当」を残せば、テスト範囲と予算の対応をレビューできます。

見積もりを確定する前に確認する

次の項目を埋められない場合は、確定額ではなく暫定見積もりにします。担当者が確認できる資料と、未確定事項を一緒に残してください。

[ ] Appleの製品紹介と予約告知を確認し、確定済みの仕様と未公表の仕様を分けた。
[ ] アプリの画面一覧を作り、固定寸法・独自レイアウト・入力状態の有無を記録した。
[ ] 共通コンポーネントと外部依存をコードレビューで確認した。
[ ] 主要業務フローとサイズ変化、画面切り替え、前後の状態復元をテスト範囲に含めた。
[ ] 調査・改修・回帰テスト・公開前検証を分け、各工程の工数根拠を記録した。
[ ] 遠隔のビルド・テスト環境を使う場合、人件費とは別に現行の利用条件を確認した。

今の環境だけで進める場合、端末やビルド用Macの共用待ち、手元の構成への依存、テスト環境の準備・再現にかかる手間が制約になり得ます。反対に、継続的な高負荷利用や物理接続が必要なら、自社機材のほうが適する場合もあります。まず画面一覧とコードリスクで適応費を見積もり、遠隔環境が必要なときだけ環境費を分けて比較してください。短期のビルドや回帰テスト環境を確保したい場合は、VPSSparkの日本向け環境の条件を確認し、要件の相談は問い合わせ窓口で行えます。