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

AppleのiOS 27リリースノートには、連続リサイズに対応していないiPadアプリ向けの回避策が1行だけ書かれています。Info.plist で4種類すべてのインターフェースの向きをサポートすると宣言する、というものです。¹ しかしそこには書かれていないことがあります。システムはこのアプリ全体の宣言を、各ビューコントローラがサポートする向きと突き合わせて共通部分を取る、という点です。² 制約を効かせたいビューコントローラすべてで supportedInterfaceOrientations をオーバーライドしていない限り、アプリ全体の宣言を広げた影響はiPhoneを含むあらゆる場所に及びます。

この変更を一言でまとめた説明もまた、現状を正しく表していません。 Appleの意図は、宣言済みの向きが連続リサイズの条件ではなくなる、というものです。ところがその意図を記したリリースノートの項目は「Known Issues（既知の問題）」に置かれています。Beta 4の時点では、依然として向きが条件になっているからです。¹

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

要点

iOS & iPadOS 27 Beta 4では、iOS 27 SDKでビルドされたiPadアプリの UISupportedInterfaceOrientations に4種類の向きのいずれかが欠けていると、そのアプリは連続リサイズ非対応として扱われます。Appleはこれを既知の問題として挙げつつ、向きは「連続リサイズ対応の条件ではなくなるはずだ」とも述べています。¹ 文書化された回避策は、4種類すべてを宣言することです。ただしそうするとアプリ全体の向きの集合が広がり、システムは回転の可否をアプリ全体の向きと各ビューコントローラの向きの比較で決めます。² さらに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 が返す向きにかかわらず」、すべての向きをサポートするシーンを受け取ります。本来これらは「ユーザーがウィンドウのリサイズを始めるまでは尊重されるべき」ものです。¹

解決済みが1件: UIRequiresFullScreen 下でリサイズ時に UIScreen.main のboundsが変化するという以前の問題は、現在は「Resolved Issues（解決済みの問題）」に移っています。¹ 少し前のベータでは現役の既知の問題でした。数週間前のメモをもとに作業しているなら、そのまま引き写す前に確認してください。

連続リサイズ対応で何が得られるのか

代償を測る前に、何が制限されているのかを正確にしておきましょう。「連続リサイズ対応」という言葉は、具体的な意味を担っています。

iPadのウィンドウがサイズを変える方法は2つあります。ひとつは離散的な状態のあいだを飛び移るやり方で、互換モードのアプリはこちらになります。Appleの表現では、システムは「アプリのシーンのサイズを一定に保ちますが、アプリのシーンをフルスクリーンでは表示しません」。³ もうひとつはドラッグに追従するやり方で、ユーザーがリサイズ用のコントロールを動かすあいだ、途中のサイズが次々と届きます。

違いはユーザーの手元に現れます。連続リサイズに対応したアプリは、ウィンドウが動いているあいだにレイアウトを組み替えます。対応していないアプリはレイアウトを保ったまま、最後にカクッと収まります。そうならない標準アプリと並べば、動きが鈍く感じられるでしょう。

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

つまりこの回避策が答えを出すのは、自分のiPadアプリを現代的なウィンドウ管理に参加させるのか、それともAppleが縮め続けているモードに留めておくのか、という問いです。それは Info.plist を書き換えるだけの価値があります。ただし、無防備な書き換えにその価値はありません。次の節はまさにその話です。

回避策の代償

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

UIViewController.supportedInterfaceOrientations のドキュメントには、回転がどう決まるかが書かれています。²

「回転すべきかどうかを判断するために、システムはビューコントローラがサポートする向きと、アプリがサポートする向き（Info.plist ファイル、またはアプリのデリゲートの[メソッド]によって決まります）、そしてデバイスがサポートする向きを比較します。」

3つの集合の共通部分です。Info.plist の宣言は上限であって、指示ではありません。Info.plist に1つの向きだけを並べ、ビューコントローラ側では何もオーバーライドしないことで縦向き固定を保ってきたアプリは、回避策を適用した瞬間にその制約を失います。

ユニバーサルアプリなら、影響は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 の既定値はiPhoneとiPadで異なり、システムがこれを参照するのは shouldAutorotate がtrueを返すときだけです。² shouldAutorotate をオーバーライドしているなら、制約が効いていると決めてかかる前に、両者の関係を読み直しておく価値があります。

自分のアプリが影響を受けるかを確かめる

ここまでの話は、どれもビルドエラーにはなりません。つまり点検は手作業です。手間を省ける度合いが大きい順に、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 についての答えです。キーがないなら、そもそも互換モードに入っていなかったということになります。

コードで向きを制約しているビューコントローラを探す。 Info.plist を変更したあとも効き続けるのは、これらです。逆に言えば、これが存在しないことこそが変更を危険にします。

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

検索結果が空で、かつ Info.plist の宣言が狭い——これが壊れる典型的な組み合わせです。アプリが縦向き固定なのはひとえにプロパティリストのおかげであり、そこを広げれば、唯一存在していた制約が消えてしまいます。

そのうえで、iPhoneとiPadの両方で実際のアプリを見る。 不具合は見た目に現れるもので、自動テストで拾える手がかりは多くありません。画面を操作して内容を検証するUIテストは、どの向きでも通ってしまいます。探しているのは、以前は回らなかったビューが回ってしまう状態です。つまり Info.plist の変更後にiPhone向けビルドを走らせ、実機やシミュレータを実際に回してみる必要があります。

メディアの撮影、書類のスキャン、署名の入力欄、ゲーム、そしてアスペクト比が固定されたキャンバスを持つもの——こうした画面では、想定外の回転が最も高くつきます。同時に、ビューコントローラ単位のオーバーライドが最も明らかに必要な場所でもあります。

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

未解決の5件のうち4件が UIRequiresFullScreen に関わるものです。¹ iPadのマルチタスクから降りるためのこのキーは、いまやリサイズ通知が正しく届かなくなる条件になっています。

それでも非推奨ではありません。UIRequiresFullScreen のドキュメントはiOS 9.0とiPadOS 9.0で利用可能と示すのみで、非推奨・利用不可・ベータのいずれの印もついていません。³ iOS 3.2から使える UISupportedInterfaceOrientations も同様です。⁴

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

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

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

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

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

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

いま何をすべきか

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

回避策を入れるなら、ビューコントローラ単位のオーバーライドとセットにする。 Info.plist の変更は上限にすぎません。制約は、必要なビューコントローラの supportedInterfaceOrientations へ、iPhoneかiPadかで場合分けしたうえで移す必要があります。

UIRequiresFullScreen は別途点検する。 未解決の問題4件がこれに関わっており、しかもビルド時には何の印も出ません。Info.plist をgrepしてください。iPadアプリだと思っていないターゲットも対象です。問題のひとつは、iPad上で動作するiPhone専用アプリを扱っているからです。

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

動く前にリリースノートを再確認する。 この6件のうち1件は、すでに既知の問題から解決済みへ移っています。本記事は2026年8月2日時点のBeta 4を反映したものです。

押さえておきたいポイント

iPadアプリの開発者へ: - Beta 4では、Appleが「条件ではないはず」と述べているにもかかわらず、宣言済みの向きが依然として連続リサイズの条件になっています。新しい仕様ではなく、回避策のあるバグとして扱ってください。 - 回避策はアプリ全体の向きの上限を広げます。ビューコントローラ単位で supportedInterfaceOrientations のオーバーライドを追加しなければ、iPhone向けビルドが回転し始めます。 - 未解決の4件は、UIRequiresFullScreen がリサイズ更新を離散的ではなく連続的に届けてしまう問題です。

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

よくある質問

宣言済みの向きは、もう連続リサイズの条件ではなくなったのですか？

Beta 4ではまだです。Appleは「iOS 27以降、サポートするインターフェースの向きは連続リサイズ対応の条件ではなくなるはずです」と述べていますが、その記述を既知の問題として掲載しています。現在の挙動が、依然として向きを条件にしているからです。¹

実際の回避策は何ですか？

UISupportedInterfaceOrientations で4種類のインターフェースの向きをすべて宣言することです。¹ あわせて、制約を保つ必要のあるビューコントローラには supportedInterfaceOrientations のオーバーライドを入れてください。システムは、アプリ全体の集合と各ビューコントローラの集合の共通部分を取るからです。²

iPhone向けのビルドにも影響しますか？

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

UIRequiresFullScreen は非推奨ですか？

いいえ。ドキュメントはiOSとiPadOSの9.0で利用可能と示すのみで、非推奨の印はついていません。³ ただし、ここで挙げた未解決の問題のうち4件がこのキーに関わっています。非推奨の印がないことを、推奨の証と読むべきではありません。

Appleがこの制約を修正したら、回避策は外すべきですか？

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

避けたい失敗は、その逆です。Info.plist を狭め直したときに、撮影画面を正しい向きに保っていたのがそのオーバーライドだけだった、と忘れてしまうことです。

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

iPadでウィンドウをリサイズし、レイアウトがドラッグに追従するか、最後にカクッと収まるかを見てください。追従するなら連続リサイズ対応です。カクッと収まるなら、2点を確認します。動的なリサイズから完全に降りる UIRequiresFullScreen が設定されていないか、そして UISupportedInterfaceOrientations が4種類の向きをすべて並べているか。後者が、この既知の問題が述べている条件です。¹³

古いSDKでビルドすれば、これらは避けられますか？

各項目の条件は、iOS 27 SDKでビルドすることです。¹ 古いSDKならこれら固有の問題は避けられますが、いずれ来る変更を防ぐわけではなく、先送りするだけです。

出典