Appleは2026年9月9日、初の折りたたみiPhoneとなる「iPhone Duo」を発表しました。予約注文は10月16日に開始され、10月23日に発売、iOS 27.1で動作します。奇妙なのはその順序です。Appleは同じ日にレイアウトルールを公開しましたが、Duoシミュレーターを含むSDKは「9月下旬」になってようやく提供される予定です。ドキュメントは存在するのに実機がほとんど存在しない、まさにこの期間こそ、アプリ内メッセージをはじめアプリの中に潜む「もう成り立たなくなったレイアウトの前提」を洗い出す好機です。
日本はiOSのシェアが高い市場であり、iPhoneの新しいフォームファクターの影響をユーザー体験に直接受けます。だからこそ、この対応は他市場以上に優先度が高いと言えます。
このガイドでは端末そのもののレビューは扱いません。それは他に無数の記事があるはずです。プッシュ通知そのものはシステムが描画するため、変更の必要はありません。対応が必要なのは、セッション中に画面の形状とアスペクト比が変化しても生き残らなければならない、アプリ自身が描画する部分です。つまりアプリ内メッセージ、リッチメディア、プッシュ通知の事前許諾画面(プライマー)、ローディング画面です。Appleが新しいルールを定めたのはまさにこの領域であり、多くのチームがここを素通りしようとしています。
折りたたみiPhoneでiOS 27が実際に変えたこと
iPhone Duoには、ほぼ同じアスペクト比を持つ2枚のディスプレイがあります。内側のディスプレイは7.6インチで、iPhone 18 Pro Maxよりも画面面積が約50%広くなります。外側のディスプレイは5.4インチで、iPhone 18 Proの画面面積の約90%です。比率は近いものの完全に一致するわけではないため、両方のディスプレイで成り立つと仮定した比率ではなく、サイズクラスからレイアウトを組み立てるべき理由がここにあります。
すべてのアプリがSplit Viewの対象になります。DuoはアプリのUIを複数インスタンス同時に実行する最初のiPhoneであり、あなたのアプリ内メッセージが他社アプリと並んで画面の半分に表示される可能性があるということです。
しかも、形状はセッションの途中で変化します。モーダルを表示している最中にユーザーが端末を開いたり、半開きにしたりします。レイアウトはもはや起動時に一度決めれば済むものではありません。
互換性の3段階と、多くのアプリが位置する場所
Appleのルールは明快です。アプリは再コンパイルなしでDuo上で動作します。問題は画面をどれだけ活用できるかで、それはどのSDKでビルドしたかによって決まります。
- 旧SDK: 動作はするが、コンテンツは電話サイズの領域に収まったままになる
- iOS 27 SDK: 内側ディスプレイのステータスバー領域より左までUIが拡張される
- iOS 27.1 SDK: UIが画面端まで届き、標準のナビゲーションバーとツールバーのボタンが縦方向に配置される
つまり、何もしないチームは、7.6インチのディスプレイ上でスマートフォンサイズの箱の中にアプリ内メッセージを表示し続けることになります。壊れているわけではありませんが、明らかに未対応であることが分かってしまい、対応を済ませた競合アプリと並んだときに見劣りします。
アプリ内メッセージのレイアウトが動かなくなる理由
理由は3つあり、それぞれが積み重なります。
アスペクト比。 多くのアプリ内メッセージやリッチメディアのテンプレートは、通常のiPhoneの比率に合わせてレイアウトされています。内側ディスプレイの比率はそれとは異なるため、旧来の比率を前提に作られたテンプレートは意図した位置に表示されません。
Orientationは正しい判断材料ではありません。 内側ディスプレイはどちらのサイズクラスでもregularであり、サポートされるインターフェース方向に従いません。orientationを基準に分岐するレイアウトロジックは、内側ディスプレイが無視している信号を読み取っていることになります。Appleの指示は明確で、レイアウトはorientationではなくサイズクラスから決定すべきとしています。
セーフエリアは非対称です。 Duoではインセットとレイアウトマージンが辺ごとに異なることが多いため、対称なフレームを前提にせず、各辺を個別に処理する必要があります。さらにSplit View下ではフレームが再び狭くなるので、そこでもテストしてください。
端末を開いた瞬間に表示されているアプリ内メッセージ
これはよく検討しておく価値のあるケースです。シミュレーターではまだ誰もこの挙動を確認できていないからです。モーダルのアプリ内メッセージが表示されている最中に、ユーザーが端末を開く。すでに表示されているビューの下で、フレームが変化します。
Appleはここで2つのツールを提供していますが、これらを混同するのがよくある失敗です。
ヒンジAPI(SwiftUIのonHingeChange、UIKitのUIHingeInteraction)は、離散的な状態(閉じている、部分的に開いている、完全に開いている)と連続的な角度をリアルタイムで報告します。これはインタラクションやエフェクトを駆動するために常時監視する用途を想定したものです。Appleのデモでも、折り曲げ角度を使って仮想楽器のピッチを変化させています。ヒンジAPIが担うのはその領域であり、ボタンの位置を動かすためのものではありません。
レイアウトはまったく別の経路を通ります。Appleが案内しているのは、「Strike a pose with adaptive layouts on iPhone Duo」セッションで紹介されている配置(arrangement)・領域(region)系のAPIです。ここでは reserved region、split/overlayレイアウトを持つ arrangement view、そして displacement(既存の要素を実際に使える空間へ再配置し、端末が閉じていく間もコンテンツを表示・操作可能な状態に保つ仕組み)が紹介されています。iOS 27.1では、SwiftUIにReservedRegion、UIKitにUIViewReservedRegionが追加され、独自のUIがシステムUIと衝突せずに必要な領域を確保できるようになりました。これらはreservedRegions(kind:)で取得でき、.divisionがヒンジそのもの、.occlusionがカメラ部分を表します。
モーダルについて言えば、結論はひとつです。ヒンジ角度を使ってモーダルを再配置してはいけません。arrangementとreserved regionに従わせることで、画面が開いたときにコンテンツは消えたフレームにしがみつくのではなく、本来あるべき位置に収まります。
Split View内でのアプリ内通知
すべてのアプリがマルチタスキングの対象になったことで、アプリ内通知が見知らぬアプリと並んで画面の半分に表示される可能性があります。これは内側ディスプレイ全体よりもかなり狭いフレームであり、半分の幅でテストすべき理由はまさにここにあります。フルスクリーンでは問題なく見えるモーダルも、表示領域が半分になると内容が切れたり詰まったりします。
もう一つ知っておくべき制約があります。外側ディスプレイでは新しいウィンドウを開けません。外側は内側の体験専用に確保されているためです。ウィンドウを生成するようなプレゼンテーションロジックは、この制約を考慮する必要があります。
外側ディスプレイ:コンパクトレイアウト、ウィジェット、Live Activities
外側ディスプレイは他のiPhone画面と同じように振る舞います。アプリはそこでも動作し、アプリ内メッセージを含め、アプリが描画するものはすべて表示されます。Appleの整理では、外側ディスプレイは通常のiPhoneと同じコンパクト幅のレイアウトであり、内側ディスプレイは両方向でregularです。5.4インチの外側ディスプレイは、この端末においてアプリ内メッセージが確保できる最小のフルスクリーンフレームであり、「対象外」として扱うのではなく、必ずテストマトリクスに含めるべき画面です。
さらにもう一つ、その上に重なる画面があります。Duoでは、充電していない状態でもStandByがどちらのディスプレイでも動作します。端末を置くと、外側の画面が点灯したまま部屋を向き続けます。ウィジェットもLive Activityも持たないアプリは、その瞬間には単純に存在しないことになります。そこでの存在感は、ロック画面やDynamic Islandのために既に行っているのと同じ作業、つまりウィジェットやLive Activityを通じて得られます。すでにLive Activitiesを実装済みであれば、その投資がもう一つの場所で報われるということです。まだであれば、これがもう一つの着手理由になります。
10月23日までに済ませておく折りたたみiPhone対応チェックリスト
端末そのものにはまだ触れられませんが、それ以外はすべて今から着手できます。
- アプリ内メッセージとリッチメディアのテンプレートを棚卸しする。 フレーム、アスペクト比、スマートフォンサイズの箱をハードコードしているものをすべて洗い出します。
- 16:9のクリエイティブを監査する。 固定アスペクト比で作られたものは、内側ディスプレイ向けの対応方針が必要です。
- orientationに依存した分岐を見つける。 インターフェースの向きを基準にしたレイアウトは、内側ディスプレイが無視している信号を読み取っています。サイズクラスに置き換えてください。
- セーフエリアの各辺を個別に確認する。 対称なインセットを前提にせず、非対称であることを想定してください。
UIScreen.mainをgrepで検索する。 2枚のディスプレイを持つ端末ではUIScreen.mainは曖昧になり、Appleは非推奨化を予告しています。画面はwindow?.windowScene?.screenから、スケールはtraitCollection.displayScaleから取得してください。- 折りたたんだ状態だけでなくコンパクト幅でもテストする。 外側ディスプレイはアプリ内メッセージが確保できる余白が最も少ない画面であり、実在するテスト対象です。
- Device Hubでのテストを準備しておく。 Xcode 27.1 betaがリリースされると、DuoシミュレーターはDevice Hubに追加されます。開く、閉じる、回転させる、メッセージを表示したまま半開きにする、という一連の操作を試してください。
- 端末モデルでセグメントを分ける。 Duoユーザーが実際に登場した後、個別にテストできるようターゲティングの手段を用意しておきます。
- プッシュ通知とオンボーディングの事前許諾画面の文言を見直す。 オンボーディング中に表示される許諾ダイアログ自体はシステムが描画しますが、その手前にある独自の事前許諾画面は、アプリ内メッセージと同じレイアウトルールを引き継ぎます。
どれも端末を必要としません。しかし、そのすべてを端末がユーザーの手に渡る前に済ませておく必要があります。
Duo対応を万全にしたアプリ内メッセージを届けましょう
アプリ内メッセージ、リッチメディア、プッシュ通知の事前許諾画面を、ユーザーが使うすべての画面ごとに手作業で直していくのは、6つの対応を個別に行うより、1つの統合基盤にまとめたほうが圧倒的に楽です。だからこそ、アプリ内メッセージとプッシュ通知を単一のカスタマーエンゲージメント基盤で運用する、というアプローチが有効です。PushwooshはSOC 2 Type I、ISO 27001:2022の認証を取得しており、情シス審査が必要な国内エンタープライズにも導入しやすい基盤です。10月23日までにDuo対応を終えたい方は、無料で始めるか、チームに相談するをご利用ください。
