mcpField
I
iphone-duo-readiness

iphone-duo-readiness

github.com/mirzaaghazadeh開発250730 回インストール今日更新
リポジトリ

iphone-duo-readiness について

iphone-duo-readinessは、既存アプリをiPhone Duo向けに調整するiOS開発者向けスキルです。画面領域やセーフエリア、システムコンテナの前提を点検し、シミュレーター検証から専門スキルへの引き継ぎ、リリース準備まで案内します。

主な機能

  1. 01SDKとデプロイメントターゲットの対応段階確認
  2. 02方向・サイズ・インセットの固定前提の検出
  3. 03適応型システムコンテナとセーフエリアの利用
  4. 04シミュレーターとミラーリングで各ポーズを確認
  5. 05専門スキルへの作業振り分け

活用シーン

  1. 01既存アプリのiPhone Duo対応状況の評価
  2. 02折りたたみやSplit Viewでのレイアウト不具合の特定
  3. 03ツールバー、2ペイン、カメラの調整計画
  4. 04各ポーズのスクリーンショットとApp Store掲載の準備

インストール

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

$npx skills add https://github.com/mirzaaghazadeh/iphone-duo-skills --skill iphone-duo-readiness

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

詳細

iPhone Duo 向けに iOS アプリを準備する

iPhone Duo は Apple 初の折りたたみ式 iPhone です。縦横比が共通する 5.4 インチの外側ディスプレイと 7.6 インチの内側ディスプレイを備え、ユーザーはヒンジを任意の角度で止められます。既存の iPhone アプリは変更せずに動作しますが、何も考慮されていないアプリのように見えてしまいます。

このスキルは、そのための入口です。チェックリストに沿って作業し、アプリが実際に行うことに応じた専門スキルに引き継いでください。

まず押さえておくべき考え方

iPhone Duo は新しい操作様式ではありません。サイズの幅が広がるだけです。

この移植で起きるあらゆる問題は、アプリが何かを固定的に決めつけることから生じます。たとえば、このデバイスの操作様式、この向き、この画面、この幅、この左右対称のインセット、といったものです。解決策はすべて同じです。決めつけをやめ、今実際に利用できるスペースについて確認するようにします。

「iPhone Duo の場合」という分岐を書きそうになったら、いったん止めてください。代わりに、サイズクラスや利用可能なスペースに基づく分岐を書けば、iPad、Split View、iPhone ミラーリング、そして今後登場するデバイスでも正しく動作します。

手順 1 — 現状を把握する

SDK が対応状況を左右するため、まずアプリがどの SDK に対してビルドされているかを確認します。

ビルドに使用した SDKiPhone Duo での動作
iOS 26 SDK 以前動作しますが、適応しません。開くと、アプリは周囲に空白を残して中央に表示されます。閉じると、コンテンツはステータスバーとカメラの左側に表示されます。
iOS 27 SDK内側ディスプレイの大部分を埋めるようにサイズ変更されますが、右端のステータスバーは引き続き避けます。
iOS 27.1 SDK 以降ディスプレイ全体に広がり、ツールバーとタブバーはステータスバーの下に縦向きで配置されます。予約領域 API と配置 API が利用可能になります。

プロジェクトでデプロイメントターゲットと SDK を確認し、アプリがどの段階にあるのかを明確に伝えてください。27.1 の段階に到達することが、最も効果の大きい変更です。このスキルのほぼすべてが、それを前提としています。

27.1 の段階でリリースする前に、ひとつ注意点があります。この段階ではバーが縦向きになるため、リリース前にコンテンツがそれに適応することを確認してください。確認せずに段階を上げると、アプリのコントロールが自身のレイアウトに重なってしまうことがあります。

まずツールに初回チェックを任せる

Xcode にはアプリのサイズ変更対応スキルがあります(アプリのモダナイズスキルから名称が変わり、SwiftUI と iPhone Duo も対象になりました)。Xcode でコーディングアシスタントに iPhone Duo 向けにアプリを準備して と頼むと、手順 2 のパターンをスキャンして、それぞれを説明し、修正案を提示します。

Xcode のアシスタントを使っていませんか?スキルを書き出して、別のエージェントで使えます。

xcrun agent skills export

ほとんどの問題は検出できますが、すべてではありません。後から手作業でも手順 2 に沿って確認してください。

次に、実行中のアプリを確認する

再現性の高い順に、3 つのツールがあります。

  • Device Hub のiOS サイズ変更可能シミュレーター — 任意のサイズでレイアウトが崩れる箇所を見つける最速の方法です。
  • macOS 27 の iPhone ミラーリング — ウインドウのサイズを両方向に大きく変えてください。サイズのキャッシュに起因するバグの検出に役立ちます。
  • Xcode 27.1 の iPhone Duo シミュレーター — 実機に近い動作を確認できる唯一の方法です。開閉、回転、折りたたみを試し、ホームインジケーターを使ってアプリを片側にドラッグし、Split View も試してください。

この種のバグは見た目やデバイスの状態に左右されます。コードを読むだけでは見つかりません。

ステップ 2 — 固定された前提を探す

コードベースで次の項目を検索してください。どれも、このデバイスでは実際の不具合になります。

向きによる分岐。 UIDevice.current.orientation、statusBarOrientation、interfaceOrientation を検索します。windowScene.effectiveGeometry.interfaceOrientation も対象です。内側のディスプレイは サポートされているインターフェイスの向きを考慮しません。また、向きからアプリの表示領域の形状を判断することもできなくなっています。横長か縦長かを判断するには、実際に利用できる領域の幅と高さを比較してください。ビューコントローラーなら view.bounds、ビューなら superview.bounds、SwiftUI なら GeometryReader のサイズを使います。

UIScreen.main。 2 画面デバイスではどちらの画面か曖昧で、非推奨になる予定です。それぞれの使用箇所に適切な置き換え先があります。

代わりに使うもの使用するもの
UIScreen.main.boundsview.bounds / window.bounds。SwiftUI では GeometryReader または onGeometryChange
UIScreen.main.scaletraitCollection.displayScale、または @Environment(\.displayScale)
UIWindow(frame: UIScreen.main.bounds)UIWindow(windowScene:)
保存しておいた UIScreenview.window?.windowScene?.screen を必要なときに読み取る

サイズを一度だけ読み取ってキャッシュする。 これは見落としやすい項目です。起動時、あるいは viewIsAppearing でサイズを読み取るだけでは不十分です。折りたたみによって、セッション中にアプリのサイズが変わるからです。サイズに依存するレイアウトは layoutSubviews / viewDidLayoutSubviews で行い、サイズ変更そのものに合わせて実行する必要がある処理には viewWillTransition(to:with:) を使います。

「幅がレギュラーなら iPad」。 画面が目に見えて誤った表示になる可能性が最も高い落とし穴です。horizontalSizeClass == .regular のときに iPad 専用レイアウトを表示し、iPhone は常にコンパクトだと想定するアプリは数多くあります。内側のディスプレイは幅がレギュラーなので、その iPad 用レイアウトがスマートフォン上で実行されます。両方の方向を確認してください。レギュラーのときに実行される分岐と、コンパクトだと想定する分岐の両方です。関連事項として、bounds.height == 844 のような特定のデバイスサイズとの比較や、既知の iPhone の寸法一覧は削除してください。このデバイスにはどれも一致しません。

全画面表示のメディア。 .scaleAspectFill または .aspectRatio(contentMode: .fill) に設定されたヒーロー画像や動画は、幅の広いディスプレイでより大きく切り取られ、被写体が完全に見えなくなることがあります。現在のサイズクラスやアスペクト比に応じて、塗りつぶしと全体表示を選ぶか、焦点を設定してください。

左右対称のインセット計算。 これは見落としやすい項目です。iPhone Duo では、セーフエリアとレイアウトマージンが左右非対称になることがよくあります。縦向きのコントロールは片側だけに配置され、その側は端末の向きや Split View の配置によって変わります。bounds.width - safeAreaInsets.left * 2 のような計算は誤りです。インセットには一式すべてを使い、各辺の値を個別に反映させてください。

幅とブレークポイントのハードコード。 固定のポイント値、デバイス幅の一覧、「幅が 390 を超えたら」のようなしきい値です。2 つのサイズクラスを対象にしてください。外側のディスプレイでは幅がコンパクト、内側のディスプレイでは幅がレギュラーです。

独自実装のバー。 カスタムの UIToolbar、UINavigationBar、UITabBar は、システムの縦型バー用レイアウトでは認識されません。そのコンテンツはレイアウトに反映されません。

ステップ 3 — 標準のコンテナーを採用する

移植をうまく進める最も手軽な方法は、システムコンテナーにレイアウトを適応させることです。次のコンテナーは、すでに端末の向きに応じた調整に完全対応しています。

  • NavigationSplitView / UISplitViewController — 閉じた状態では列が 1 つのスタックにまとまり、開いた状態ではタイル状またはオーバーレイとして表示されます。
  • TabView / UITabBarController — あらゆる向きに適応し、適切な場合は縦方向に配置します。内側のディスプレイでは、タブバーの優先配置を .sidebar に設定することで、より機能豊富なサイドバーを利用できます。
  • NavigationStack、List、ScrollView — 確保された領域に自動的に適応します。
  • シート、アラート、メニュー、ポップオーバー、コンテキストメニュー — 折り目を避けて自動的に位置を調整します。

システムコンポーネントには折り目回避機能があり、操作要素が曲面領域に重ならないよう移動するため、ボタンが折り目に配置されることはありません。システムコンポーネントを使えばこの機能をそのまま利用でき、使わない場合は自分で実装する必要があります。

ステップ 4 — セーフエリアを正しく扱う

優先度の高い順に、4 つのルールがあります。

  1. バー状の UI には、コンテナが提供するバーを使います。これらはセーフエリアの外側に配置され、ステータスバー、Dynamic Island、カメラを自動的に避けます。横方向のバーは上端/下端のインセットに、縦方向のバーは先頭側/末尾側のインセットに反映されます。
  2. 操作可能で読みやすい前景コンテンツは、セーフエリア内に配置します。SwiftUI ではデフォルトでそうなります。UIKit では safeAreaInsets を参照するか、セーフエリアのレイアウトガイドに制約を設定します。
  3. 背景はセーフエリアを越えて広げます。SwiftUI では .ignoresSafeArea()、UIKit では view.bounds を使い、アートワークがバーやサイドバーの下まで広がるようにします。
  4. 各端を個別に処理し、Split View の左右両方でテストします。

システム UI とぶつからずにセーフエリアの外側に配置する必要があるカスタム UI には、iOS 27.1 で追加された ReservedRegion(SwiftUI)と UIViewReservedRegion(UIKit)を使います。インセットを推測するのではなく、これらを使ってください。

画面の角丸に合わせるには、iOS 26 の同心性 API を使います。SwiftUI では ConcentricRectangle、UIKit では UICornerConfiguration を使用します。これらは、このデバイスの形状に合わせて更新されています。

ステップ 5 — 専門ガイドを参照する

アプリに次の特徴がある場合…使用するもの
ツールバー、タブバー、オーバーフローメニューがあるiphone-duo-vertical-bars
カスタムレイアウト、分割表示に似たビュー、または折り目にかかるコンテンツがあるiphone-duo-adaptive-layout
ヒンジを活用したエフェクト、複数のウィンドウ、またはデュアルディスプレイ UI を使いたいiphone-duo-hinge-and-scenes
写真またはビデオを撮影するiphone-duo-camera
各ペインに配置する内容やアセットのサイズを決める必要がある、または 2 ペインのペイウォール/オンボーディングを構築するiphone-duo-dual-pane-patterns
コードの確認ではなく、デザインのレビューが必要iphone-duo-design-review

デバイスの数値は ../../reference/device-facts.md に、各 API 名とそのフレームワークは ../../reference/api-index.md に記載されています。

ステップ 6 — リリースする

アプリへの対応が作業の大半ですが、App Store 関連は忘れがちなうえ、手軽に対応できます。

  • スクリーンショットとプレビュー。 向きやポーズを変えてアプリを撮影し、製品ページで、スマートフォン向けレイアウトを横に引き伸ばしたものではなく、デバイス上で実際に動作している様子を見せましょう。必要なサイズについて、最新のスクリーンショット仕様を確認してください。
  • バッジ。 App Store Connect に iPhone Duo のスクリーンショットを提出すると、製品ページに、アプリが iPhone Duo 向けに最適化されていることを示すバッジが表示されます。これにより、スクリーンショットの作業は単にアートワークを改善するだけでなく、掲載ページ上で目に見えるアピールになります。このセクションで最も効果の高い項目です。
  • 公開前にプレビューする。 App Store Connect には、iPhone Duo でアセットがどのように表示されるかを確認するプレビューツールがあります。ぜひ使ってください。Xcode では問題なく見えるアセットでも、製品ページでは見づらくなることがあります。
  • 特集への推薦。 App Store Connect から推薦を申請できます。「Helpful Details」セクションでは、すべてのデバイスポーズに対応していることを含め、アプリが iPhone Duo 向けに最適化されていると記載できます。ここでは早めに対応することが重要です。発売時には最適化済みアプリがまだ少なく、まさにその時期に編集部が注目するからです。

報告内容

ユーザーに、現在の評価段階、file:line 形式で見つかった具体的な問題、評価段階が変わる条件を伝えてください。実行中のシミュレーターで確認する必要がある点については、正直に説明してください。ポーズによって変わるレイアウトのバグは静的には判定できません。判定できると主張しても、ユーザーの時間を無駄にするだけです。

正確性に関する注記

このリポジトリのシグネチャは、2026年9月25日にAppleが公開したAPIリファレンスと照合して確認済みです。そのため、Tech Talkのセッションから推測したものではなくなりました。確認の過程で3つの記述が誤っていることがわかり、修正しました。../../reference/api-index.mdの⚠マーカーを参照してください。

AppleのPrepareチェックリストもその後公開され、ここに反映されています。これにより、動画から推測した内容ではなく、文書化されたガイダンスがすべて揃いました。

ただし、まだ1つ注意点があり、重要です。ここにある内容は、実機に対してコンパイルも実行もされていません。特にポーズに依存するレイアウトの挙動はシミュレーターで確認する必要があるため、ドキュメントだけを根拠に検証済みだと報告しないでください。

コメント