iOS 27のiPadリサイズ対応：回避策には代償がある

AppleのiOS 27リリースノートは、連続的にリサイズできないiPadアプリ向けに、1行だけの回避策を示しています。Info.plistで4つのインターフェース方向すべてをサポートすると宣言する、というものです。¹ ただしそのノートが書いていないのは、システムがこのアプリ全体の宣言を各view controllerがサポートする向きと突き合わせ、その積を取るという点です。² アプリ全体の集合を広げれば、iPhoneも含めてあらゆる場所で広がります。制約のあるview controllerがすべてsupportedInterfaceOrientationsをオーバーライドしていない限り、そうなるのです。

更新（8月24日）： このゲートは解消されました。現行のリリースノートは、問題166422120をFixedとして掲載しています。beta 4版とbeta 6版のあいだにKnown Issuesから移動し、beta 7版でもそれが確認できます。宣言された向きが連続リサイズの条件になることはもうなく、下記に引用した意図どおりの挙動になりました。¹ 4方向すべてを宣言する回避策をすでに出荷済みなら、現行のベータではもう必要ありません。ただし取り除く前に、その回避策と併せてsupportedInterfaceOrientationsのオーバーライドを追加したview controllerを改めて確認してください。それらのオーバーライドは、それ自体として今も効いているからです（本記事で扱う積集合の挙動は変わっていません）。beta 4当時のUIRequiresFullScreenのリサイズに関するKnown Issuesも同様に、Resolved IssuesでFixedとされています。以下の分析はBeta 4を基準として書かれたまま残してあります。出荷済みビルドに回避策が残っている限り、その副作用の仕組みは今も当てはまるからです。この変更が収まる全体像については、リサイズ可能なiPhoneの時代をご覧ください。

この変更について流布している見出し的な理解も、現状の説明としては誤っています。 Appleの意図は、宣言された向きが連続リサイズを制限しなくなることにあります。その意図を記したリリースノートがKnown Issuesに分類されているのは、Beta 4では依然として制限が効いているからです。¹

どちらの側面も重要です。この挙動は意図的な変更へ向かう途上のバグであり、そしてそのバグの回避策には、同じ場所には書かれていない副作用があるのです。

TL;DR

iOS & iPadOS 27 Beta 4では、iOS 27 SDKでビルドされ、UISupportedInterfaceOrientationsに4方向のいずれかを含めていないiPadアプリは、連続リサイズ非対応として扱われます。Appleはこれを既知の問題として挙げると同時に、向きは「連続リサイズの条件ではなくなるはずだ」とも述べています。¹ 文書化された回避策は、4方向すべてを宣言することです。しかしそうするとアプリ全体の向きの集合が広がり、システムは回転の可否をアプリ全体の向きと各view controllerの向きとの比較で決めます。² さらに4件の既知の問題は、離散的なUIScreenの変更が意図されている場面でUIRequiresFullScreenが連続的なリサイズ更新を配信する、という内容です。¹ UIRequiresFullScreenもUISupportedInterfaceOrientationsも、非推奨にはなっていません。³⁴

リリースノートが実際に述べていること

iOS & iPadOS 27 Beta 4のノートのうち、UIKitセクションの6件がこの話題に関係し、そのうち5件が未解決です。¹

ゲートそのもの、Known Issuesに分類：

「iPadでは、iPadアプリがiOS 27 SDKでビルドされ、そのUISupportedInterfaceOrientationsが4つのインターフェース方向すべてを含んでいない場合、そのアプリは連続リサイズ非対応として扱われます。iOS 27以降、サポートされるインターフェース方向は連続リサイズの条件ではなくなるはずです。」

2文目の時制に注目してください。「条件ではなくなるはずです」は、意図された挙動を述べたものです。この項目が既知の問題として存在しているのは、出荷中の挙動がまだその意図と一致していないからです。

この区別は、取るべき行動を左右します。もし向きが本当に制限として働かなくなっているのなら、助言は「回避策を外しなさい」になるはずです。実際にはまだ制限が効いているので、助言は「回避策を適用し、その理由がやがて消えることを見込んでおきなさい」となります。

UIRequiresFullScreenにまつわる4件の既知の問題：

iOS 27 SDKでビルドされUIRequiresFullScreenを設定したiPadアプリは連続的なリサイズ更新を受け取りますが、本来は「各リサイズは、更新されたboundsを持つ新しいUIScreenへの離散的な変更として配信されるべき」です。同じことが、iPad上で動作するiPhone専用アプリにも、そしてiPhoneミラーリング内でも当てはまります。¹

4件目はiPhoneミラーリングにおける向きの扱いです。iOS 27 SDKでビルドされたアプリは、「UISupportedInterfaceOrientationsで宣言された向きやUIViewController.supportedInterfaceOrientationsが返す向きにかかわらず」すべての向きをサポートするsceneを受け取ります。本来これらは「ユーザーがウインドウのリサイズを始めるまで尊重されるべき」ものです。¹

解決済みが1件： UIRequiresFullScreenの下でリサイズ時にUIScreen.mainのboundsが変化するという以前の問題は、現在Resolved Issuesに掲載されています。¹ これは以前のベータでは有効な既知の問題でした。数週間前に取ったメモを頼りに作業しているなら、繰り返す前にこの1件を確認してください。

連続リサイズで得られるもの

代償を検討する前に、制限されている当のものを正確に押さえておく価値があります。「連続的にリサイズ可能」という言葉は、特定の意味を担っているからです。

iPadのウインドウのサイズが変わる道筋は2つあります。ひとつは離散的な状態のあいだを飛び移るもので、互換モードのアプリが得るのがこれです。Appleの言葉を借りれば、システムは「アプリのsceneサイズを一貫して維持しますが、アプリのsceneをフルスクリーンでは表示しません」。³ もうひとつはドラッグに追随するもので、ユーザーがリサイズコントロールを動かすあいだ、中間のサイズが次々と届きます。

その差はユーザーの手元に現れます。連続リサイズ対応のアプリは、ウインドウが動いているあいだにレイアウトを流し直します。非対応のアプリはレイアウトを保持し、最後にスナップします。そうしないシステムアプリと並ぶと、これは鈍く見えるのです。

Appleは何年もかけて互換モードという逃げ道を狭めてきました。UIRequiresFullScreenはiOS 9で登場し、iPadのマルチタスクと動的リサイズから完全に離脱するための手段でした。³ iPadOS 16のStage Manager、iPadOS 26のWindowed Appsモードは、それぞれウインドウにできることを広げ、ドキュメントは今や互換モードを、何を与えるかではなく何を差し控えるかで説明しています。

つまり回避策が答えを出す問いは、あなたのiPadアプリが現代的なウインドウ管理に参加するのか、それともAppleが縮め続けているモードに留まるのか、というものです。それはInfo.plistを変更するだけの価値があります。ただし無防備な変更に見合う価値はありません。それが次のセクションの主題です。

回避策の代償

Appleの回避策は1文で述べられています。Info.plistで4つのインターフェース方向すべてを宣言する、というものです。¹ その帰結は、別のページに書かれています。

UIViewController.supportedInterfaceOrientationsは、回転がどう決まるかを説明しています。²

「回転するかどうかを判断するために、システムはview controllerのサポートする向きを、アプリのサポートする向き（Info.plistファイルまたはapp delegateの[メソッド]によって決まります）およびデバイスのサポートする向きと比較します。」

3つの集合の積です。Info.plistの宣言は指示ではなく、上限なのです。Info.plistに1つの向きだけを列挙して縦向き専用を保ってきたアプリが、view controllerレベルでは何もオーバーライドしていなければ、回避策を適用した瞬間にその制約を失います。

ユニバーサルアプリなら、これはiPadだけでなくiPhoneにも降りかかります。しかもAppleの指針自体が、iPhoneで広い宣言をすることに反対しています。上下逆さまの向きについて、「iPadイディオムでは有効にするのがベストプラクティスです。iPhone 12のようにホームボタンのないiOSデバイスは、この向きをサポートしません。iPhoneイディオムでは完全に無効にすべきです」とあります。² Info.plistのドキュメントも、逆方向から同じことを述べ、システムは「ホームボタンのないデバイスでは」上下逆さまを無視すると記しています。⁴

ですから正直な指示は、1段階ではなく2段階になります。

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

2段階目を飛ばせば、iPadのウインドウ挙動を得るために、ユニバーサルアプリへiPhoneで上下逆さまに回転せよと命じたことになります。その失敗はクラッシュでもビルドエラーでもありません。誰かが使っている最中にカメラビューが反転する、という形で現れるのです。

なおsupportedInterfaceOrientationsの既定値はイディオムによって異なり、システムがこれを参照するのはshouldAutorotateがtrueを返すときだけです。² これをオーバーライドしているなら、自分の制約が保たれていると決めてかかる前に、この相互作用を読み直しておく価値があります。

自分が影響を受けるかどうかを見極める

ここまでの話はどれもビルドエラーを生まないので、監査は手作業になります。節約できる時間の大きい順に、3つの確認をします。

Info.plistが実際に何を宣言しているかを、ターゲットごとに確認する。 向きのキーはプロジェクト作成時に一度設定されたきり見直されないことが多く、ユニバーサルアプリはUISupportedInterfaceOrientations~ipadを通じてiPhoneとiPadで異なる宣言を抱えられます。両方を読んでください。

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddyはキーが存在しないと非ゼロで終了しますが、それ自体がUIRequiresFullScreenについての答えになります。キーがないなら、そもそも互換モードに入ったことがないということです。

コードで向きを制約しているcontrollerを探す。 Info.plistを変更したあとも効き続けるのはこれらであり、これが無いことこそが、その変更を危険にしています。

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

結果が空で、しかもInfo.plistの宣言が狭い——この組み合わせが、まさに壊れるプロファイルです。アプリはプロパティリストだけによって縦向き専用になっているので、そこを広げれば存在していた唯一の制約が消えます。

そのうえで、両方のイディオムで実際にアプリを見る。 失敗は視覚的なもので、自動化された検出は弱いのです。画面を操作して内容をアサートするUIテストは、どの向きでも通ってしまいます。探すべきは、これまで回転できなかったビューが回転することであり、そのためにはInfo.plistの変更後にiPhoneビルドを走らせ、実機かシミュレータを実際に回してみる必要があります。

メディアキャプチャ、書類スキャン、署名欄、ゲーム、そして固定アスペクト比のキャンバスを持つものは、予期しない回転の代償がもっとも大きい領域であり、同時にcontrollerごとのオーバーライドがもっとも自然に収まる場所でもあります。

UIRequiresFullScreenは非推奨ではなく、中身を抜かれている

未解決の5件のうち4件がUIRequiresFullScreenに関わります。¹ アプリをiPadのマルチタスクから外すためのこのキーが、今やリサイズ配信が正しく動かない条件になっているのです。

非推奨ではありません。UIRequiresFullScreenのドキュメントはiOS 9.0とiPadOS 9.0での提供を示しており、非推奨・利用不可・ベータのいずれのフラグもありません。³ UISupportedInterfaceOrientationsも同様で、iOS 3.2から利用できます。⁴

この組み合わせには名前を与えておく価値があります。2026年にUIRequiresFullScreenを設定したアプリは、警告なしにコンパイルされ、移行の通知もなく出荷され、そしてAppleが狭め続けている互換モードに着地します。そのモードが現代のシステムで何を意味するかは、すでにドキュメントに書かれています。Windowed AppsモードをサポートするiPadのiPadOS 26以降、そしてStage ManagerをサポートするiPadのiPadOS 16以降では、システムは「アプリのsceneサイズを一貫して維持しますが、アプリのsceneをフルスクリーンでは表示しません」。³

このキーは、もはやその名前が言うとおりの働きをしません。廃止はされておらず、そしてビルドの中の何ひとつ、それをあなたに教えてはくれないのです。

共通するパターン：SDKのリンク先が決める

ここまでの項目にはすべて共通の条件があり、それはOSのバージョンではありません。どれも「iOS 27 SDKでビルドされた」アプリに当てはまります。¹

同じソース、違うバイナリ、違う挙動。今回のリリースでは、これが繰り返し現れています。メニュー項目の画像は、どのSDKに対してリンクしたかで変わり、2世代のSDKにまたがって3つの異なる挙動が生じます。一方でmacOS 27のチーム間コンテナ拒否は逆のケースに見え、SDKの条件が付かないOSレベルのポリシーです。だからこそ、思い込みで済ませずこの区別を確認する価値があるのです。

テストにとっての実務的な帰結はこうです。iOS 26 SDKに対するビルドとiOS 27 SDKに対するビルドは、別々の対象です。CIマトリクスのXcodeが1バージョンなら、テストしているのはそのうち片方だけです。

いま何をすべきか

そもそも連続リサイズが必要かどうかを決める。 iPadアプリがすでに4方向すべてを宣言しているなら、ここまでの話は当てはまりません。回避策が関係するのは、意図的に向きを制約した場合だけです。

回避策を適用するなら、controllerごとのオーバーライドと組にする。 Info.plistの変更は上限であり、制約のほうは、それを必要とするcontrollerのsupportedInterfaceOrientationsへ、イディオムで分岐させて移す必要があります。

UIRequiresFullScreenは別途監査する。 未解決の4件がこれに関わり、しかもビルドでは何も指摘されません。Info.plistファイルをgrepしてください。iPadアプリだとは思っていないターゲットも含めてです。問題のひとつは、iPad上で動くiPhone専用アプリを対象にしているからです。

このゲートは消えると見込んでおく。 Appleは、向きが連続リサイズの条件ではなくなるはずだと述べています。それが実現したとき、4方向すべてを宣言する理由は消えますが、広げられた向きの集合は、誰かが取り除くまでInfo.plistに残り続けます。なぜそこにあるのかを説明するコメントを残しておきましょう。

行動する前にノートを再確認する。 この6件のうち1件は、すでにKnown IssuesからResolvedへ移りました。本記事は2026年8月2日時点のBeta 4を反映しています。

要点

iPadアプリの開発者へ： - Beta 4では、Appleが条件ではないはずだと述べているにもかかわらず、宣言された向きが依然として連続リサイズを制限します。新しい挙動ではなく、回避策のあるバグとして扱ってください。 - 回避策はアプリ全体の向きの上限を広げます。controllerごとのsupportedInterfaceOrientationsオーバーライドを追加しなければ、iPhoneビルドが回転し始めます。 - 未解決の4件は、UIRequiresFullScreenが離散的ではなく連続的なリサイズ更新を配信することに関わっています。

古いアプリを保守している人へ： - UIRequiresFullScreenは非推奨ではなく警告も出ませんが、それが要求する挙動のほうは狭まり続けています。明示的に監査してください。 - ここに挙げた問題はすべて、ユーザーが動かしているOSではなく、iOS 27 SDKでビルドすることを条件としています。

FAQ

宣言された向きは、連続リサイズを制限しなくなったのですか

Beta 4ではまだです。Appleは「iOS 27以降、サポートされるインターフェース方向は連続リサイズの条件ではなくなるはずです」と述べていますが、現在の挙動が依然としてそれらを条件にしているため、その記述をKnown Issuesに分類しています。¹

実際の回避策は何ですか

UISupportedInterfaceOrientationsで4つのインターフェース方向すべてを宣言することです。¹ そして制約を保つ必要のあるview controllerにはsupportedInterfaceOrientationsのオーバーライドを組み合わせてください。システムはアプリ全体の集合と各controllerの集合の積を取るからです。²

これはiPhoneビルドに影響しますか

ユニバーサルアプリを出荷していて、向きの制約をInfo.plistだけに頼っているなら、影響します。Appleは、iPhoneイディオムでは上下逆さまを完全に無効にすることを推奨し、ホームボタンのないデバイスではシステムがそれを無視すると記しています。²⁴

UIRequiresFullScreenは非推奨ですか

いいえ。そのドキュメントはiOSとiPadOS 9.0での提供を示しており、非推奨フラグはありません。³ ここで挙げた未解決の問題のうち4件がこれに関わるので、非推奨マーカーが無いことを推奨と読み替えるべきではありません。

Appleがゲートを修正したら、回避策は外すべきですか

不要になった部分は外し、自分を守っている部分は残してください。宣言された向きが連続リサイズの条件でなくなれば、4方向すべてを列挙する理由は消え、UISupportedInterfaceOrientationsをアプリが実際にサポートする範囲へ戻せます。一方、controllerごとのsupportedInterfaceOrientationsオーバーライドは、いずれにせよ残すべきです。向きの制約は、制約が属する場所で表現するほうが、アプリ全体の上限に頼るよりも長持ちするからです。

避けたい失敗はその逆です。Info.plistを狭く戻しながら、キャプチャ画面をまっすぐ保っていた唯一の存在がそのオーバーライドだったことを忘れてしまう、というものです。

自分のアプリが現在連続リサイズ対応かどうかは、どう確かめますか

iPadでウインドウをリサイズし、レイアウトがドラッグに追随するか、最後にスナップするかを見てください。追随するなら連続リサイズ対応です。スナップするなら、2点を確認します。動的リサイズから完全に離脱させるUIRequiresFullScreenが設定されていないか、そしてUISupportedInterfaceOrientationsが4方向すべてを列挙しているか。後者が、この既知の問題が述べている条件です。¹³

古いSDKに対してビルドすれば、これらをすべて回避できますか

各項目はiOS 27 SDKでビルドすることを条件としています。¹ 古いSDKならこれら個別の問題は避けられますが、それは最終的な変更を防ぐのではなく先送りするだけです。

出典