※ 本記事は、WWDCで公開されたセッション内容をもとに、将来的なiPhoneのフォームファクター変化について考察するものです。Appleによる未発表製品の発表・発売を示すものではありません。

こんにちは、システム開発部のK.Iです。

WWDC2026 の Keynote で「foldable」「folding」「hinge」といった単語が発せられることは一度もありませんでした。Apple Vision Pro のような「One more thing」もなく、ブルームバーグのニュースなどで噂されている折りたたみ型 iPhone が公式にアナウンスされることもありませんでした。

しかし、各種開発者向けセッションの内容を確認していくと、そこには一本の共通メッセージが流れていました。それは「iPhone アプリを完全にリサイズ可能(resizable)にする」という、iOS が誕生して以来最大規模と思われるレイアウト思想の転換です。

この記事では、iOS アプリ開発者の視点で WWDC2026 で何が変わるのか、そしてそれが何を示唆しているのかを整理してみます。

iOS 27 で何が起きるのか

もっとも手がかりが多かったのはセッション278「Modernize your UIKit app」です。冒頭で発表者はこう述べています。

“iPhone apps are now fully resizable in iPhone Mirroring on Mac and when running on iPad.”
(iPhone アプリは、Mac 上の iPhone Mirroring と iPad 上での実行時に、完全にリサイズ可能になりました)

「iPhone Mirroring と iPad 上で」という表向きの理由は控えめですが、続いて挙げられる要件は、毎年の「非推奨 API の整理」とは明らかに異なる規模です。整理すると、要件は大きく2つのグループに分かれています。

WWDC25 セッション282「Make your UIKit app more flexible」で予告されていた内容の再通知:

  • UIScene ライフサイクル必須化(iOS 26 の次のメジャーリリースで必須化、と WWDC25 で予告済み)
  • UIRequiresFullscreen 非推奨化(WWDC25 で予告済み)
  • UIScreen.main 参照の除去要求

iOS 27 で新たに打ち出された、WWDC25 では触れられなかった要件:

  • iPhone アプリが iPhone Mirroring・iPad 上で完全にリサイズ可能になる
  • userInterfaceIdiom をレイアウト判断に使うべきではない
  • interfaceOrientation もレイアウト判断に使うべきではない
  • UIRequiresFullscreen が非推奨から「discrete resizing を有効にする」挙動に変更
  • Device Hub / Xcode Previews に「自由リサイズモード」が追加

“Interface orientation also is no longer useful for layout decisions. In iOS 27, an app’s supported interface orientation is a preference provided to the system. It will be ignored when your app is running in a resizable environment.”
(画面方向もレイアウト判断には役立たなくなりました。iOS 27 では、サポートする画面方向はシステムへの「希望」として扱われ、リサイズ可能な環境下では無視されます)

scene 必須化は計画通りとしても、idiom と orientation をレイアウト判断に使わない方向へ寄せる、という要求は、これまでの iPad 対応の延長線上では説明がつきにくいですね。しかも WWDC25 では「iPhone アプリの完全 resizable 化」には一切触れられておらず、iOS 27 で唐突に盛り込まれた点が気になるところです。

プラットフォーム方針の転換

セッション102「Platforms State of the Union」では、この方針転換がもっとも象徴的な一文で表明されていました。

“Now, instead of designing for specific devices and orientations, you’re designing for a dynamic range of sizes and aspect ratios.”
(今後は、特定のデバイスや画面の向きに合わせて設計するのではなく、サイズとアスペクト比の動的な範囲に向けて設計することになります)

「dynamic range of sizes and aspect ratios(サイズとアスペクト比の動的な範囲)」という表現がポイントです。iPhone Mirroring でユーザーが自由にウィンドウをリサイズできるとはいえ、「動的な範囲」を設計前提にせよと全開発者に求めるほどの幅広さは、従来の想定にはなかったのではないでしょうか。

“Once you rebuild with the latest SDK, your app is automatically opted in to resizability.”
(最新 SDK で再ビルドするだけで、アプリは自動的に resizability に opt-in します)

最新 SDK で再ビルドした時点で自動 opt-in される、というのも特徴的です。対応の選択肢はなく、全アプリが一律に対象になります。

SwiftUI 側も同じ方針

SwiftUI を見ても方針は同じです。セッション269「What’s new in SwiftUI」ではこう述べられています。

“And on iOS 27, our iPhone app becomes resizable too.”
(そして iOS 27 では、我々の iPhone アプリも resizable になります)

“In Xcode 27, Live Previews now have resize handles that allow you to test how your app responds to being interactively resized.”
(Xcode 27 では、Live Previews に resize ハンドルが追加され、インタラクティブにリサイズされたときのアプリの挙動をテストできます)

ツールバー周りには、サイズ変化に追従させるための新しい API が複数追加されました。visibilityPriority で重要ボタンを優先表示させ、ToolbarOverflowMenu で収まらない項目をオーバーフローに回し、topBarPinnedTrailing で Share ボタンを常に trailing にピン留めする、といった具合です。

StickerPageView()
    .toolbar {
        ToolbarItemGroup {
            UndoButton()
            RedoButton()
        }
        .visibilityPriority(.high)
        ToolbarOverflowMenu {
            ChoosePhotoButton()
            ExportAsImageButton()
        }
        ToolbarItem(placement: .topBarPinnedTrailing) {
            ShareButton()
        }
    }

「ウィンドウや画面サイズに関わらずアプリの重要な機能にアクセスできること」が、明示的な設計要件として打ち出されていますね。

変更規模の違和感

ここまでを整理すると、Apple が公式に掲げる理由は「iPhone Mirroring と iPad 上での iPhone アプリのリサイズ」です。しかし、冷静に眺めると、この理由に対して変更規模が明らかに過剰ではないか、という違和感が生じます。

#違和感ポイント理由
1WWDC25 予告を上回る iOS 27 の追加要件scene 必須化自体は前年予告済みだが、idiom/orientation 排除、iPhone アプリの完全 resizable 化、Device Hub の自由リサイズまで含めると「2 年がかりの準備」に見える規模で、単なる Mac ミラーリング対応の枠を超えている
2ゲーム(UIRequiresFullscreen)まで対象discrete resizing で「サポートする向きを尊重しつつリサイズ」とする理由が、単なる Mac ミラーリングでは説明しづらい
3idiom をレイアウト判断に使わない方針の徹底度iPad 対応としては既に size class ベース運用が推奨済み。改めて全開発者に「idiom ではなく size class を使う」ことを求める追加の動機がある
4「any size」「dynamic range of aspect ratios」の強調iPhone Mirroring の解像度バリエーションを想定するには過剰な表現
5Device Hub の「自由リサイズ」Mac ミラーリング解像度をテストするだけならプリセットで十分なはずが、端をドラッグして自由変形できる設計

これら一つひとつは決定的な証拠ではありません。しかし、すべてが同じ方向を向いていること自体が情報として意味を持っていますね。

歴史的パターンとの照合

Apple はこれまで、新しいフォームファクタを投入する前に、表向きの理由をつけて事前に API 整備を行ってきました。

  • iPad(2010)導入前: iPhone OS 3.x で Universal 化の基礎と UISplitViewController の整備
  • iPhone X(2017)導入前: iOS 11 で safeAreaLayoutGuide を導入し、ノッチ対応の基盤を準備
  • Apple Vision Pro(2024)導入前: iOS 17 / iPadOS 17 で UIWindowScene のマルチウィンドウ拡張など、visionOS に通じる API を整備

今回は、2年以上かけて段階的に準備が進められているように見えます。

  • WWDC25(2025年6月): セッション282「Make your UIKit app more flexible」で UIScene 必須化と UIRequiresFullscreen 非推奨化を予告。このセッションには、明確に新しいフォームファクタを示唆する一文が含まれていました。

    “There is another compatibility mode, specifically for new hardware. Previously, when new hardware was released with a different screen size, the system would scale or letterbox your app’s UI… Once you build and submit with the iOS 26 SDK, the system will no longer scale or letterbox your app’s UI for a new screen size.”
    (もう1つの互換モードは、新しいハードウェア向けのものです。以前は、異なる画面サイズのハードウェアがリリースされた際、システムはアプリの UI をスケーリングまたはレターボックス表示していました。iOS 26 SDK でビルド・提出すれば、システムは新画面サイズにあたってスケーリング・レターボックスを行わなくなります)

  • iOS 26(2025年秋): Liquid Glass 導入、iPadOS 26 の windowing control、UISplitViewController のインタラクティブな column resizing
  • WWDC26 / iOS 27(2026年): 予告通り scene 必須化を実施、加えて idiom/orientation 排除、iPhone アプリの完全 resizable 化、Device Hub の自由リサイズを追加

「新しい画面サイズのハードウェア」に向けて、letterbox 互換モードを外すところから始まり、scene 基盤の整備、レイアウト思想の転換へと、継続的なステップが踏まれています。この継続性は、新しいフォームファクタの可能性を考える上で無視できない材料です。

折りたたみ iPhone が来るとしたら

ここからは完全に推測の領域ですが、タイムラインを考えてみましょう。

Apple は毎年、9 月の新 OS リリースに対して、翌年 4 月に「最新 SDK ビルド必須化」を App Store 要件として課してきました(例: iOS 18 SDK ビルドが必須化されたのは 2025 年春)。iOS 27 SDK ビルドの必須化は、例年通りなら 2027 年春頃と想定されます。

もし折りたたみ iPhone が例年の iPhone 発売時期(9 月)に投入されると仮定すると、話が変わってきます。フォームファクタ固有の調整、とくに idiom/orientation の排除、UIRequiresFullscreen 対応、ツールバー新 API の採用が未完了のアプリは、新デバイス投入時の体験を損なうことになります。つまり「4 月の SDK 必須化の期限を待っていたら間に合わない」開発チームは、iOS 27 のリリース時期には対応を完了させておく必要がある、ということになりますね。

実際、WWDC2026 で Apple が取っている行動は、このタイムライン観点と整合しています。UIScene を必須化し、Coding Agent 向けの「app modernization skill」を提供して自動移行を促し、Device Hub で自由リサイズを可能にしているのは、開発者に早急に準備を促す意図があるように見えます。Liquid Glass も iOS 26 で導入され iOS 27 で更新されたことを踏まえると、Liquid Glass 対応と resizability 対応は並行して進めるしかない、というのが iOS 開発者側の現実的な立場になりそうです。

もっとも、Apple が WWDC25 の段階で「新しい画面サイズのハードウェア」を明示的に前提にしていたことを考えると、投入時期は 2027 年秋(iOS 28)の可能性も十分にあります。その場合でも、iOS 27 での大規模な API 整備は「1 年前の基盤完成」として辻褄が合います。いずれにせよ、来年の Apple 動向を注視する価値はあるでしょう。

周辺の手がかり

主要セッション以外にも、画面サイズ変動を前提とした変更が見えます。

セッション223「Live Activities essentials」では、iOS 27 で Dynamic Island が landscape でも表示されるようになり、新しい環境値 isDynamicIslandLimitedInWidth が追加されました。「landscape では幅方向に成長する余地がない」という状況を明示的にハンドリングさせる設計は、画面形状がこれまで以上に変動する前提と親和性が高いと言えます。

セッション277「WidgetKit foundations」では、systemExtraLargePortrait ファミリが visionOS 26 から iOS / iPadOS 27 にも拡張されました。大きな画面面積を活かすウィジェットサイズを iOS に持ち込む動機として、画面が広くなるフォームファクタは自然な説明になりますね。

おわりに

繰り返しますが、WWDC2026 のいずれのセッションでも「折りたたみ iPhone」という言葉は出てきませんでした。この記事で触れた要素は、すべて「間接的な手がかり」に過ぎません。Apple が公式に挙げる理由は iPhone Mirroring と iPad ですし、それ自体は事実です。

ただ、iOS 27 で進められている API 整備の規模と思想の転換は、その公式理由の枠を明らかに超えています。iOS 27 のリリース時期や来年以降の Apple の発表を、開発者として注視する価値はあると感じています。

折りたたみ iPhone の有無に関わらず、私たち iOS 開発者が iOS 27 で確実に進めるべき作業は以下の 3 点です。

  1. UIScene ライフサイクルへの移行(WWDC25 で予告された必須化が iOS 27 で実施されます。Xcode 27でビルドする未対応アプリは起動しません)
  2. UIScreen.main 参照の除去(windowScene?.screen、traitCollection.displayScale、ビューの bounds への置換)
  3. userInterfaceIdiom / interfaceOrientation によるレイアウト分岐の除去(size class ベースへの統一)

Xcode 27 が Coding Agent 向けに用意している「app modernization skill」を使えば、これらの機械的移行は大幅に自動化できるはずです。早めに着手し、Device Hub の resize mode で想定外のアスペクト比でもレイアウトが崩れないかを確認しておくのが、来年に備えた現実的な一手でしょう。

ここまで読んでいただき、ありがとうございました。

参考・引用元セッション

本記事は WWDC26 公式トランスクリプトに基づく個人の考察であり、Apple Inc. の公式見解を代表するものではありません。



ギャップロを運営しているアップフロンティア株式会社では、一緒に働いてくれる仲間を随時、募集しています。 興味がある！一緒に働いてみたい！という方は下記よりご応募お待ちしております。
採用情報をみる