リサイズ可能なiPhoneの時代：9月までにアプリを備えておく

iPhoneアプリをリサイズ可能な画面に備えさせるには、どうすればよいのでしょうか。 Appleが引く境界線は、リンク先のSDKです。Xcode 27のDevice Hubは、iOS 26以前のSDKに対してリンクされたアプリではリサイズモードを明確に非サポートとして扱い、iOS 27リリースノートのリサイズ関連の記述はどれも「iOS 27 SDKでビルドされている」ことを条件としています。¹² そのうえで、固定サイズを前提にした箇所（UIScreen.main.boundsの参照、ハードコードされたframe、向きで分岐するレイアウト）をすべて洗い出し、size classとレイアウトに適応するSwiftUIのコンテナに寄せ、Xcode 27のResizable Canvasプレビューとdevice hubのリサイズモードで継続的にテストしていきます。² 連続的なリサイズを妨げていた向きの前提条件は、現行のリリースノートでFixedと記載されました。道筋はすでに開けているのです。¹

この夏、Appleの秋のベータはiPhone開発者に向けて一つのメッセージへと収束してきました——固定された長方形を前提にするのはやめること。その証拠は基調講演ではなく、ツールとリリースノートの中にあります。リサイズ対応はiOS 27 SDKへのリンクとともに到来し、プレビューのキャンバスは自由にリサイズでき、ベータサイクルが成熟するにつれてリリースノートは最後の構造的な障害を取り除きました。この秋どんなハードウェアが出るとしても、ソフトウェア側の約束事はすでに変わっています。

要約： iOS 27は新しいSDKでビルドされたアプリに連続的なリサイズをもたらします。Xcode 27はそのためのテスト面（Resizable Canvasプレビュー、device hubのリサイズモード）を備えています。そして現行のリリースノート——8月24日公開のbeta 7版——は、向きに関するゲートをFixedとして掲載しています。この項目はbeta 4版とbeta 6版の間にKnown Issuesから外れ、宣言された向きがアプリのリサイズ可否を決めることはもうなくなりました。¹ 作業の大半は引き算です。レイアウトが画面サイズを一つだと信じ込んでいる箇所を見つけ、その思い込みを取り除いていきましょう。以下、私が実際に進める順番でのチェックリストです。

なぜ今なのか

日付のある事実が3つ、時計を進めています。

1. beta 7は8月24日に到着しました。 サイクルは安定化フェーズに入っています——Appleの後期ベータは追加ではなく修正が中心で、正式リリースは毎年9月に出ています。¹
2. リサイズ対応の境界はSDKへのリンクです。 Xcode 27のリリースノートは、「iOS 26以前のSDKに対してリンクされたアプリ」でdevice hubのリサイズモードに入ることを「unsupported（非サポート）」と記述しています。² 同じパターンはiOS側のノートにも通っており、リサイズ関連の記述はすべて「iOS 27 SDKでビルドされている」ことが条件です。リビルドすればその線のリサイズ対応側に入り、古いSDKに留まればプラットフォームの向かう先から降りることになります。
3. 最後の構造的なゲートが解消されました。 beta 4の時期には、UISupportedInterfaceOrientationsから4つの向きのいずれかが欠けているiPadアプリは、連続的なリサイズ非対応として扱われていました。これはKnown Issueであり、文書化された回避策には文書化されていないコストが伴っていたことをリサイズ回避策の記事で取り上げました。この項目はノートのbeta 4版とbeta 6版の間にKnown Issuesから外れ、現行版ではFixedとして掲載されています。「iOS 27以降、サポートするインターフェースの向きは連続的なリサイズの条件ではなくなるはずです」。beta 7のノートにあるUIKitのKnown Issuesの一覧は空です。¹

まとめると、プラットフォームはレイアウトをデバイスのスペック表ではなくコンテナの関数として書くことを期待しています。iPadはマルチタスクを通じてこの教訓を先に教えてくれました。iOS 27は同じ約束事をiPhoneにも広げるのです。

チェックリスト

1. iOS 27 SDKでリビルドし、そのうえで実際に目で見る

オプトインの実体はリビルドです。レイアウトのコードを1行も変える前に、Xcode 27でビルドし、device hubのリサイズモードを開いて、ドラッグしてみてください。適切に分割されたSwiftUIアプリの多くは、この最初の接触を作者の予想より上手く乗り切ります。壊れる箇所こそ学びであり、しかも毎回同じ数カ所で壊れます——このチェックリストの残りは、まさにその数カ所の話です。

2. 固定サイズという思い込みを狩る

よくある違反箇所を、たいてい効いてくる順に並べます。

• UIScreen.main.boundsを「画面サイズ」として使っている。 リサイズ前提の世界にその画面サイズというものは存在せず、UIScreen.mainはiOS 26で正式に非推奨となりました。サイズはwindow sceneから導き出すか、SwiftUIであればGeometryReaderを控えめに、あるいはcontainerRelativeFrame(_:)を意図をもって使い、コンテナから導出しましょう。
• 特定のデバイスに合わせたハードコードのframeとマジックナンバー（「幅390ポイントならiPhone」といった類）。if width == <数値>によるデバイス推定は、必ずいつか嘘をつきます。
• サイズではなく向きで分岐するレイアウト。 向きのチェックは常に代用品でした。iOS 27が向きとリサイズ対応を切り離した今、この代用品は公式に不要な荷物です。水平・垂直のsize classで分岐してください。もともとそのための仕組みなのです。
• 起動時に寸法をキャッシュしている。 起動時に一度計測して保存した値は、最初のリサイズで古くなります。

3. アダプティブなコンテナに仕事をさせる

SwiftUIの現代的なレイアウト機構は、まさにこのために作られています。配置の選択にはViewThatFits、画面ではなくコンテナに対するサイズ指定にはcontainerRelativeFrame、その中間のすべてにはgridと柔軟なframeがあります。固定長方形の時代から続くアプリなら、最も効くリファクタリングはたいてい、荷重を支えているGeometryReader＋算術のレイアウトを一つ、これらのプリミティブに置き換えることです。UIKitのアプリでも、size classとUICollectionViewCompositionalLayoutの環境駆動セクションで同じ結果が得られます。

iOS 27のツールバーとレイアウトの変更も同じ方向を押しています——フレームワークはスペースが尽きる地点で明示的な制御を渡してくれるようになり、そしてスペースは今や動的に尽きるのです。

4. 実際にリサイズが起きる場所でテストする

Xcode 27には専用のテスト面が2つあり、どちらもベータサイクルの早い段階で成熟しました。

• プレビューのResizable Canvasモード——特定のサイズ比に縛られなくなったため（この制約はbeta 2で解除されました）、アプリが取り得る形状の全域をドラッグして確認できます。²
• 実行中のアプリ向けのdevice hubのリサイズモード。脱出経路の不具合はbeta 3以降修正済みです（クラッシュやバックグラウンド移行でリサイズモードを抜けても、再起動までデバイスの画面が固まることはなくなりました）。²

主要な画面のすべてについて、それぞれで一巡してください。見つかるバグは、キャッシュした画面、前提を置いた画面、推測した画面に集まります。

5. 何年も前に設定したフラグを見直す

UIRequiresFullScreenと、範囲を狭めたUISupportedInterfaceOrientationsの宣言は、アプリが歴史的にiPadのマルチタスクの要求からオプトアウトするための手段でした。どちらも非推奨ではありませんが、両方とも今は新しい意味で荷重を支えています——ベータサイクルはこれらが連続的なリサイズとどう相互作用するかを何版かにわたって整理してきており、beta 4期にあったUIRequiresFullScreenのリサイズ挙動に関するKnown Issuesは、現在Resolved Issuesの下でFixedと記載されています。¹ これらのキーが2019年の判断のためにInfo.plistに残っているなら、その判断を意図的に下し直す月が今月です。回避策のコスト分析では、範囲を広げる前に確認しておきたい向きの設定の副作用を扱っています。

6. 二次的な影響を見込んでおく

リサイズ可能になるとは、テキストの折り返しが変わり、画像のクロップが変わり、NavigationSplitViewが誰かの気分で畳まれたり開かれたりし、丁寧に調整した空状態がプレビューしたことのないアスペクト比で表示されるということです。どれ一つとして個別には難しくありません。それでも、ハードウェアが出る週ではなく今からチェックリストを始める理由は、まさにこれらすべてなのです。

私ならやらないこと

特定のデバイスについて推測するのはやめましょう。リサイズの約束事は今日ダウンロードできるSDKの中にあり、今日読めるリリースノートに文書化されており、Xcode 27の最初のベータで出荷されたツールでテストできます。折りたたみiPhoneがこの秋に登場するなら、上のリストをこなしたアプリは準備できています。来春になるとしても、同じ作業はiPadのマルチタスク、そしてプラットフォームが次にリサイズする何かに対して、すぐに報われます。噂に備えるより、仕組みに備えるほうが優れているのです。

要点

• オプトインの線はSDKへのリンクです。 iOS 27 SDKでリビルドすれば、リサイズ対応はあなたのアプリの課題であり機会になります。device hubは古いSDKのアプリでのリサイズモードを非サポートとして扱います。²
• 向きのゲートは解消されました。 宣言された向きがリサイズ可否を決めることはもうありません——この項目は現行のノートでFixedと記載され、UIKitのKnown Issuesの一覧は空です。¹
• 作業は機能の追加ではなく、前提の削除です。 画面サイズの参照、マジックナンバーのレイアウト、向きによる代用、起動時のキャッシュ。これらを見つけ、コンテナから導出するレイアウトに置き換えれば完了です。
• 本物のテスト面で試してください。 Resizable Canvasプレビューとdevice hubのリサイズモードは、まさにこのために存在します。画面ごとにそれぞれを一巡すれば、後で効いてくる問題の大半が見つかります。

FAQ

アプリは自動的にリサイズ可能になるのですか？

Appleが引く境界はSDKへのリンクです——Xcode 27のリリースノートはiOS 26以前のSDKのアプリでのリサイズモードを非サポートと呼び、iOS側のノートはリサイズの挙動すべてをiOS 27 SDKでのビルドを条件としています。¹² その先に起きることはレイアウト次第です。コンテナ駆動のSwiftUIならおおむね適応し、固定サイズの前提はバグとして表に出てきます。

連続的なリサイズのために、4つの向きすべてを宣言する必要はまだありますか？

いいえ。現行のリリースノートは向きの条件をFixedとしており（beta 4版とbeta 6版の間に解消されました）、「サポートするインターフェースの向きは連続的なリサイズの条件ではなくなるはずです」と述べています。¹ 以前のベータでは4つすべてを宣言する回避策が必要でしたが、それを出荷したのであればアプリ全体に及ぶ副作用を理解しておく価値があります。

UIRequiresFullScreenは非推奨になったのですか？

いいえ。引き続きサポートされるキーであり、そのリサイズ挙動に関するベータサイクル中のKnown Issuesは、現行のノートのResolved Issuesの下でFixedと記載されています。¹ ただしこれはまさに、リサイズを前提とするプラットフォームで意図的に判断し直す価値のある、何年も前のオプトアウトです。

これが急務になるのはいつですか？

iOS 27の正式リリースは9月と見込まれ、Appleの秋のSDK要件サイクルにより、その後は新規申請がAppleの通常のスケジュールでiOS 27 SDKへ移行します。上のチェックリストは大半のアプリにとって集中して1週間ほどの作業です。今から始めれば、ローンチシーズンまでに余裕をもって終えられます。

出典