iPhone Duoへのアプリ対応：実例でたどる準備と提出

iPhone Duoに向けてアプリをどう準備すればよいのでしょうか？ iOS 27.1 SDKでビルドし、シミュレータで全ポーズを一通り歩かせ、そこで見つかったものを直し、Appleがまだ発表していない2つの日付に合わせて提出の段取りを組みます。iPhone Duoは10月23日にiOS 27.1を載せて発売されます。¹ その上でアプリが何を受け取るかは、バイナリに刻まれたSDKバージョンで決まります。同じソースファイルを26.0、27.0、27.1としてリンクしたところ、それぞれiPhoneサイズの箱、ステータスレールの隣のウインドウ、そして画面全体（バーは側面に並び、折り目も報告される）として立ち上がりました。¹² 10月2日時点で27.1以降をスタンプできるのはAppleのベータだけ（Duoシミュレータを持つXcode 27.1 betaと、Xcode 27.2 beta）で、App Store Connectはそのビルドをストア向けではなくTestFlight向けとして受け付けます。⁸ この記事では、私たちがTestFlightで配布しているカードコレクター向けアプリKiradexで、作業を最初から最後までやり通します。何がタダで手に入ったか、コードを読んでも見つからなかったものを実際に歩かせて何が見つかったか、両ディスプレイ向けのスクリーンショット、そしてコーディングエージェントに渡せるブリーフまでです。

TL;DR

• SDKスタンプがスイッチです。 iOSはバイナリのLC_BUILD_VERSIONにあるSDKバージョンを読みます。27.1とスタンプされたプローブは画面全体を受け取りました。閉じた状態で466×678ポイント、開いた状態で951×669ポイントで、縦のバーと予約領域も付いてきます。27.0とスタンプされたものは、ステータスレールのある端の80ポイント手前で止まり、バーは横向きのまま、折り目については何も知らされませんでした。26.0とスタンプされたものは、箱に入った375×667のiPhoneでした。手元のビルドはotool -lで確認してください。¹²
• カレンダーには未定の日付が2つあります。 TestFlightは9月18日から27.1 SDKのビルドを、9月16日から27.2 betaのビルドを受け付けています。App Storeが受け付けるのは27.0 SDKのビルドだけです。Duoのスクリーンショットサイズは公開済みですが、アップロードは「will be available later this year」（今年後半に利用可能になる）とされています。⁸⁹ アップロード時にはローンチスクリーンのキーが必須になりました。¹⁰
• 大半はシステムのコンテナがやってくれました。 TabView、5つのタブのうち4つに入ったNavigationStack、タイトルとシンボルを持つツールバー項目。これだけで、Duo用のコードなしにKiradexのバーは側面に移りました。ArrangementViewひとつで開いたディスプレイが分割され、Bookのポーズでは仕切りが折り目の上に移動しました。onHingeChangeひとつで、端末を開いたときにアプリのオープニングが再生されます。¹³
• コードを読んでも分からなかったことを、歩かせると見つけました。 唯一のボタンがテキストの「Done」だけのシートは、側面のレールを確保したまま空にしてしまいます。フルスクリーンのカードは外側カメラの下に潜り込みます。ポートレートに回すと分割が上下に積まれます。折り目をまたいで開いたままのカードは、compactのレイアウトが引き伸ばされた状態で表示されます。内側ディスプレイ向けに書いたregular幅のレイアウトは、ランドスケープの6.9インチiPhoneで崩れます。¹³
• ストアが27.1を受け付けるまで、1つのソースツリーに2つのXcodeが要ります。 #availableでは解決しません。27.0 SDKにはコンパイル対象となるArrangementViewが存在しないからです。コンパイル条件のフラグか、#if canImport(SwiftUI, _version: 8.0.85)で新しい呼び出しを囲います。¹⁴
• スクリーンショットも同じ実行から出てきます。 シミュレータのキャプチャはApp Store Connectのサイズとぴったり同じで、AppleのDuo用ベゼルの開口部も同じサイズです。それでもAppleのルールは、正面から、無加工で、デバイスの3Dレンダリングは不可、と言っています。⁹¹¹

10月2日時点の状況

このうち3行はAppleの動き待ちですが、どれも作業を止めるものではありません。表から導かれる順番はこうです。アプリを27.1 SDKに載せてシミュレータに入れ、全ポーズを歩かせ、見つかったものを直し、そのビルドをTestFlightに置く。そしてストアへの提出とDuoのスクリーンショットは、それぞれが開く日に向けて準備したまま待機させます。

Apple自身の出発点は、6本あるTech Talkの1本目、10分の動画です。以下はすべて、これを見ている前提で進めます。

ステップ1：SDKスタンプが、端末から受け取るものを決める

トークは3段階の互換性の約束から始まります。iOS 27 SDKでビルドされていないアプリも動きます。「When the device is closed, your app will use the screen space to the left of the status bar and camera. When the device is open, your app will be a familiar size and aspect ratio.」（閉じているときはステータスバーとカメラの左側のスペースを使い、開いているときは見慣れたサイズとアスペクト比になる）（0:36）iOS 27 SDKを採用したアプリは「will extend to the left of the status bar area on the inner display.」（内側ディスプレイでステータスバー領域の左側まで広がる）（0:58）。そしてこう続きます。「When you build your app with the iOS 27.1 SDK, your app extends to the edge of the screen. Standard navigation and toolbar buttons now lay out vertically under the status bar.」（iOS 27.1 SDKでビルドすると画面の端まで広がり、標準のナビゲーションボタンとツールバーボタンはステータスバーの下に縦に並ぶ）（1:05）³

この3段階は、コードの性質ではありません。バイナリの中のたった1つの数字、つまりリンカがLC_BUILD_VERSIONロードコマンドに記録するSDKバージョンの性質であり、iOSは起動時にそれを読みます。この数字にどれだけのものが懸かっているかを確かめるため、小さなプローブを1つ作りました。5項目のツールバーを持つNavigationStackとArrangementViewを収めたTabViewです。これを同じソースファイルから3回ビルドしました。3つのバイナリの違いはその数字だけ、26.0、27.0、27.1です。そして3つすべてを、iPhone Duoシミュレータで全ポーズにわたって動かしました。¹²

1つのソースファイル、3つのSDKスタンプ、開いた状態で正立。左から26.0、27.0、27.1。

ウインドウサイズはポイント単位で、各ビルドのウインドウ自身が報告した値です。¹²

真ん中の列は2回読んでください。これから大半のアプリが出荷することになるのが、この列だからです。Xcode 27でビルドしたものは、内側ディスプレイでregular幅と画面の大部分を得ます。最初の列の「箱に入ったiPhone」に比べれば、本物の改善です。ただしステータスレールのあるtrailing側の端の80ポイント手前で止まり、縦のバーは得られず、システムは折り目のこともカメラのことも何も教えてくれません。予約領域への問い合わせは、どのポーズでも、プローブが何度尋ねても、すべて空で返ってきました。¹² スタンプが公平な代用になっているかを確かめるため、プローブの素朴な版をXcode 27.0そのもので、それ自身のiOS 27.0 SDKに対してコンパイルもしてみました。得られたウインドウは同じで、閉じた状態で386×678、開いた状態で871×669でした。¹²

この点について、Appleの文章のガイドはトークほど正確ではなく、しかも文言が変わっています。9月17日の時点で、概要にはこうありました。「Build your app with Xcode 27.1 or later to use all of the available screen space on iPhone Duo. In earlier versions, your app doesn’t extend under the status bar and camera.」（iPhone Duoで使える画面スペースをすべて使うにはXcode 27.1以降でビルドする。それより前のバージョンではステータスバーとカメラの下まで広がらない）9月19日には、10月2日の今と同じく、こう書かれていました。「Build your app with the latest version of Xcode to use all of the available screen space on iPhone Duo. When you build with Xcode 26 and earlier, your app doesn’t extend under the status bar and camera.」（最新バージョンのXcodeでビルドする。Xcode 26以前でビルドするとステータスバーとカメラの下まで広がらない）² 新しい文が足りないものとして名指ししているのはXcode 26以前だけで、「latest version」がベータを含むのかは書かれていません。そのため、読み手はXcode 27.0のビルドで画面全体が得られると受け取りかねません。このベータのシミュレータでは、そうはなりません。得られるのはトークの言う真ん中の段階で、以前の文言のほうが私の測定と一致していました。実機が別のことを示すまでは、表のとおりに計画してください。

ですから、何よりも先に、テストしているビルドのスタンプを確認しましょう。

otool -l Build/Products/Debug-iphonesimulator/YourApp.app/YourApp | grep -A4 LC_BUILD_VERSION

Xcodeのデバッグビルドは、コードを小さなランチャーの隣のYourApp.debug.dylibに置いており、どちらにもこのコマンドが入っています。探すのはsdk 27.1以降です。Xcode 27.2 betaのSDKが書き込むであろう27.2をスタンプしたプローブも、27.1と同じ扱いを受けました。¹² Kiradexのものはminos 27.0とsdk 27.1です。iOS 27.0にインストールでき、Duoでは27.1の挙動を得ます。¹³

ここを強調するのは、私自身が公の場で間違えたからです。9月21日のこのシミュレータについての最初のレポートで、私はツールバーが一度も縦にならず、予約領域はどのポーズでも空だったと書きました。ベータに問題はありませんでした。あのプローブはswiftc -sdkを直接呼んでコンパイルしており、リンクの段階で同じXcodeの中のmacOS SDKがルートとして使われ、バイナリは27.0とスタンプされて出ていきました。あの日に測ったものはすべて、真ん中の列だったのです。その記事には現在、訂正を載せています。¹² シミュレータでDuoのレイアウトが半分しか採用されていないように見えたら、つまり上部にバーが横切り、側面に死んだ黒い帯が走っていたら、コードを調べる前にスタンプを確認してください。

作業台のアプリ

Kiradexは、私たちがTestFlightで配布しているトレーディングカードのコレクター向けアプリです。すべてのセット、持っているカードと欲しいカード、その価値の推移、そして裏返して眺められる3Dオブジェクトとしての各カード。無料で、iPhone専用、iOS 27.0以降で動き、コレクターのリストは本人のiCloudに保存され、間に私たちのサーバーは挟まりません。¹³ 完成品ではありません。スキャナーは本物のカメラに一度も触れたことがなく、今週まで開いたDuoでこのアプリを見た人はいませんでした。内側ディスプレイのレイアウトの隣で、ロードマップには「Seen on the open Duo’s inner display only by the column maths; the simulator was folded shut.」（開いたDuoの内側ディスプレイは列の計算でしか確認していない。シミュレータは閉じたままだった）という一行が載っていました。¹³ だからこそ公平なテストになります。このアプリのDuo対応は、Appleのドキュメントをもとに書かれ、一度も画面で確かめられていなかったのです。

アプリがDuoのためにしていることはわずかです。そのうちDuo用のコードがどれほど少ないかを見るために、書き出しておく価値があります。

• ナビゲーションはシステムのもの。 5つのタブを持つTabViewで、うち1つは検索の役割。そのうち4つにNavigationStackが入っています。スキャナーは独自のバーを持たないカメラビューです。ツールバー項目はタイトルとシンボルを持つLabelで、.toolbarで付けています。独自のバーはどこにもありません。
• レイアウトはサイズクラスに従う。 compact幅では3列のバインダーページになり、カードのインスペクタはスタックにプッシュされます。regular幅は、iPhone専用アプリではほぼDuoの内側ディスプレイを意味しますが、偶数列のカードの壁になり、1枚を選ぶと画面がページとインスペクタに分かれます。
• 27.1 SDKの呼び出しは2つ。 分割は.splitスタイルのArrangementViewで、iOS 27.1未満ではHStackにフォールバックします。そしてonHingeChangeが、端末が閉じた状態からそれ以外の状態に移るときに、アプリのオープニングアニメーション（赤いデバイスが開いていく）を再生します。
• 向きのロックはなく、ローンチスクリーンはある。 Info.plistはポートレートと両方のランドスケープを挙げ、UILaunchScreenを宣言しています。¹³

これで全部です。2つのファイルに2つのavailabilityチェック。それ以外に端末がアプリにすることは、この方法でビルドしたどのアプリにも同じようにします。

この記事の画像は、アプリが参照している公開カタログのカード画像を使い、実際に動いている姿を写したものです。Kiradexは独立したコレクター向けツールで、Nintendo、Creatures Inc.、GAME FREAK inc.、The Pokémon Companyとは提携しておらず、承認も受けていません。カード画像の権利はそれぞれの権利者に帰属します。

ステップ2：全ポーズを歩かせる

Appleのガイドは、この確認を4つのチェックとして示しています。²

• 「Confirm your views resize well in each supported orientation and pose.」（サポートするそれぞれの向きとポーズで、ビューがうまくリサイズされることを確認する）
• 「Inspect how the system presents your app’s navigation bars, toolbars, and tab bars vertically on the side of the display.」（ナビゲーションバー、ツールバー、タブバーがディスプレイの側面に縦に表示される様子を点検する）
• 「Identify any views, sheets, or popovers that position awkwardly when you fold or open iPhone Duo.」（iPhone Duoを折りたたんだり開いたりしたときに、おかしな位置に来るビュー、シート、ポップオーバーを見つける）
• 「Identify elements or controls in your views that appear in the fold, and are difficult to see or interact with.」（折り目に掛かって見づらい、または操作しづらい要素やコントロールを見つける）

デザインガイダンスは、必要なレイアウトの数をこう示しています。「A compact width layout for the outer display and a regular width layout for the inner display give you the fundamentals for every pose.」（外側ディスプレイ用のcompact幅レイアウトと、内側ディスプレイ用のregular幅レイアウトがあれば、すべてのポーズの基礎がそろう）⁷

ポーズはDevice Hubのボタンで、Closed、Book、Open、Rotate Rightがあり、組み合わせごとに別の画面になります。SwiftLeeのガイドは、私には必要なかったもっと細かい操作を付け加えています。「Holding Option ⌥ reveals a slider that you can use to control the hinge angle of the device with precision」（Option ⌥を押し続けると、デバイスのヒンジ角度を精密に操作できるスライダーが現れる）¹⁷ アプリを見る前に、それぞれのポーズでシステムがどのアプリにも何を渡すのかを知っておくと役に立ちます。以下は27.1スタンプのプローブが読んだ値です。¹²

この表の3つの点が、その後のすべてを形作りました。

端末を折りたたんでもウインドウは変わりません。 BookとOpenは同じサイズを報告します。アプリから見える違いは、折り目のdivisionが非アクティブからアクティブに変わることと、ヒンジが完全に開いた180度から、部分的に開いた127度に変わることだけです。サイズしか読まないアプリは、端末が折りたたまれたことを知らずに終わります。

折り目は常にそこにあり、しかも小さい。 開いていても折りたたんでいても、ちょうど中央に報告され、APIが返すフレームはどちらの状態でも幅40ポイントで、両側に20ポイントのマージンがあります。Appleのトークは折り目の領域について「When flat, it’s inactive and has a width of zero.」（平らなときは非アクティブで、幅はゼロ）（7:32）と言っています。シミュレータは幅ゼロのフレームを返しません。Artem Novichkovのフィールドノートは同じ読み取りを「40 pt wide, with 20 pt margins on each side of a zero-width fold line,」（幅40pt、幅ゼロの折り目の線の両側に20ptのマージン）と書いており、¹⁷ 私もトークのゼロを、マージンに挟まれた線のことだと同じように読んでいます。これは私の読みであって、Appleの文章が言っていることではありません。トークは実用上の要点も示しています。「By default, only active ones will be returned, but you can query for inactive ones」（デフォルトではアクティブなものだけが返るが、非アクティブなものも問い合わせられる）、そして「in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state.」（グリッド状のレイアウトでは、divisionの領域があるなら、アクティブかどうかにかかわらず偶数列を選ぶとよい）（7:16、7:41）⁵

領域は遅れて届きます。 毎回の起動で、プローブの最初の数回の評価では領域がまったく読めず、それ以降の評価ではすべてそろって読めました。最初のレイアウトパスで一度だけ尋ねるビューは、空の配列をキャッシュしてしまいます。ビューのbodyの中で、評価のたびに読んでください。プローブは1秒ごとのタイマーで再評価させていました。Artem Novichkovのノートは、そのルールを端的に書いています。「Read them in the GeometryReader body so the view updates when they arrive. Don’t cache them.」（GeometryReaderのbodyで読めば、届いたときにビューが更新される。キャッシュしないこと）¹²¹⁷

アプリに入る前に、実用上の注意をひとつ。このベータのiOS 27.1シミュレータランタイムがサポートするデバイスタイプはiPhone Duoただ1つで、iPhone 18 Pro Maxを作ろうとすると「Incompatible device」で失敗します。そのため、以下の比較のうち、同じビルドを普通のiPhoneで動かしたものはiOS 27.0ランタイムで行いました。これは#availableのフォールバックが働くことを手早く確かめる方法にもなります。¹²

6.9インチiPhone、閉じたDuo、開いたDuoで動く1つのビルドのKiradex。アプリのコードには、バーを側面に置くものは何もありません。

歩かせて見つかったこと

UIテストがビルド5を、6つのポーズそれぞれで8種類の画面に連れて行き（閉じて回転させた状態では、Settingsボタンがオーバーフローメニューに移っていたので7種類）、スクリプトが各停止点で両方のディスプレイをキャプチャしました。外側は1398×2034ピクセル、内側は2853×2007ピクセルで、App Store Connectが挙げるサイズです。¹³ Appleの4つのチェックと照らし合わせると、アプリは予想以上に多くを通過し、コードをどう読んでも引っかからなかった箇所で失敗しました。

タダで手に入ったもの

バー。 閉じた状態では、ツールバーと5つのタブがすべて時計の下のレールに立ちます。開いても同じ。開いて回転させると、上部と下部に戻ります。アプリはそのどれも要求していません。2本目のトークは、手作りのバーが置き去りにされる理由を説明しています。「When used to build custom bars, content from sub-components like UIToolbar, UINavigationBar, or UITabBar won’t be considered.」（独自のバーを組むのに使った場合、UIToolbar、UINavigationBar、UITabBarといったサブコンポーネントの内容は考慮されない）（2:52）⁴ そしてメイン画面のツールバー項目はすべてLabelなので、どれもレール用のシンボルとオーバーフローメニュー用のタイトルを持っています。これがガイドのもう1つの条件です。「If your item has a title and doesn’t have an icon, the system doesn’t present it vertically.」（項目にタイトルがあってアイコンがない場合、システムはそれを縦に表示しない）²

折り目。 開いた状態では、セットのカードが横に6枚、偶数で並ぶので、画面の中央にカードが来ることはありません。1枚を選ぶと、画面はアプリのコンテンツ領域の中央、x 433でページとカードのインスペクタに分かれます。これは折り目より42ポイント左です。レールが右側から84ポイントを取っているからで、端末が平らな間は問題になりません。Bookのポーズでは、arrangementのビューが仕切りを折り目の上に移し、40ポイントの帯を空けておきます。x 433から始まっていたインスペクタは、495から始まるようになります。アプリにはBookのポーズのためのコードがまったくありません。これはトークが説明するとおり、ArrangementViewが「moving, resizing, or reorganizing what’s already there.」（すでにあるものを移動し、リサイズし、組み替える）（6:04）を行っているのです。⁵¹³

開いて平らな状態、続いてBookのポーズ。2枚目の隙間が折り目で、アプリが置いたものではありません。

開いた状態のシート。 内側ディスプレイでは、シートは中央に現れ、Doneボタンは横向きのままです。Bookのポーズでは、プローブのシートは自分から折り目のleading側に移動しました。¹²

イベントとしてのヒンジ。 アプリを動かしたまま端末を開くと、内側ディスプレイでオープニングがもう一度再生されます。閉じた赤いデバイスが開いていき、アプリへとつながります。ステータスがclosedから離れたときに発火するonHingeChangeハンドラ1つで実現しており、4本目のトークが求める役割分担そのものです。「Hinge data is observed live, and is ideal for driving interactions or effects. For layout, use the arrangement and region APIs.」（ヒンジのデータはリアルタイムで観測され、インタラクションやエフェクトを駆動するのに最適。レイアウトにはarrangementと領域のAPIを使う）（2:34）⁶

アプリを動かしたまま開いたところ。オープニングはアプリ自身が描いたアプリ自身のデバイスで、ヒンジがそれを再生します。

見落としていたもの

テキストのボタン1つだけのシートは、レールを確保して空のままにします。 閉じた状態では、Settingsシートはtrailing側の端の細長い領域を縦のバーのために明け渡し、そこに何も置きません。唯一のツールバー項目はタイトルだけでシンボルのない「Done」で、テキストだけの項目は横向きのままだからです。フォームは残りの幅に押し込められます。プローブはその損失を測りました。レールを確保した状態でコンテンツ幅374ポイント、縦のバーをオフにすると450ポイントです。¹² Appleのトークはまさにこのケースを挙げています。「if a sheet is control-heavy with only one item, like the close button here, consider disabling a vertical bar so it doesn’t reduce available space.」（シートがコントロール中心で、ここにある閉じるボタンのように項目が1つしかないなら、使えるスペースを減らさないよう縦のバーを無効にすることを検討する）（14:37）⁴ 直し方は2つあり、プローブで両方を試しました。ボタンにシンボルを与える、Button("Done", systemImage: "checkmark")。するとボタンは目立つチェックとしてレールに移ります。あるいはシートのコンテンツに.toolbarVerticalBehavior(.disabled)を付ける。するとレールは消えますが、引き換えにシートは短くなります。

左から、アプリのシート、続いてテキストだけのDoneのプローブ、シンボル付き、縦のバーを無効にしたもの。

フルスクリーンのカードがカメラの下に潜ります。 このアプリの見せ場は、バーを隠した黒いステージの上のカードで、そのステージはすべての辺でセーフエリアを無視しています。外側ディスプレイでは、これによってカードの上の角がカメラの下に入ります。システムは尋ねてきたどのビューにもそのカメラを37ポイント四方のアクティブなocclusionとして報告しており、その位置はApple自身のベゼル素材の切り欠きと1.5ポイント以内で一致します。¹¹¹² Appleのデザインガイダンスは全幅の扱いを「as long as nothing conflicts with the Dynamic Island or the status bar.」（Dynamic Islandやステータスバーと衝突しない限り）認めています。⁷ 直し方は、黒い地には全面の塗り足しを残し、カード自体は内側に収めることです。このディスプレイではステージにtrailing側と上側のセーフエリアを守らせるか、reservedRegions(kind: .occlusion)を読んで、返ってきたものを避けてカードを配置します。

外側ディスプレイ用のAppleのベゼルに収めたビューアのキャプチャ。シミュレータのスクリーンショットに穴はありませんが、端末にはあります。

回転させると、2つのペインが上下に積まれます。 開いてポートレートに回すと、ディスプレイの幅は669ポイントでなおregular幅なので、アプリは分割したままです。しかし、縦長のスペースを埋めるarrangementのビューは上下に分割します。Appleのガイドによれば「it places the primary view on top and the secondary view below it when the containing view is taller than it is wide.」（コンテナのビューが幅より高さのほうが大きいとき、プライマリビューを上に、セカンダリビューをその下に置く）です。² 結果として、インスペクタの上に、カード1行と2行目の上端だけを見せる細い帯ができます。その行に付いたアプリ自身のコメントは、このペアは「is only useful side by side,」（左右に並べたときにしか役に立たない）と書いていますが、それを強制するものは何もありませんでした。.split.axes(.horizontal)でスタイルを制限するのがドキュメントに書かれた制御方法で、¹⁶ トークが説明する落とし穴があります。「If the split arrangement cannot split among an axis, and it’s the primary axis, the arrangement view chooses to only show a single view.」（split arrangementがある軸に沿って分割できず、それが主軸である場合、arrangementのビューは1つのビューだけを表示することを選ぶ）（12:44）⁵ プローブは両方を裏付けました。回転させたディスプレイを埋めると、素のsplitは上下に積まれ、横方向限定のsplitはプライマリのペインだけを表示して、ほかには何も出しませんでした。¹² このアプリではインスペクタが隠れてしまうので、誠実な修正はモディファイアではなく判断です。スペースが幅より高さのほうが大きいときは、compactのレイアウトと同じようにインスペクタをプッシュします。

回転させた状態。Appleのガイダンスどおりバーは横向きで、分割はこのビューのペアにとって間違った方向に進みました。

折り目をまたいで持ち越したカードは、どちらのレイアウトにも収まりません。 閉じた状態でカードを選ぶと、そのインスペクタがナビゲーションスタックにプッシュされます。インスペクタを表示したまま開くと、カードはまだそこにあります。ここは間違えやすい部分です。しかしそれは依然としてプッシュされた画面で、いまや幅951ポイントです。左にステージ、黒の上を漂う白い箱の中に詳細、レールには戻るボタン。このディスプレイ向けのアプリのデザインは、カードの壁とその隣のカードであり、そこへ行く唯一の方法は、戻ってカードを選び直すことです。1つの選択状態が両方のレイアウトを動かしていても、ナビゲーションのパスは1つではありません。直し方は、カードを選んだままcompactからregular幅に変わったことを検知し、プッシュされた画面をポップして、分割に引き継がせることです。

開く前と開いた後の同じカード。状態は残りましたが、レイアウトはcompactのものが引き伸ばされています。

regular幅は「Duo」ではありません。 このアプリはregular幅を内側ディスプレイとして扱います。壁、偶数列、分割です。横向きの6.9インチiPhoneもregular幅で、高さはcompactです。そしてこのアプリは向きをロックしていません。そこで動かすと、同じ分岐が、左端から内側に寄ったページ、カード名が収まらないほど狭い詳細列を持つインスペクタ、画面の下端で切れたアクションボタンを生み出します。これはiOS 27で新しく生じたことではなく、私が動かしたどのDuoのポーズでも出てきませんでした。Duo対応の作業がこれを見つけたのは、regular幅を報告するすべての画面でregular幅のレイアウトを誰かが歩かせたのが、これが初めてだったからです。両者を区別するのは、もう一方のサイズクラスです。内側ディスプレイは両方向ともregularで、Appleのトークは、横向きにした外側ディスプレイを両方向ともcompactとしています。³ 2方向にスペースを必要とするレイアウトは、両方を尋ねるべきです。

Duoではない端末でのregular幅のレイアウト。横向きの6.9インチiPhone、iOS 27.0。

キーボードがレールを覆います。 外側ディスプレイでキーボードを出すと、レールの下部にあるタブがその裏に隠れます。これはシステムのレイアウトであって欠陥ではありません。トークは、バーが「as other competing UI appears, like the keyboard」（キーボードのように競合する別のUIが現れるにつれて）オーバーフローする必要があるかもしれないと言っています（11:50）。⁴ それでもこのリストに載っているのは、ツールを壊したからです。私の最初のツアーは検索キーボードを出したまま「Collection」をタップし、そのタップはPのキーに着地しました。タブバーに常に手が届くと仮定したUIテストは、ここで真っ先に失敗します。

小さなことが2つ。このアプリは偶数列を幅のサイズクラスから選んでいますが、トークの提案は、折り目自身の領域があるかどうかで決めることです。もう1つは折りたたみとは関係ありません。6.9インチのシミュレータでフルスクリーンのビューアを4回続けて開くと、1回目はカードが表示され、残りの3回は真っ黒な画面でした。どちらもTestFlightのビルドを止めるものではありません。どちらも、アプリを画面に載せて何かが順番にボタンを押していくまでは見えませんでした。

シミュレータでは見せられなかったもの

スキャナーです。背面の広角カメラを開き、すでにローテーションコーディネーターを使っています。これはカメラのトークが求めることで、「On iPhone Duo, the rotation coordinator will update when your app moves displays.」（iPhone Duoでは、アプリがディスプレイを移ると、ローテーションコーディネーターが更新される）（8:19）とあります。⁶ セッションが一方のディスプレイからもう一方への移動を生き延びるかどうかは、実機で確かめるしかありません。シミュレータにはカメラがまったくないからです。Appleのリリースノートは、このランタイムで動かせないものとしてStandByと大半のアプリ拡張を加えており、Xcode 27.2 beta 2のノートは、キャプチャを自動化する人に向けて1つ加えています。「Screenshots and recordings in iPhone Duo may be black for up to a few minutes after booting the device.」（iPhone Duoのスクリーンショットと録画は、デバイスの起動後数分まで黒くなることがある）²⁰

1つのソースツリー、2つのXcode

カレンダーが問題を生みます。ストアが受け付けるビルドはXcode 27と27.0 SDKから作られ、iPhone Duoで正しく振る舞うビルドは27.1 SDKから作られます。Appleがストアを後者に開放するまでは、アップデートを出荷しつつDuoのレイアウト作業も続けたいアプリは、両方でコンパイルできなければなりません。

if #available(iOS 27.1, *)ではそこに届きません。availabilityは実行時の問題であって、コンパイラはそれでもシンボルを見つけなければならないからです。Kiradexは2つのDuo呼び出しをまさにその方法で包んでおり、デプロイメントターゲットは27.0なので、ビルドはまだアップデートしていない端末にもインストールできます。27.1 SDKではこれでコンパイルが通ります。Xcode 27.0では、同じことをするファイルはerror: cannot find 'ArrangementView' in scopeで止まります。27.0 SDKにはそのような型がないからです。¹⁴ Kiradexはまだストアに出ていないので、ベータのツールチェーンに留まっていれば済みます。顧客を抱えるアプリはそうはいきません。

Swiftのドキュメントにある条件でも、2つのSDKは区別できません。#if compiler(>=6.4)はどちらでも真になります。Xcode 27.0、Xcode 27.1 beta、Xcode 27.2 betaは、どれも同じApple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1)を出力します。¹⁴ 残る囲い方は2つで、私は両方を試しました。

自分で設定するコンパイル条件。 こちらがドキュメントに沿ったやり方です。ベータでビルドする構成にだけフラグを定義し（XcodeではSWIFT_ACTIVE_COMPILATION_CONDITIONS = DUO_SDK、コマンドラインでは-D DUO_SDK）、27.1専用のコードをそれで囲います。

struct Pair<Primary: View, Secondary: View>: View {
    @ViewBuilder var primary: Primary
    @ViewBuilder var secondary: Secondary

    var body: some View {
        #if DUO_SDK
        if #available(iOS 27.1, *) {
            ArrangementView { primary } secondary: { secondary }
                .arrangementViewStyle(.split)
        } else {
            HStack(spacing: 0) { primary; secondary }
        }
        #else
        HStack(spacing: 0) { primary; secondary }
        #endif
    }
}

フラグなしなら、このファイルはXcode 27.0でも27.1 betaでも型チェックを通ります。フラグありなら、ベータでは通り、27.0では同じシンボル欠如のエラーで失敗します。間違った組み合わせはビルドできないということです。¹⁴

コンパイラが読む、SDK自身のバージョン。 canImportは、モジュールのバージョンと比較するアンダースコア付きの第2引数を取ります。そしてSwiftUIのモジュールバージョンはSDKごとに異なります。27.0 SDKでは8.0.84.1.104、27.1 SDKでは8.0.85.27、27.2 beta SDKでは8.1.6.1.101です。¹⁴ ですから、これにはビルド設定が要りません。

#if canImport(SwiftUI, _version: 8.0.85)
// ArrangementView, reservedRegions, onHingeChange, toolbarVerticalBehavior
#else
// what the app did before
#endif

それぞれの分岐に#warningを入れ、3つのXcodeすべてでコンパイルしてみました。27.0は2つ目の分岐を、27.1 betaと27.2 betaは1つ目の分岐を通りました。¹⁴ 注意点はアンダースコアにあります。Swiftのブックにあるこの条件の文法はcanImport(import-path)だけで、それ以上ではありません。つまり_version:はドキュメント化された契約のないコンパイラ機能で、8.0.85という数字は私が2つのSDKから読み取ったものであって、Appleが公表したものではありません。¹⁴ ストアが27.1に閉じている間、ビルド設定が自分の環境で扱いにくいならこれを使い、説明責任を果たせるものが欲しいならフラグを使ってください。

どちらにしても、この囲いは一時的なものです。27.1 SDKを搭載したXcodeのビルドをApp Store Connectが受け付ける日が来たら、囲いを削除し、#availableのチェックは残してください。iOS 27.0のままの端末を守るのはそちらです。

提出：App Store Connectが今日受け付けるもの

TestFlightは27.1のビルドを受け付けます。 App Store Connectの9月18日のリリースノートにはこうあります。「You can now submit apps built with Xcode 27.1 beta using the SDK for iOS 27.1 beta or iPadOS 27.1 beta for internal and external testing.」（iOS 27.1 betaまたはiPadOS 27.1 betaのSDKを使いXcode 27.1 betaでビルドしたアプリを、内部・外部テスト用に提出できるようになった）9月16日と9月28日のエントリは、Xcode 27.2 betaとbeta 2について同じことを述べています。⁸ Kiradexはこの経路でアップロードしています。この記事でテストしている5つ目のビルドは10月2日にアップロードされ、App Store Connectは有効なものとして表示しています。¹³

App Storeは、まだ受け付けません。 ストアを開放した最新のエントリは9月14日のものです。「You can now upload apps built with Xcode 27 using the SDK for iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, and watchOS 27.0 for the App Store, and for internal and external testing through TestFlight.」（iOS 27.0などのSDKを使いXcode 27でビルドしたアプリを、App Store向けに、またTestFlightでの内部・外部テスト向けにアップロードできるようになった）⁸ それ以降のエントリで、27.1とストアを同じ文の中で挙げているものはありません。最新の項目が9月28日付けのAppleのReleasesフィードに載っているXcode 27.1のビルドは、9月18日のベータ1つだけです。⁸ これがいつ変わるのか、Appleは言っていません。端末は10月23日に発売されます。¹

10月23日より前にAppleがストアを27.1 SDKに開放しない限り、発売日に顧客の手元にあるストアのビルドは、よくても27.0 SDKのビルドです。それがシミュレータで何を得るかは上の比較が示しており、Appleのトークも同じ真ん中の段階を説明しています。ステータスレールの隣の画面、横向きのバー、折り目なし。うまくリサイズできるなら使えるアプリです。だからこそ、リサイズの作業はいまXcode 27で出荷すべきだ、ということになります。

ローンチスクリーンが必須になりました。 Duoのルールではありませんが、同じSDKとともにやってきて、審査ではなくアップロードの時点で失敗します。Appleのテクニカルノートにはこうあります。「Starting in iOS 27 and iPadOS 27, App Store Connect requires your app to include a launch screen configuration in its Info.plist,」（iOS 27とiPadOS 27から、App Store ConnectはアプリのInfo.plistにローンチスクリーンの構成を含めることを求める）そしてUILaunchStoryboardName、UILaunchStoryboards、UILaunchScreen、UILaunchScreensのいずれもなければ、アップロードは「ITMS-90870: Missing launch screen.」で拒否されます。¹⁰ KiradexはUILaunchScreenを、表紙の赤という色付きで宣言しているので、起動からそのままオープニングアニメーションにつながります。¹³

スクリーンショットの枠は、書類の上では存在します。 App Store Connectのスクリーンショット仕様は9月9日からiPhone Duoを2組で挙げています。外側ディスプレイ用に1398×2034または2034×1398ピクセル、内側用に2007×2853または2853×2007ピクセルで、「Support for uploading assets for this device in App Store Connect will be available later this year.」（App Store Connectでこのデバイス用のアセットをアップロードするサポートは今年後半に提供される）という注記付きです。⁹ いつものルールも適用されます。「You can upload one to 10 screenshots in .jpeg, .jpg, and .png formats,」（.jpeg、.jpg、.png形式で1枚から10枚のスクリーンショットをアップロードできる）そして「Images can’t include alpha channels or transparencies.」（画像にアルファチャンネルや透明部分を含めてはならない）⁹

アップロードのページにある1文が、これにどう備えるかを決めます。「Once your app is submitted for review and approved, you must create a new version to update the screenshots.」（アプリが審査に提出されて承認されたら、スクリーンショットを更新するには新しいバージョンを作らなければならない）⁹ Duoのスクリーンショットは、あとから単独で差し込むことができません。枠が開いたら、それはバージョンに載って出ていきます。

まとめると、私が回すであろう段取り、そしてKiradexで実際に回している段取りはこうです。

1. いますぐ27.1のビルドをTestFlightに置き、歩かせて見つかったことを見つかり次第直す。
2. すでにストアにあるアプリなら、27.1 SDKを必要としない修正をすべて載せた、Xcode 27でビルドしたアップデートを出す。idiomや向きのチェックではなくサイズクラス、辺ごとのセーフエリア、システムのコンテナが持つバー、すべてのツールバー項目にタイトルとシンボル。
3. Duoのサイズのスクリーンショットをいまシミュレータからキャプチャし、保管しておく。
4. 2つのことが真になる日に向けて、バージョンを準備して待機させる。27.1 SDKを持つXcodeがストア向けに受け付けられること、そしてDuoの枠がアップロードを受け付けること。この種の変更をAppleはこれまでいずれもApp Store Connectのリリースノートに掲載してきました。Xcode 27のリリースにストアを開放した9月14日のエントリや、Duoのスクリーンショット仕様を追加した9月9日のエントリもそうです。ですから見張るべきはそのページで、その隣にdeveloper newsのページを置いておきます。⁸

もう1つの要件が、もう少し先にあります。2027年4月からは、そもそもアップロードするために「iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later」（iOSとiPadOSのアプリはiOS 27とiPadOS 27のSDK以降でビルドしなければならない）とされています。¹⁸ iOS 26 SDKでビルドしたままのアプリは、Duoでは上の3つのうち最も小さい姿になり、2027年4月からはiOS 27 SDKに移るまでアップデートをアップロードできません。

2つのディスプレイのためのスクリーンショット

素材は歩かせる作業がすでに生み出しています。どの停止点も1398×2034と2853×2007ピクセルで、回転させた状態は2034×1398と2007×2853ピクセルでキャプチャされており、App Store ConnectのiPhone Duoの行にある4つのサイズすべてがそろっています。⁹¹³ 残るのはその周りに何を置くかを決めることで、そこで折りたたみ端末は失敗を誘います。

誰もが欲しがる絵は、端末が斜めに半分開き、アプリが折り目を越えてあふれ出しているものです。Appleのマーケティングガイドラインは、それを1行ずつ禁じています。Apple自身のデバイス画像については「Use Apple product images ‘as is’ and without modification. Modifications include adding reflections, shadows, highlights, or graphic elements that appear to enter or come out of the product screen; cropping, tilting, or obstructing any part of the images; animating, flipping, or spinning the images」（Apple製品の画像は「そのまま」無加工で使うこと。加工には、反射、影、ハイライト、製品の画面に出入りするように見えるグラフィック要素の追加、画像の切り抜き、傾け、一部を隠すこと、アニメーション化、反転、回転が含まれる）。自分で作る画像については「Straight-on product shots are preferred. Don’t use extreme angles or alter an Apple product in any way.」（正面からの製品写真が望ましい。極端な角度を使ったり、Apple製品に手を加えたりしないこと）。そしてUnauthorized Usesの項の筆頭には「Rendering in 3D or creating any simulation of an Apple product」（Apple製品を3Dでレンダリングすること、あるいはいかなるシミュレーションを作ること）とあります。¹¹ 私のスクリーンショットの記事では、受賞作がこれらのルールをどう扱っているか、ルールを守ったセットがどう見えるかを詳しく見ています。ヒンジがあっても、それは何も変わりません。

その代わりにAppleがくれるのが、この端末用のベゼルパックです。2つの仕上げと5つのビューがあります。ポートレートとランドスケープの閉じた端末、ランドスケープとポートレートの開いた内側ディスプレイ、そしてカメラの隣に外側ディスプレイが見える、背面から見た開いた端末です。これらのファイルの開口部はスクリーンショットのサイズとぴったり同じなので、シミュレータのキャプチャを拡大縮小なしではめ込めます。¹¹ 半分折りたたんだビューも、斜めのビューもありません。

そこで以下のフレームは3つの部品で組み立てています。アプリ自身の色の地、短い1行の文字、そしてAppleのベゼルに収めた、欠けも傾きもなく、上に何も重ねていないキャプチャです。変化は、地、デバイスの大きさ、そしてセットごとに1枚の、デバイスをまったく使わないフレームから生まれます。黒の上にアプリのフルスクリーンのカードを置いたもので、これはアプリ自身の3Dであって、誰のハードウェアでもありません。

ツアーのキャプチャからスクリプトで組んだ3つのセット。1320×2868、1398×2034、2853×2007ピクセル。これは方法を示すもので、掲載物ではありません。これらのキャプチャにはカタログのカードが写っており、ストアのセットに何を映すかは、下の3つ目の注意で触れる未解決の問題です。

作ってみて得た、実用上の注意が3つあります。

スクリプトで組む。 上のセットは、キャプチャ、見出し、地を受け取り、ぴったりのサイズでアルファチャンネルのないPNGを書き出す、1つのPythonファイルから出てきます。アプリが変われば（このアプリはキャプチャした当日に2回変わりました）、ツアーをもう一度走らせればフレームも作り直されます。

端末が加えるものをスクリーンショットにする。 Appleのアップロードページによれば、インターフェースがどのサイズでも同じなら6.9インチのセットで足ります。「provide only the highest resolution screenshots required. They automatically scale down to smaller device sizes.」（必要な最高解像度のスクリーンショットだけを用意すればよい。小さいデバイスのサイズには自動的に縮小される）⁹ この端末では同じではありません。カードの壁と分割されたインスペクタは内側ディスプレイにしか存在しません。内側のセットの最初の2枚は、この2つです。

画面に何が映っているかに気をつける。 同じガイドラインには「You are responsible for securing the rights to all materials used in screen content within your app.」（アプリ内の画面コンテンツで使うすべての素材の権利を確保する責任はあなたにある）とあります。¹¹ コレクター向けアプリは、その性質上、ほかの人のアートワークを表示します。そしてストアの掲載はマーケティングであり、アプリが使用中に表示するものとは別物です。Kiradexについてはまだその判断をしておらず、上のフレームをこのまま提出することはありません。ツアーには、この理由から6枚の架空のカードで走る2つ目のモードがあります。ただしそのカードにはまだアートワークがないので、提出するセットを作るには、代わりの絵をデザインするか、権利を整理するかが必要です。

Kiradexにはまだ掲載ページがありません。掲載するときは6.9インチのセットから始め、Duoのセットは、App Store Connectが受け付ける日に向けて、専用のバージョンとともに待機させます。

コーディングエージェントに仕事を渡す

この作業の大半は、エージェントが得意とする種類のものです。ただし、アプリを見ることができれば、の話です。作業は2つに分かれ、そのうち一方はAppleが提供しています。

静的な半分はAppleのものです。 1本目のTech Talkは、それで締めくくられます。「During the talk, Modernize Your UIKit App, we introduced a new app modernization skill. With Xcode 27.1, this skill has a new name: App Resizability. It now supports SwiftUI and iPhone Duo.」（トーク「Modernize Your UIKit App」で新しいアプリ近代化のスキルを紹介した。Xcode 27.1でこのスキルはApp Resizabilityという新しい名前になり、SwiftUIとiPhone Duoをサポートするようになった）（9:19）³ このスキルはベータの中にあるプレーンテキストのファイル群で、Xcode 27.1 betaではContents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/app-resizability.idechatprompttemplateと、その隣の5つの参照ファイルです。¹⁵ その指示は、どこまで網を広げるかを述べています。「Treat a request about the foldable iPhone Duo as a request for every task in the Task Registry, because a screen that changes size exposes all of them at once.」（折りたたみのiPhone Duoについての依頼は、Task Registryのすべてのタスクの依頼として扱う。サイズが変わる画面は、それらすべてを一度に露わにするからだ）¹⁵

実行しないとしても、読む価値はあります。Appleのレビューのチェックリストを書き下したものだからです。プロジェクト設定を3つ確認し（ローンチスクリーンのキー、iPadの向きの宣言、UIRequiresFullScreen）、どれも変更しません。そのうえで5つのパターンを探します。UIScreen.main、インターフェースの向きで決めるレイアウト、userInterfaceIdiomで決めるレイアウト、シーンのライフサイクルを使うべきところでのアプリケーションのライフサイクル、そして左右が一致すると仮定したセーフエリアのコードです。セーフエリアのファイルには、この端末で起きる問題の半分を説明する一行があります。「Asymmetric horizontal insets are the normal case. Where a vertical bar is present, one horizontal edge usually carries the whole inset and the other carries zero.」（左右非対称のインセットが普通のケースだ。縦のバーがある場合、たいてい一方の辺がインセットのすべてを持ち、もう一方はゼロになる）¹⁵

Kiradexは今年書かれたSwiftUIアプリで、この5つの検索では何も見つかりません。¹³ 上で見つかったことはすべて、動かしたことから出てきました。これが静的な半分の限界です。読むのはソースであり、折り目、レール、キーボードは画面の上でしか見えません。

もう半分は、エージェントが走らせて目で見られる歩行です。 上の監査を可能にしたのは3つの小さな部品で、どれもこのアプリに固有のものではありません。

1. あらゆる種類の画面を訪れ、それぞれで止まるUIテスト。 アサーションではなく、ツアーです。私たちのものは、Dex、セット、カード、シート、コレクションのリスト、コレクションからのカード、フルスクリーンのビューア、キーボードを出した検索を開きます。停止点は8つです。¹³
2. テストの中ではなく、Mac側で行うキャプチャ。 UIテスト自身のスクリーンショットは1つのディスプレイしか写しません。simctlなら両方に届きます。

xcrun simctl io "$UDID" screenshot --type=png --display=primary   outer.png
xcrun simctl io "$UDID" screenshot --type=png --display=primary-1 inner.png

テストは停止点の名前を付けた空のファイルを書き、Mac側のシェルのループがそれを見て両方のディスプレイをキャプチャし、2つ目のファイルで応答します。テストはそれを待ってから先へ進みます。外側のキャプチャは端末を閉じた状態で1398×2034ピクセル、内側のキャプチャは開いた状態で2853×2007ピクセルなので、監査用の画像とストア用のスクリーンショットが同じ実行から出てきます。⁹¹³ 3. マウスに手を置かずにポーズを変える方法。 simctlにはポーズのコマンドがなく、このベータのUIテストのフレームワークにも、私が見つけられた限りヒンジの呼び出しはありません。そこでスクリプトはDevice HubのClosed、Book、Open、Rotate RightのボタンをアクセシビリティAPIで押します。これはDevice Hubがバックグラウンドにあっても動きます。¹³

これらがあれば、全ポーズでアプリを確認することは、エージェントの意見を求めることではなくなり、ポーズごとの画像フォルダになります。エージェントもあなたも、それを読めます。以下が、私なら渡すブリーフです。そのまま貼り付けられるように書いてあります。

Goal: make this app correct on iPhone Duo in every pose, without device checks.

0. Toolchain. Build with Xcode 27.1 beta. Confirm the binary is stamped with the 27.1 SDK:
   otool -l <App>.app/<App> | grep -A4 LC_BUILD_VERSION      (debug builds: <App>.debug.dylib)
   If "sdk" is lower than 27.1, stop: nothing below will reproduce.

1. Static pass. Report every use, with file and line, of:
   UIScreen.main / UIScreen.mainScreen; userInterfaceIdiom; interface orientation used for layout;
   a UIApplicationDelegate doing scene work; one safe-area inset applied to both sides;
   a bare ignoresSafeArea() on anything a person reads or taps; fixed widths tied to a phone size;
   toolbars or tab bars built by hand instead of owned by NavigationStack, NavigationSplitView or TabView;
   toolbar items with a title and no symbol, or a symbol and no title.
   Confirm Info.plist has a launch screen key and no orientation lock the design does not need.

2. Walk. Run the screenshot tour in each pose and capture BOTH displays at every stop:
   closed; closed and turned; open; open and turned; partly folded; partly folded and turned.
   If no tour exists, write a UI test that stops at each kind of screen and signals a host script, and have
   the script capture with:  xcrun simctl io <udid> screenshot --display=primary     (outer)
                             xcrun simctl io <udid> screenshot --display=primary-1   (inner)
   Poses are buttons in Device Hub (Closed, Book, Open, Rotate Right); simctl has no pose command.

3. Read every capture and answer, per pose:
   - Are the bars where the system puts them (down the side closed and in open landscape, across the top
     and bottom in open portrait)? Is any toolbar item missing from the bar and from the overflow menu?
   - Does any sheet reserve the side rail and leave it empty?
   - With the keyboard up, what is covered? Can every tab still be reached once it is dismissed?
   - Does anything sit under the outer camera corner or the status column?
   - Open: does a grid have an even number of columns? Does any control or line of text cross the middle?
   - Partly folded: does content move off the fold? Do sheets and alerts land on one side?
   - Turned: did a two-pane layout stack when it should have stayed side by side, or the reverse?
   - Is the same selection, scroll position and navigation path still there after the pose changed?

4. Fix with, in this order: a system container that already adapts; size classes; ArrangementView for a
   custom two-pane layout; reservedRegions for hand-placed content. Never branch on the device model,
   the idiom, the orientation, or the raw hinge angle to decide layout.

5. Guard everything from the 27.1 SDK with `if #available(iOS 27.1, *)` and a fallback that keeps both
   panes reachable. If the same source must also build with Xcode 27.0, fence it at compile time.

6. Report what could not be checked in the simulator: cameras, StandBy, extensions, haptics, real reach.

Appleの資料を、私なら使う順に

Appleがこのデバイスについて公開しているものは、すべて1つのページ、Get ready for iPhone Duoからたどれます。¹⁹ 作業の順に並べるとこうなります。

Group LabのQ&Aのまとめとフォーラムのスレッドは読んでいません。Appleのフォーラムのページは、自動化された取得に対して人間であることの確認ページを返し、私はそれを回避しませんでした。

要点

• いまアプリを出荷しているなら： リサイズの作業をいま、Xcode 27でビルドして出してください。10月23日の時点でストアが27.1 SDKに閉じたままなら、顧客がDuoで手にするのはそれであり、そのどれにもベータは要りません。
• Duo APIを採用するなら： Xcode 27.1 betaでビルドし、otoolでsdk 27.1以降であることを確認し、ビルドはTestFlightに置き、同じソースをまだストア向けにもビルドしなければならないなら、27.1専用の呼び出しを囲ってください。
• テストするなら： コードを読むのではなく、ポーズを動かしてください。閉じた状態、開いた状態、半分折りたたんだ状態、それぞれを回転させた状態、シート、キーボード、フルスクリーンのビュー、そして折り目をまたいで持ち越した1つの画面。毎回、両方のディスプレイをキャプチャします。
• ストアの掲載物を作るなら： いまDuoのサイズでキャプチャし、スクリプトで組み、Appleのベゼルを正面向きで使い、枠が開く日に向けてバージョンを準備しておいてください。
• これをエージェントに渡すなら： ファイルだけでなく、歩行を渡してください。AppleのApp Resizabilityスキルは読むことで見つかるものを扱います。上で見つかったことは、すべて見ることで見つかりました。

よくある質問

既存のアプリは変更なしでiPhone Duoで動きますか？

動きます。AppleのトークはどのSDKでビルドしたものにもそれを約束しており、シミュレータもそれを裏付けています。iOS 26 SDKでスタンプされたビルドは375×667ポイントのウインドウとして動き、27.0でスタンプされたものはステータスレールの隣の画面を、横向きのバーで埋めました。どちらも縦のバーや予約領域は得られません。³¹²

iPhone Duoの完全なレイアウトには、どのXcodeが必要ですか？

Xcode 27.1 beta（27A9269）です。iOS 27.1 SDKと、唯一のiPhone Duoシミュレータを搭載しています。その27.1シミュレータランタイムはiPhone Duoのデバイスタイプしかサポートしないため、ほかのiPhoneは27.0ランタイムでテストします。Xcode 27.2 betaのSDKも同じAPIを持ち、27.2でスタンプしたプローブはシミュレータで27.1と同じように振る舞いましたが、そのXcodeには動かすためのDuoがありません。⁸¹²¹⁴

いまiPhone DuoのビルドをApp Storeに提出できますか？

2026年10月2日時点では、27.1 SDKでビルドしたものはできません。App Store Connectは、Xcode 27.1 betaと27.2 betaのビルドを内部・外部のTestFlightテスト向けに、Xcode 27のビルドをストア向けに受け付けています。この変更の日付をAppleは示していません。⁸

App Store ConnectはiPhone Duo用にどのスクリーンショットサイズを求めていますか？

外側ディスプレイ用に1398×2034または2034×1398ピクセル、内側ディスプレイ用に2007×2853または2853×2007ピクセルで、アルファチャンネルのない画像を1枚から10枚です。アップロードは「later this year」（今年後半）に提供予定とされています。⁹

iPhone Duoシミュレータの両方のディスプレイをキャプチャするには？

外側ディスプレイはxcrun simctl io <udid> screenshot --display=primary、内側は--display=primary-1です。UIテスト自身のスクリーンショットは1つのディスプレイしか対象にしません。¹³

iPhone Duoシミュレータで、アプリのバーがまだ横向きなのはなぜですか？

原因は3つで、確認する順に挙げます。バイナリが27.1 SDKでスタンプされていない。バーがTabView、NavigationStack、NavigationSplitViewの持ち物ではなく手作りされている。あるいは内側ディスプレイがポートレートで、そこではAppleが設計としてバーを横向きに保っている。²⁷¹²

ポーズごとにレイアウトが必要ですか？

いいえ。Appleのガイダンスは、compact幅とregular幅の2つのレイアウトに加え、コンテンツが折り目を横切りそうな箇所で折り目に対応すること、というものです。Kiradexにはその2つと、arrangementのビューが1つあります。Bookのポーズにはコードが要りませんでした。⁷¹³

このサイトの関連記事：シミュレータの記事には、インストール手順、デバイスプロファイル、訂正済みのポーズごとの測定値があります。iPhone Duoのためのデザインは、Appleのデザインガイダンスをルールとして読み解いています。Duo開発者向けの記事には、ハードウェアの数値と日付入りの経緯があります。スクリーンショットの記事は、セットが何を語るべきかについての論考です。リサイズ可能なiPhoneのチェックリストは、この記事が最初に出荷するよう勧めるXcode 27での作業です。そしてXcode 27のハブがツールチェーンを追っています。

出典