UIKitのシーン義務化：iOS 27で起動しなくなるもの

Appleの移行ドキュメントは、iOS 27サイクルで最も厳しい要件を一文で言い切っています。「iOS 27、iPadOS 27、Mac Catalyst 27、tvOS 27、visionOS 27以降、最新のSDKでビルドされたアプリは、シーンベースのライフサイクルを採用しなければ起動しません」¹。非推奨でも、警告でも、低速化でもありません。起動しないのです。セッション278も同じく明快に述べています。「UIScene lifecycleは、最新のSDKでビルドする際に必須となりました。これがなければ、アプリケーションはもう起動しません」²。旧来のapp-delegateライフサイクルで動いているすべてのUIKitアプリは、iOS 27 SDKに対してビルドするまでに移行を済ませる必要があり、その警告フェーズはすでに何年も続いてきました。

この要件は、セッション278の2:36で述べられています。

TL;DR

• iOS 27 SDKでビルドされたアプリは、UIKitのシーンベースのライフサイクルを使わなければ起動しません。これはiOS、iPadOS、Mac Catalyst、tvOS、visionOS 27のすべてに及びます¹。古いSDKでビルドされた既存のバイナリは引き続き動作します。壁となるのは、ビルド対象のSDKなのです。
• 段階的に圧力が高められてきました。UIKitはiOS 18.4の時点ですでに移行メッセージのログ出力を開始し、そのメッセージはiOS 26で変更されました。そしてiOS 27で、そのログは起動失敗へと変わります¹。
• 次のいずれかの条件に当てはまる場合は移行が必要です。Info.plistに設定済みのUIApplicationSceneManifestキーがない場合、またはapp delegateがシーン構成メソッドを実装していない場合です¹。
• 最小限の移行はわずかな作業です。プロパティリストへのシーンマニフェストのエントリ追加、または動的構成のためのdelegateメソッドの実装で済みます。複数シーンのサポートは引き続き任意です¹。
• Xcode 27には、アプリをシーンライフサイクルへ変換し、メインスクリーンや画面方向のチェックを書き換え、複雑なタスクでは確認のための質問を行い、1セッションで終わらない作業にはコメントを残す、アプリモダナイゼーション用のエージェントスキルが付属します²。

非推奨ではなく、義務

27サイクルには、置き換え先が成熟した1リリース後にAPIを刈り取るというパターンがあります。ImageCreatorはiOS 27で動作しなくなり、MXMetricManagerは置き換え先がリリースされたのと同じ週に27.0の非推奨を背負いました。シーン要件は、機能ではなくアプリ全体を門番として塞ぐため、このパターンの中で最も重大なものです。Image Playgroundに一切触れないアプリは、この秋に失うものは何もありません。しかし、シーンライフサイクルを無視するアプリは、新しいSDKでビルドした日に起動しなくなります。

このタイムラインは、Appleが施行に踏み切るまでにどれほどの猶予を費やしたかを物語っています。iOS 18.4、iPadOS 18.4、Mac Catalyst 18.4、tvOS 18.4、visionOS 2.4から、UIKitは未移行のアプリに対してメッセージをログに記録し始め、26リリースではそのメッセージが変更されました¹。2リリース分の警告を経て、床が抜けるわけです。概念的な土台はさらに古く、セッションはBruce Niloがデバイスの回転を「アニメーション化されたbounds変更にすぎない」と位置づけたWWDC 2014にまで遡り、リサイズ可能なiPadウィンドウとリサイズ可能なiPhoneアプリの登場により「今日この洞察はかつてないほど重要になっている」と指摘しています²。

正確に述べておくべき境界が一つあります。この要件が拘束するのは「最新のSDKでビルドされた」アプリです¹。iOS 26以前のSDKに対してビルドされた出荷済みのバイナリは引き続き起動します。新機能を取り込もうとXcode 27のSDKで再ビルドした瞬間、シーンライフサイクルがそれに付いてきます。

本当に移行が必要なのか？

ドキュメントは2つの条件によるテストを示しています。情報プロパティリストにUIApplicationSceneManifestキーがない（または設定済みの構成がない）場合、あるいはapp delegateがシーン構成メソッドを実装していない場合は、移行が必要です¹。2019年以降に開始されたアプリのほとんどはすでにこれをパスしています。Xcodeのテンプレートはそれ以来、シーンベースのプロジェクトを生成してきたからです。この義務に引っかかるのは、いまだにAppDelegateがウィンドウを保持し続けている、長く使われてきたアプリです。

最小限の修正は2つの経路のいずれかです。静的な経路では、プロパティリストにシーン構成付きのUIApplicationSceneManifestキーを追加します。これはターゲットのGeneral設定の「Deployment Info」内にある「Scene manifest」からアクセスできます¹。動的な経路では、代わりにシーン構成のdelegateメソッドを実装します。これは、ユーザーアクティビティに応じてシーンをカスタマイズしたり、異なるシーンロールを扱ったりするアプリ向けです。ドキュメントの例では、セッションのroleプロパティを使ってどのシーンを作成するかを判断しています¹。ストーリーボードからルートビューコントローラを読み込むアプリは、シーンマニフェストにストーリーボード名を含めます。すると、システムがウィンドウシーンとルートビューコントローラを自動的に構成します¹。

この義務が求めていないのは、複数シーンです。ドキュメントは、複数シーンのサポートが引き続き任意であり、データモデルをシーンごとに固有のものへ再構築する必要があるかもしれないと明言しています。有効にする前に、ユーザー体験にメリットがあるかどうかを検討するよう促しています¹。移行するということは、ライフサイクルイベントをアプリレベルからシーンレベルへ移すことを意味します。そこではUIApplicationDelegateがプロセスレベルのイベントを保持し、シーンdelegateがUI固有のイベントを引き受けます¹。構成でつまずきやすい点が一つあります。素のUISceneオブジェクトではなくUIWindowSceneオブジェクトを指定すること、そしてCarPlayのシーンは独自のtemplate-application scene typeを使うことです¹。

なぜ今なのか：すべてがリサイズされる

この義務は、リサイズ可能性を普遍的なものにするのと同じリリースで到来し、セッション278は両者を一つの物語として提示しています。iOSとmacOS 27では、Mac上のiPhone Mirroringのウィンドウは自由にリサイズでき、iPad上で動くiPhone専用アプリは「他のあらゆるiPadアプリと同じように完全にリサイズ可能」になります²。シーンライフサイクルは、セッションの言葉を借りれば「あらゆるアダプティブなアプリの基盤」であり、セッションが修正を求める他のすべての前提条件なのです²。

修正リストは、画面中心の前提の一掃です。シーンが別のディスプレイ上に存在するようになると、メインスクリーンへの参照は誤った情報を返します。そこでセッションは、ウィンドウのウィンドウシーンを通じて画面に動的にアクセスするか、あるいはより望ましくは画面参照を完全に取り除くよう述べています。スクリーンのスケールはtrait collectionのdisplayScaleになり、スクリーンのboundsはウィンドウシーンの実効ジオメトリ、もしくは単に周囲のビューのサイズになります²。自動的なtraitトラッキングが移行を和らげます。システムは、layoutSubviewsのようなレイアウトや描画のメソッド内でどのtraitプロパティが読み取られたかを追跡し、追跡対象のtraitが変化したときにそれらを再度呼び出します²。

長らく使われてきた2つの指標は、レイアウト上の意味を完全に失います。user-interface idiomは「いかなるレイアウト判断においても、もはや意味を持ちません」。iPad上のiPhoneアプリは、phoneのidiomを報告し続けながらも完全にリサイズ可能で動作するからです。そしてサポートされるインターフェース方向は、リサイズ可能な環境ではシステムが無視するただの設定値となり、iPhone Mirroringはウィンドウのアスペクト比にかかわらず常にportraitを報告します²。どちらの置き換え先もsize classesです。ゲームは適用除外ではなく配慮を受けます。UIRequiresFullscreenはiOS 27以降、リサイズ可能な環境のiPhoneでも尊重されますが、その挙動は離散的なリサイズへと変わります。リサイズのたびにシーンを一致する画面構成へ遷移させ、利用可能な空間の中でゲームがフル品質でレンダリングされるようにします²。

このマトリクス全体のテストも、同じサイクルで安価になりました。Device HubとXcode Previewsには、デバイスのエッジを自由にドラッグできる「enter resize mode」が加わります。セッションは、その後にiPhone MirroringとiPadでの実機チェックを行うよう助言しています²。

移行にはエージェントスキルがある

セッションは、この要求の大きさを認めつつ、Xcode 27の答えを指し示して締めくくります。それは、セッションが概説するアダプティブ化のタスクへの「深い理解」を備えた、新しいアプリモダナイゼーションスキルです²。アプリをよりアダプティブにするよう求めると、エージェントはメインスクリーンの呼び出しを、必要に応じて無効化ロジックを伴うtrait-collectionやscene-boundsのチェックへ変換し、インターフェース方向のチェックをsize classesに置き換え、さらには「アプリをシーンライフサイクルを使うように変換さえします」²。複雑なタスクでは確認のための質問を行い、1セッションには大きすぎる作業には、残っているものを示すコメントを残します²。

その配布の流れは、今回のWWDCでのAppleのスキル推進の他の部分とも一致します。xcrun agent skills exportは、他のツールにインポートできるmarkdownファイルを生成します。これはXcode 27のエージェントスキルエクスポートで扱われたのと同じ仕組みです²。SDKによって施行される移行と、その移行を実行するスキルを組み合わせたこの形は、エージェント時代において破壊的変更がどのように吸収されることをAppleが期待しているかの、これまでで最も明快な表現です。プラットフォームが床を引き上げ、ツールがあなたをその上へと運んでくれるのです。

FAQ

既存のアプリはiOS 27で動かなくなりますか？

この要件だけが原因で動かなくなることはありません。この義務は「最新のSDKでビルドされた」アプリに適用されます¹。古いSDKですでに出荷されたバイナリは、iOS 27でも引き続き起動します。失敗が起きるのは、シーンベースのライフサイクルを用意しないまま、iOS 27 SDKに対して再ビルドしたときです。

自分のアプリが影響を受けるかどうかは、どうすればわかりますか？

2つの点を確認してください¹。Info.plistに設定付きのUIApplicationSceneManifestキーがなく、かつapp delegateがシーン構成メソッドを実装していなければ、そのアプリはapp-delegateライフサイクルの上にあり、iOS 27 SDKでビルドすると起動に失敗します。UIKitは、iOS 18.4以降、影響を受けるアプリに対して移行メッセージをログに記録してきました¹。

これは複数ウィンドウのサポートを強制しますか？

いいえ。複数シーンのサポートは引き続き任意であり、データモデルをシーンごとに固有のものにする必要があるかもしれないため、Appleのドキュメントは有効化する前にユーザー体験にメリットがあるかを天秤にかけるよう助言しています¹。この義務が求めるのは、シーンベースのライフサイクルそのものだけです。すなわち、ライフサイクルイベントをグローバルにではなくシーンごとに扱うことです。

エージェントに移行をやってもらえますか？

Xcode 27には、アプリをシーンライフサイクルに変換し、メインスクリーンへの参照を書き換え、画面方向のチェックをsize classesに置き換えられると、セッションが述べるアプリモダナイゼーションスキルが付属します。変更が曖昧な箇所では確認のための質問を行い、終わっていない作業にはコメントを残します²。これはxcrun agent skills exportを通じて他のツールにエクスポートできます²。その出力は、エージェントが書いた他の移行と同じように扱ってください。特に状態の復元やウィンドウのセットアップ周りについて、差分をレビューしましょう。

この義務は、今サイクルのあるテーマを完成させます。すなわち、Appleが27の境界において移行を提案するのではなく施行するというテーマです。これは、ImageCreatorの提供終了が、より小さな範囲で同じ段階的な圧力の高まりを見せた後のことです。エージェントスキルという答えは、Xcode 27はどこへでもエクスポートできるエージェントスキルを搭載するで扱われた、より広いスキルの流れにつながっています。シリーズ全体のハブはApple Ecosystem Seriesです。

参考文献