mcpField
I
iphone-duo

iphone-duo

github.com/d-date開発4441 回インストール2 週間前に更新
リポジトリ

iphone-duo について

iphone-duoは、iPhoneアプリをiPhone Duoに対応させるための開発者向けスキルです。Appleの資料を基に、レイアウト、動作、テスト、移行を案内します。

主な機能

  1. 01適応レイアウトとサイズクラスの指針
  2. 02ディスプレイ、ヒンジ、マルチタスクの動作
  3. 03シミュレーターとサイズ変更のテスト指針
  4. 04移行チェックリストとAPI上の注意

活用シーン

  1. 01既存のiPhoneアプリをiPhone Duoに対応
  2. 02各デバイスポーズでのレイアウト確認
  3. 03ディスプレイ切り替え時の動作確認
  4. 04App Store提出に向けたアプリ準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/d-date/iphone-duo-skill --skill iphone-duo

インストール後、Claude Code で/iphone-duoを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
bars.md
camera.md
checklist.md
layout.md
scenes.md

詳細

iPhone Duo に合わせたアプリの適応

6 件の Apple Tech Talks、Human Interface Guidelines、Apple Developer Documentation、および 2 回の iPhone Duo Group Labs（2026-09-16 と 2026-09-17）を主な情報源とする実装ガイドです。

App Store Connect では、2026-10-05 から最適化されたアプリを受け付けます。2027-04 以降の提出では、iPhone Duo のスクリーンショットが必須です。

まずはこちら

iPhone Duo は iOS 27.1 とともに 2026-10-23 に発売されます。iPhone Duo に対応する SDK と Device Hub は Xcode 27.1 に含まれています（ベータ版は 2026-09-18 にリリースされ、Release Candidate は 2026-10-05 にリリースされます）。

iPhone Duo には、内側と外側の 2 つのディスプレイがあり、中央のヒンジを軸に開閉します。アプリは引き続き iPhone アプリです。開閉するとサイズが変更されます。専用のユーザーインターフェイスのイディオムはなく、電話として扱われます。新しい点は、内側のディスプレイで横方向と縦方向の両方にレギュラーサイズクラスが適用されることです。これは iPhone では初めてです。

内側のディスプレイでフルスクリーン表示しているアプリは、デバイスを閉じると外側のディスプレイに移動し、実行を続けます。バックグラウンドには入りません。例外は Split View です。2 つのアプリを横に並べている場合、最後に使用したアプリは外側のディスプレイに移動し、もう一方のアプリはバックグラウンドに入ります。すぐに再び開くと両方のアプリが戻ります。時間が経ってから開くと、外側のディスプレイに表示されていたアプリが内側のディスプレイ全体に表示されます。

基盤となるのは、サイズ変更に対応するレイアウトです。iPad や iPhone Mirroring でのサイズ変更に既に対応している場合、そのまま活用できます。

SDK ごとの動作
ビルドに使用する SDK動作
iOS 27 より前（Xcode 26）レターボックス表示で実行されます。外側のディスプレイでは、アスペクト比は iPhone mini に近く、縦向きのバー側に黒い帯が表示されます。内側のディスプレイでは、同じアスペクト比で中央に表示され、ポーズの変更には対応しません。
iOS 27サイズ変更への対応が有効になります（オプトアウト不可）。内側のディスプレイをほぼ全体的に使用しますが、ステータスバーの下の端に沿って黒い帯が残ります。
iOS 27.1ディスプレイの端まで広がり、標準のバーがステータスバーの下に縦向きに配置されます。

最初からすべてのポーズに合わせた体験を用意する必要はありません。Apple は、まずサイズ変更への対応を含め、ベストプラクティスに従ってアプリをリリースし、その後に体験を改善することを推奨しています。

Xcode 27.1 の Device Hub にある iPhone Duo シミュレータでテストしてください。ヒンジの角度を変更し、閉じた状態、開いた状態、本のように開いた状態、ラップトップのように開いた状態、テントのように開いた状態を選択できます。各ポーズだけでなく、ポーズ間の切り替えも確認してください。シミュレータは予約領域も返します。デバイスを途中まで折りたたみ、領域を描画して、折り目やカメラを避けるカスタムレイアウトを確認できます（references/layout.md の「シミュレータでのテスト」を参照）。カメラが必要なため、内側と外側のディスプレイが同時に点灯した状態をシミュレータで再現することはできません。iOS 27.1 のシミュレータでは、カメラを使用するアプリを起動できるようになりました。映像は表示されず、カメラが利用できないと報告されますが、UI の残りの部分は確認できます。

Device Hub の iOS サイズ変更可能シミュレータを使って、サイズ変更への対応を確認することもできます。iPad で実行してウインドウのサイズを変更するか、iPhone 専用アプリの場合は、macOS 27 の iPhone Mirroring を使って、縦横両方向に極端なサイズまで変更してください。ネイティブの体験全体をテストするには、iPhone Duo シミュレータが最適です。iPhone Mirroring は内側のディスプレイに近いアスペクト比を使用し、iPhone のインターフェイスのイディオムを維持します。多くの問題を再現できます。縦向きのバーによるセーフエリアとマージンの非対称性が原因の問題は、iPhone Duo シミュレータなしでは見つけにくくなります。

読むべきリファレンス

タスクに必要なリファレンスだけを読んでください。

リファレンス対象範囲
references/layout.mdサイズクラス、安全領域の非対称性、ディスプレイの角、予約領域、配置
references/bars.md縦方向のバー、項目の順序、軸の制御、バッジ、オーバーフロー、シート、縦方向のバーの無効化
references/scenes.mdヒンジ、マルチタスキング、Split View でのウインドウ位置、複数のウインドウ、シーンアクセサリ、カメラアクセサリ、Core Motion、Web
references/camera.mdデュアルフロントカメラ、カメラの向き、プレビュー、回転
references/checklist.md既存アプリの移行と検証、および App Store のチェックリスト

基本原則

これらの原則はすべての領域に当てはまります。判断をすばやく行うために、念頭に置いてください。

サイズクラスに基づいて判断してください。 ユーザーインターフェイスの種類から画面サイズやデバイスの機能を推測したり、UIDevice.current.orientation、statusBarOrientation、interfaceOrientation（windowScene.effectiveGeometry.interfaceOrientationを含む）に基づいてレイアウトを切り替えたりしないでください。境界の幅と高さを比較してレイアウトが縦長か横長かを判断し、bounds.height == 844のようなデバイスサイズの比較は削除してください。内側のディスプレイは、アプリが宣言した対応インターフェイスの向きに応じて回転せず、拡大縮小されます。向きを確認しても、意図した結果にはなりません。ポートレート専用アプリでも、内側のディスプレイではサイズクラスがregular/regularになります。現在の向きは環境またはトレイトから取得できますが、判断は利用可能な幅に基づいて行ってください。UIRequiresFullScreenなど、向きやサイズを固定する設定から移行することをおすすめします。

分岐によってビュー階層を再構築しないでください。 サイズクラスに応じて異なるコンテナを各分岐で使うSwiftUIコードは、分岐が切り替わると一方のビュー階層を破棄します。状態を親に移しておかない限り、状態は失われます。これはiPadのサイズ変更時にも起きていましたが、iPhone Duoではデバイスが内側のディスプレイ表示から閉じた状態になるたびに発生します。まず、たとえばArrangementViewを使うなどして、分岐そのものをなくすことを検討してください。

画面を直接参照しないでください。 2つのディスプレイを備えたデバイスではUIScreen.mainがどちらを指すのか曖昧であり、ドキュメントでもすでに非推奨です。環境、トレイトコレクション、シーンの境界を使用してください。画面が必要な場合は、window?.windowScene?.screenから取得してください。UIWindow(frame: UIScreen.main.bounds)はUIWindow(windowScene:)に置き換え、UIScreenを保持するのではなく動的に取得してください。起動時やviewIsAppearingで一度だけサイズを読み取らず、layoutSubviews／viewDidLayoutSubviewsでも再度読み取ってください。サイズ変更の処理はviewWillTransition(to:with:)に記述してください。ディスプレイのスケールにはdisplayScale／traitCollection.displayScaleで十分です。

フルブリードメディアの切り抜きを確認してください。 横長レイアウトで.scaleAspectFill／.aspectRatio(contentMode: .fill)によりコンテンツが切り抜かれるかを確認してください。サイズクラスやアスペクト比に応じてfillとfitを切り替えるか、焦点を指定してください。iOS 27.1 SDKでビルドしたアプリをリリースする前に、バーが縦方向になったときにコンテンツが適応することを確認してください。

安全領域は非対称になります。 反対側の端のインセットが等しいと想定するコードは正しく動作しません。view.bounds.width - insets.left * 2のような式は使わず、それぞれの端を個別に処理してください。レイアウトマージンとコンテンツインセットも非対称です。一方の端の値を反対側の端に使い回さず、システムから実際に提供される値を使用してください。

標準コンポーネントは多くの適応を自動的に処理します。 標準のナビゲーション、バー、シート、アラート、メニューは、デバイスの向きや折りたたみに適応します。折り目の回避もシステムが処理します。独自の代替コンポーネントを増やすほど、自分で対応すべき作業も増えます。 高レベルの API から始めましょう。 ヒンジ関連の API は、ヒンジ角度 → 予約領域 → 配置ビュー → システムコンポーネントという階層を形成しています。ヒンジ角度から自分でレイアウトを計算する前に、より上位のレイヤーで十分かどうかを検討してください。

これはスマートフォンです。 既存の iPad デザインはよい出発点ですが、そのまま持ち込まないでください。iPad 専用の要素は削除するか、デバイスの種類に応じて分けてください。同様に、iPhone Duo でしか動作しないアプリや、単一のポーズを前提とするアプリは作らないでください。ユーザーはこれを製品ラインの 1 つのモデルとして扱います。iPad アプリを移行する最初のステップは、ユニバーサルにして iPhone を対応プラットフォームに追加することです（Apple Vision Pro のような互換モードが存在するかどうかについては、明確な回答がありません）。

1 台のデバイスとして扱ってください。 開く操作は、アプリのウィンドウが横に広がるサイズ変更として設計してください。ユーザーはさまざまな持ち方や置き方をするため、特定のポーズを前提にしないでください。テーブルトップポーズでは、カメラ側または外側のディスプレイ側のどちらを下にしても、同じエクスペリエンスを提供する必要があります。ポーズに応じて UI を変更する場合は、スムーズに遷移をアニメーションできるかどうかを検討してください。

iOS 27.1 API について

2026-09-18 時点で、配置、予約領域、ヒンジ（UIKit）、縦型バーコントロール、カメラ方向コーディネーターなどの API に関するドキュメントが、iOS 27.1+ Beta として公開されていることを確認しています。これらの API は、正式リリース前に変更される可能性があります。

2026-09-18 時点で、このガイドで取り上げているすべての API の宣言がドキュメントに記載されていることを確認しています。

iOS 16 などの旧バージョンにも引き続き対応する場合は、iPhone Duo 固有のコードを利用可能性チェックで囲んでください。対応範囲はアプリによって異なります。新しい UI を別途構築して旧バージョンはそのまま維持する方法も、より細かい条件を使ってすべてのデバイスで同じ機能を提供し続ける方法もあります。

実装時には、Xcode のコード補完と実機またはシミュレーターで検証してください。

回答方法

説明、提案、検証結果はユーザーの言語で記述してください。API 名、型名、識別子、ソースタイトルは元の表記を維持してください。

このガイドは未公開 API を扱うため、検証できないシグネチャを作り出さないでください。 Xcode のコード補完または実機、シミュレーターで確認できない場合は、実装を提案する際にその旨を明記してください。もっともらしくても誤った表記を使うより、分からないと伝えるほうが適切です。

ソース

コメント

Markdown 対応