iOS resizability のデザイン思想：App は自分がどこで動いているかを知らなくていい

iOS resizability とは、App のウィンドウをデスクトップアプリのようにユーザーが端からつかんで自由にドラッグし、大きさを変えられることを指す。この変化に対する Apple のデザイン思想は、一行に圧縮できる——App は、自分がどのデバイスで、どの向きで、どの画面の上で動いているかに関心を持たない。持つのは「今、どれだけの空間を使えるか」だけである。 あなたが決めるのは「空間が広いときにどう並べ、狭いときにどう並ぶか」という二つの論理。システムは、その論理をすべてのデバイス、すべてのウィンドウサイズ、すべての折りたたみ状態に適用する。

これは月並みな API の更新ではない。iOS が生まれて以来のレイアウト范式の切り替えである。本記事では resizability のデザイン思想を五つの原則に分解し、それぞれを UIKit と SwiftUI のコードに落とし、最後にそのまま実行できる移行ロードマップとテストマトリックスを置く。

文中のシグネチャは Xcode 27.1 の iOS 27.1 SDK で照合してある。挙動の根拠は Apple の公式ドキュメントと WWDC のセッションで、出典は末尾に挙げる。本文はその資料の言い換えと工学的な整理であり、いずれかのページの翻訳ではない。

一、iOS 26 から 27 へ：resizability はどう既定になったか

デザイン思想の前に、時間線を追う。「以前のやり方」がなぜ足りなくなったかがわかる。

この線を一言でまとめる：ウィンドウサイズは「列挙値」から「連続値」になった。 昔、App が相手にしていたのは 375、393、414、768、1024 という数個の離散段だった。今はユーザーの指がウィンドウ端をつまんで一度ドラッグすれば、幅は 320 から画面の上限までの任意の数値になりうる。離散段に合わせて書き固めたレイアウトは、連続値の前では必ず壊れる。

二、デザイン思想その一：「デバイス思考」から「空間思考」へ

古いレイアウト知識のほとんどは、デバイス思考の上に成り立っている。これは iPhone で、横を向いているからこう並べる。これは iPad だから二段に分ける。resizability は、この思考をまるごと取り替えることを求める。

空間思考の最も平たい表現は WWDC から来ている。プラットフォームごと、ウィンドウサイズごとに個別にデザインする必要はない。コンテンツが「余裕があるときどう振る舞い、足りないときどう振る舞うか」を一度定義すれば、システムがその論理をすべてのアスペクト比に適用する。画面の回転は、その論理の一度のトリガーにすぎず、ウィンドウのドラッグ、分割表示、折りたたみの展開と本質的に変わらない——それらは最終的にすべて同じ一つのことに帰着する。使える空間のサイズが変わった。

三、デザイン思想その二：size class は新しい共通語

デバイス思考が退いたあと、何がその棒を受け取るのか。size class である。それは空間に対するフレームワークの定性判断だ。二本の軸、各軸に二つの語——compact は「きつい」、regular は「余裕がある」を表す。

• horizontal 軸は左右を見る。compact なら一段の縦積みにすべきで、regular になって初めて段組み、横並び、サイドバーが正直に成立する。

• vertical 軸は上下を見る。compact では上下の chrome（タブバー、ツールバー）が収まらず、システムは横並びのタブバーを縦に移す。regular なら上下のバーを同時に置ける。

SwiftUI での読み出し：

@Environment(\.horizontalSizeClass) private var hSize  // UserInterfaceSizeClass?
@Environment(\.verticalSizeClass) private var vSize

if hSize == .regular {
    // 左右に余裕：段組み / サイドバー / 二列
} else {
    // 左右がきつい：一段の縦積み
}

UIKit では traitCollection.horizontalSizeClass が同じ役目を担い、registerForTraitChanges で変化を正確に購読できる。

この記事で最も重要な表が次にある——size class とデバイス・向きは一対一ではない：

この表を三度読めば、二つの直感に反する結論が浮かぶ。「iPhone で動いている」ことはもはや compact を意味しない（ウィンドウを大きくすれば regular だ）。「iPad で動いている」ことももはや regular を意味しない（Slide Over は compact だ）。デバイスの種類も画面の向きも「今どのレイアウトを使うべきか」には答えられない。実行時に size class に尋ねるだけだ。

この表は古い思い込みも正す。画面を回すことは「デバイスが変わった」のではない。回すことは (H, V) の組を (compact, regular) から (compact, compact) に切り替え、bounds を一度変えるだけだ。レイアウトコードの構造は動かない。動くのは入力だけだ。「向き」をレイアウト概念として扱っていた時代、それはいつも代理変数だった。今や代理はなく、残るのは空間だけである。

size class の断崖：なぜ第二段が必要か

size class は二値で、粗くて「嘘をつく」。断崖を見よう。iPad 全画面の 1024pt と、分割半分の 507pt はどちらも (regular, regular) だ——しかし前者にはサイドバーが収まり、後者には収まらない。二つの語は「何列か、どれくらいの大きさか、幅を制限するか」といった程度の問題に答えられない。

だから成熟した做法は二段のリレーである。size class は方向の問題（一段か分割か）に答え、工学的な策略は程度の問題（何列か、Hero の大きさ、幅制限）に答える。 第二段はたいてい実測のコンテナ幅で分档する。たとえば広い画面では本文を読みやすい行幅に制限したり、コンテンツの最小サイズからグリッドの列数を決めたりする。iOS 17 以降、SwiftUI では onGeometryChange でコンテナサイズを直接実測してこの判断に使える。GeometryReader に頼る必要はない。

四、デザイン思想その三：機能はサイズで変わらない。変わるのは「見える量」だけ

これは Human Interface Guidelines の、見落とされやすく、しかし極めて重要な原則である。size class が変わっても機能の集合は変わらない。変わるのは「一度に見られる量」だけだ。

広い画面ではタブバーがサイドバーに展開し、二段目の目的地を現す。狭いウィンドウでは優先度の低いツール項目がオーバーフローメニューに収まり、それでも一度のタップで到達できる。収納は並べ替えであって、削除ではない。 広いレイアウトで使える操作が、狭い画面で忽然と消えるなら、それは自適応ではなく機能の欠損だ。同様に、縦横の間で「この画面は一つの向きでしか完全に操作できない」という設計があってはならない。縦でできることは、横でも頭から尾まで通るべきだ。

プロダクト設計者への暗黙の要求はこうだ。情報設計の段階で、すべての要素に優先度を書き込む。共有や主操作といった高優先度の項目は、あらゆるサイズで常駐する。保存や二次的な設定といった低優先度の項目は、広いときは常駐し、狭いときはオーバーフローに入る。システムコンポーネントの Visibility Priority 機構がやっているのは、まさにこれである。

五、デザイン思想その四：min / max サイズは衝突防止であり、縮放の拒否ではない

UIKit ではシーンに最小・最大サイズを宣言できる。しかし語義をはっきりさせておく。この二つの値の存在理由は、小さいサイズで要素が互いを覆わないように、大きいサイズで緩みすぎないようにするためであって、ユーザーに「これ以上小さくなるな」というハードルを設けるためではない。 ウィンドウが任意のサイズにドラッグできる以上、あなたの責任は、どのサイズでもコンテンツを少なくとも使えて、読めて、重ならない状態に保つことだ。あるサイズで必ず壊れるなら、あなたの最小サイズ宣言が欲張りすぎたか、レイアウト自体がまだ本当に自適応していないかのどちらかだ。

シーン接続時に宣言する：

func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
           options: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene else { return }

    // 下限：これより小さくなると要素が重なり始める
    // 上限：これより大きくなるとレイアウトが緩む
    windowScene.sizeRestrictions?.minimumSize = CGSize(width: 320, height: 480)
}

これに付きまとう古い貸しがある。UIRequiresFullScreen は非推奨で、それを保持する App は縮放から抜けられない。新しい表示サイズを自動的に手放すことになる。iOS 26 SDK 以降、App は新しい画面のためにコードを書き換えたり再提出したりする必要がない。システムが自動的に適応する——自分で戸に鍵をかけない限りは。

六、デザイン思想その五：システムコンポーネントに働かせる

resizability の時代で最も省力な策略は、並べ替えの仕事をシステムコンポーネントに任せることだ。任意のアスペクト比に対する彼らの処理は、手書きのレイアウトよりずっと頑健である。

• タブバー / ツールバー：ウィンドウが広がるとタブのアイコンがラベルと同じ行に並び、バーをコンパクトに保つ。狭くなると優先度の低いツール項目がオーバーフローメニューに流れ込む。ニュース系 App では「共有」をあらゆるサイズで釘付けにでき、「保存」は狭いときだけオーバーフローさせる——Visibility Priority で宣言するだけで、レイアウトコードは一行も要らない。

• サイドバー：iPadOS 26 以降、iPhone App も空間が許すときサイドバーレイアウトを選べる。sidebar.isAvailable で「今の空間で表示できるか」を確かめてから請求する。

• NavigationSplitView：iOS 26 以降、列は空間に応じて自動的に現れたり消えたりする。列の可視性を手で管理する必要はもうない。

• Liquid Glass のシステムマテリアル：iOS 27 では改良された拡散と縁の分離を得る。再コンパイルしなくても享受できる。

あなた自身の UI には、ここでたった一つの仕事がある。これらの部品と戦うな、ということだ。自前のトップバーは、ウィンドウ左上の閉じる・最小化コントロールを避けなければならない（水平の角適応を持つレイアウトガイドを使う）。タブバーが常に下部に、ツールバーが常かに上部にあると仮定してはならない——それらの形そのものが空間とともに変わるのだから。

七、UIKit での実装：シーン設定とジオメトリ応答

シーンは resizability の地盤である。各シーンは自分の UI インスタンスと状態を独立して管理し、「この UI がどこに、どれだけの大きさで表示されているか」という文脈を供給する。iOS 27 以降、最新 SDK でビルドする App は UIScene ライフサイクルを採用しなければならない。これは任意ではない。

そのまま写せるシーンデリゲートの骨組み：

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
               options: UIScene.ConnectionOptions) {
        guard let windowScene = scene as? UIWindowScene else { return }

        // 1) サイズ能力の宣言：衝突防止。縮放の拒否ではない
        windowScene.sizeRestrictions?.minimumSize = CGSize(width: 320, height: 480)

        // 2) ウィンドウはシーンに掛ける。UIWindow(frame: UIScreen.main.bounds) は禁止
        let window = UIWindow(windowScene: windowScene)
        window.rootViewController = AdaptiveRootController()
        self.window = window
        window.makeKeyAndVisible()
    }

    // 3) ジオメトリ変化のコールバック：ドラッグ、分割、折りたたみ展開、外部画面の切り替えがすべてここを通る
    func windowScene(_ windowScene: UIWindowScene,
                     didUpdateEffectiveGeometry previous: UIWindowScene.Geometry) {
        let geometry = windowScene.effectiveGeometry
        let size = geometry.coordinateSpace.bounds.size

        // isInteractivelyResizing が true は、ユーザーがまだ端をつまんでドラッグ中であることを意味する
        // 重い仕事（リソースの再構築、チャートの再計算）は指を離したあとに一度でやる。コマ落としでレンダリングしない
        if !geometry.isInteractivelyResizing,
           size != previous.coordinateSpace.bounds.size {
            AssetStore.shared.rebuild(for: size)
        }
    }

    // 4) iPadOS 26+ のウィンドウボタン（閉じる / 最小化）のスタイル偏好
    func preferredWindowingControlStyle(for scene: UIWindowScene)
        -> UIWindowScene.WindowingControlStyle {
        .unified
    }
}

展開すべき要点が三つある。

isInteractivelyResizing はドラッグ性能の生命線である。 ユーザーがウィンドウをドラッグする間、システムはジオメトリ変化を連続的に報告する。ゲームや App が中間のサイズごとにレンダリングリソースを再構築すれば、フレームレートはその場で崩れる。標準的な姿勢は、ドラッグ中は軽い更新（制約、字級の変更）だけを行い、指を離したあとに重い仕事を一度で済ませることだ。

画面やサイズを取るときに UIScreen.main を通ってはいけない。 iPhone ミラーリングや外部画面の場面では main screen は誤りである。正しい出所は view.window?.windowScene?.screen、シーンの effectiveGeometry、またはビュー自身の view.bounds だ。

ウィンドウコントロールの回避。 iPadOS 26 以降、シーンの左上には閉じる・最小化のコントロールがある。自前のトップバーは containerView.layoutGuide(for: .margins(cornerAdaptation: .horizontal)) に制約すべきだ。さもないとユーザーはあなたの最初のボタンをタップできない。

八、ビュー層：三つの古いモードを消す

自適応な UIKit ビューコードの本質は、一回の「三つの置き換え」である。

置き換えたあとは、trait の変化がレイアウトを駆動する：

class AdaptiveRootController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // size class が変わったら並べ替え。自動追跡が覆えないキャッシュ無効化も登録で受け持つ
        registerForTraitChanges([UITraitHorizontalSizeClass.self,
                                 UITraitVerticalSizeClass.self]) { (vc: Self, _) in
            vc.applyLayout()
        }
    }

    private func applyLayout() {
        switch (traitCollection.horizontalSizeClass, traitCollection.verticalSizeClass) {
        case (.regular, _):   useSidebarLayout()
        case (.compact, _):   useStackedLayout()
        default:              useStackedLayout()
        }
    }

    override func viewDidLayoutSubviews() {
        super.viewDidLayoutSubviews()
        // size class より細かい判断が必要なときは、自身の使えるサイズを使う
        fineTune(for: view.bounds.size)
    }
}

viewDidLayoutSubviews / layoutSubviews が効き続けることに注意しよう。size class が発火させるのは「構造の並べ替え」で、bounds の変化が発火させるのは「細粒度の微調整」だ。一度きりの onAppear / viewDidLoad でサイズを読んで取っておくコードは、縮小が始まってから最初に時代遅れになる。

九、SwiftUI との対照：多くは自動、要所だけ補強

SwiftUI で書いた App は resizability で得をする。Xcode 27 で再コンパイルすれば、ウィンドウ縮小のサポートは自動的に有効になり、採択すべき新 API はなく、Liquid Glass の新マテリアルも自動的に継承する。しかし「自動」は「点検不要」ではない。以下が SwiftUI 側の補強ツールボックスを構成する。

• @Environment(\.horizontalSizeClass) / verticalSizeClass：UIKit の trait に対応し、方向の問題に答える。

• onGeometryChange(for:of:action:)：コンテナサイズを実測し、程度の問題に答える。GeometryReader の貪欲な占有を起こさずに読むことができ、派生値が本当に変わったときだけアクションを呼ぶ。ドラッグ途中の中間態を天然に濾過する。

• ViewThatFits：「収まるものを最初から順に使う」という宣言的な書き方。幅によって並べ替えが変わるコンテンツに向く。

• containerRelativeFrame()：絶対的な点数ではなくコンテナの比率で寸法を決める。背景の延展領域を書くときに特に楽ができる。

• NavigationSplitView：iOS 26 以降、列幅と列の可視性が自適応する。その外側に手作業の列管理をもう一层被せないこと。

• .windowResizability(.contentMinSize)：SwiftUI シーンが最小サイズを宣言する入口で、UIKit の sizeRestrictions?.minimumSize と等価だ。

典型的な二段リレーの書き方：

struct DashboardView: View {
    @Environment(\.horizontalSizeClass) private var hSize
    @State private var columnCount = 1

    var body: some View {
        ScrollView {
            MetricGrid(columns: columnCount)
        }
        // 第一段：size class が一段か分割かの世界観を決める
        .onChange(of: hSize) { _, new in
            usesSidebar = (new == .regular)
        }
        // 第二段：実測幅がグリッドの列数を決める。どちらも regular な 507 と 1024 を覆う
        .onGeometryChange(for: CGFloat.self) { $0.size.width } action: { _, width in
            columnCount = AdaptiveWindowLayoutPolicy.tier(for: width).columns
        }
    }
}

十、Info.plist と Launch Screen の赤線

移行リストには工学的な設定に由来する二本の赤線がある。どちらを見落としても、爆発するのはリリース直前だ。

1. UIRequiresFullScreen は処理しなければならない。 非推奨で、かつ保持する App は縮放に参加できない。消すか、歴史的な互換诉求が本当にあるなら UIRequiresFullScreenIgnoredStartingWithVersion でどのバージョンからそのキーを無視するかを明示する。ゲーム系 App はこの結果として discrete resizing に入る——ドラッグを終えるたびにサイズに一致する新しい画面構成に切り替わり、full-quality なレンダリングを保つ。

2. Launch Screen は必須になった。 iOS 27 SDK 以降、Launch Screen を設定していない App は App Store の提出を通過できない（TN3208）。SwiftUI 工程では、これはたいてい最小限の起動画面設定を補うことを意味する。裸で走り続けることではない。

十一、アンチパターン早見表

コードをいじる前に、まず全文をこれらのパターンで検索しよう。見つかった一つひとつが返済待ちの借りだ。

十二、移行ロードマップ

リスクと収益で並べた四歩：

第一段・雷を外す（最初に。リリースを塞ぐ）：UIRequiresFullScreen を削除、Launch Screen を補い、UIScene ライフサイクルが使われていることを確認する。この三項は設計の質とは関係のないハードな門槛だ。落とせば審査やビルドで直接つまずく。

第二段・アンチパターンを消す：第十一節の表で UIScreen.main、idiom / 向きの分岐、手製の幅ブレークポイントを全文置き換える。置き換えの目標は「動く」ことではなく、レイアウトの入力源を空間の語義に統一することだ。

第三段・二段の分档を補う：内容型の画面に「size class が方向を定め + 実測幅が程度を定める」という策略層を作り、すべての裸の閾値を一カ所に収束させる。広い画面では本文の幅制限に注意する。一行が 85 字を超えるのは可読性のバグだ。

第四段・テストの体系化：第十三節のマトリックスでサイズごとに順に検証し、結果を回帰項目として固定する。

十三、テストマトリックス

resizability のテストはデバイス清单ではやらない。空間の形でやる。どの形でも問いに答えなければならない。機能は完全か、コンテンツは切られていないか、chrome はタップできるか。

ツール側では、Xcode 27 の Device Hub と Previews にウィンドウの resize モードがあり、端をドラッグすれば連続的にサイズを変えられる。ミラーリングと外部画面は実機で検証する。

十四、よくある質問

なぜ私の iPhone App は急にウィンドウを大きくできるようになったのですか？

バグではない。iOS 26 SDK 以降の新しい振る舞いだ。iPad 上と Mac の iPhone ミラーリングの中で動く iPhone App は、自由に大きさを変えられるウィンドウを持つ。対応するレイアウト信号は、horizontal size class が compact から regular に切り替わることである。以前の if idiom == .phone というコードは、そうしたウィンドウの中で誤ったレイアウトを出す。size class に尋ねるように変えること。

size class で足りませんか。なぜ幅も実測するのですか？

足りない。そして断崖は実在する。iPad 全画面と分割の半分はどちらも (regular, regular) だが、幅は一倍違う。片方にはサイドバーが収まり、片方には収まらない。size class は方向（一段 / 分割）を定め、実測幅は程度（何列 / どれくらい）を定める。両者はリレーであり、二択ではない。

minimumSize を宣言すれば、ユーザーはこれ以上小さくドラッグできなくなりますか？

minimumSize は「あなたの内容が乱れ始める」下限の設定であり、ユーザーはこの下限まで来るとそれ以上ドラッグできない——これは衝突防止の機構であり、縮小を拒否する機能の門禁ではない。本当に保つべきは、minimumSize から maximumSize までのどのサイズでも App が使えることだ。それができないなら、自適応が書き終わっていないということであって、最小値を大きくすればいいという話ではない。

UIRequiresFullScreen を削除するとどうなりますか？

削除すると App はウィンドウ縮小に参加する。これは iOS 26+ の既定の予想だ。古いバージョンとの互換が心配なら UIRequiresFullScreenIgnoredStartingWithVersion で無視し始めるバージョンを指定できる。ゲームのレンダリングの質が心配なら discrete resizing に入り、サイズに一致する画面構成に切り替わる。かえって画質を保ちやすい。

SwiftUI アプリは何をすればいいですか？

再コンパイルすれば縮小サポートが得られ、採択すべき新 API はない。点検すべきはこうだ。UIScreen 時代の仮定に依存するコードがないか、サイズの判断が size class だけを使っていて実測の補強がないか、固定 frame の部品が極端なアスペクト比で裂けないか。フレームワークが管轄するのは巨視だ。裂ける部品は、たいていあなた自身が書き固めたあれである。

参考と参照

公式の出所：WWDC25 session 282「Make your UIKit app more flexible」、WWDC26 session 278「Modernize your UIKit app」、Human Interface Guidelines の Layout と Designing for iPhone Duo、UISceneSizeRestrictions と UIWindowScene.Geometry のドキュメント、技術説明 TN3192（UIRequiresFullScreen キーからの移行） と TN3208（Launch Screen の要件）。

サイト内の参照：この思想がある具体的なデバイスに端から端まで落ちる様子を見たいなら、iPhone Duo の画面：レイアウトからコードまで を読むとよい。「データも空間に合わせて縮む」もう一面を理解したければ、個人ベースラインのガイド を見る。製品と適応に関するさらなる問いはよくある質問 にある。