はじめに

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

WWDC2026 で発表された iOS 27 / Xcode 27 は、例年の「新機能てんこ盛り」とは少し雰囲気が異なるように見えました。iOS 27 SDK でビルドすると、条件を満たさないアプリが「起動しない」、そのビルドを提出すると「リジェクトされる」、さらに「見た目と挙動が変わる」という、後方互換に大きく影響する変更が複数まとめて入ってきました。

Apple がここまで明確に「必須」と示す変更が同時に複数入る年は珍しく、いつもと比較して「そのうちに対応」では済まない感じです。この記事では、通常の iOS アプリを開発しているチームが Xcode 27 対応で必須・実質必須として進める事項と、非推奨化に備えて計画すべき事項を、WWDC2026 のセッションと公式ドキュメントの記述をもとに整理しました。

なお、この記事の内容は 2026 年 7 月 11 日時点の iOS 27 beta 3 / Xcode 27 beta 3 の公式リリースノートやドキュメント、セッショントランスクリプトに基づいています。正式リリースまでに変わる可能性がある点はご了承ください。

想定される対応タイムライン

対応の優先度を判断するために、先に前提となるタイムラインを押さえておきます。

  • 2026年9月（見込み）: iOS 27 / Xcode 27 正式リリース
  • 2027年春（見込み）: App Store へ提出するアプリに iOS 27 SDK(Xcode 27)ビルドが必須化

Apple は毎年、秋の新 OS リリース後、翌年4月頃に「最新 SDK でのビルド」を App Store の提出要件にしてきました（iOS 26 SDK ビルドは 2026 年 4 月 28 日に必須化されています）。例年通りであれば、2027年春には Xcode 27 でのビルド対応が必要になる見込みです。

重要なのは、この記事で扱う変更の多くが「iOS 27 SDK でビルド（再ビルド）したときに初めて有効になる」という点です。ここで扱う SDK リンク条件付きの要件は、原則として iOS 26 SDK 以前でビルド済みのバイナリには適用されません。ただし、これは iOS 27 上で既存バイナリに別の互換性問題が起きないことを保証するものではありません。

期限も項目によって異なります。UIScene は iOS 27 SDK でビルドしたアプリを起動する前、Launch Screen はそのアプリを App Store などへ初めて提出する前に必要です。2027 年春は、例年通りならすべての更新で iOS 27 SDK ビルドが必要になる最終期限の見込みであり、Xcode 27 への移行をそれまで先送りできるという意味ではありません。また、非推奨 API の整理には、すぐの対応が必須ではなく中期的な移行計画として扱えばよい項目も含まれます。

【起動しない】UIScene ライフサイクル必須化

今回の変更で最もインパクトが大きいのがこれです。iOS 27 の公式リリースノートには、UIKit の Deprecations として簡潔にこう書かれています。

“Apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch.”
（最新 SDK でビルドされたアプリは、scene ベースのライフサイクルを採用しなければ起動に失敗します）

警告や機能制限でもなく、「起動しない」です。対象は iOS 27 / iPadOS 27 / Mac Catalyst 27 / tvOS 27 / visionOS 27 の全プラットフォームです。

実はこの必須化は突然の話ではなく、iOS 18.4 の頃からコンソールに「This process does not adopt UIScene lifecycle. This will become an assert in a future version.」というログが出ており、iOS 26 では「UIScene lifecycle will soon be required.」に変わっていました。WWDC25 で予告されていた期限が、予告通りに来た形です。

移行が必要かどうかの判定

とりあえず Xcode 27 でビルドしてシミュレータで起動してみる、という確認方法もありますが、ビルドせずに判定するなら scene configuration の供給方法を確認します。Apple のドキュメントによると、UIKit に有効な scene configuration を次のいずれかの方法で提供する必要があります。

  • Info.plist の UIApplicationSceneManifest → UISceneConfigurations に構成を記述する
  • AppDelegate の application(_:configurationForConnecting:options:) から構成を動的に返す

この2つは代替関係であり、両方の実装が必須ではありません。どちらからも有効な scene configuration を提供していないアプリは移行が必要です。

昔ながらの「AppDelegate + window プロパティ」構成のまま動いているアプリは移行が必要になります。SwiftUI の App プロトコル(@main struct MyApp: App)で書かれたアプリは、内部的に scene ベースで動いているため対応不要です。影響を受けるのは UIKit ベース、とくに長期運用されてきたアプリです。

移行手順

最小構成の移行は次の3ステップです。

1. Info.plist に UIApplicationSceneManifest を追加

<key>UIApplicationSceneManifest</key>
<dict>
    <key>UIApplicationSupportsMultipleScenes</key>
    <false/>
    <key>UISceneConfigurations</key>
    <dict>
        <key>UIWindowSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneConfigurationName</key>
                <string>Default Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
                <key>UISceneStoryboardFile</key>
                <string>Main</string>
            </dict>
        </array>
    </dict>
</dict>

Storyboard を使っている場合は UISceneStoryboardFile を指定すれば、window と rootViewController の構成はシステムがやってくれます。コードで rootViewController を組み立てている場合は次のステップへ。

2. SceneDelegate を実装し、window を scene に紐付ける

import UIKit
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let windowScene = scene as? UIWindowScene else { return }
        let window = UIWindow(windowScene: windowScene)
        window.rootViewController = RootViewController()
        window.makeKeyAndVisible()
        self.window = window
    }
}

ポイントは UIWindow(frame: UIScreen.main.bounds) ではなく UIWindow(windowScene:) を使うことです（後述しますが、UIScreen.main 自体を排除する必要があります）。

3. AppDelegate の UI 系ライフサイクルメソッドを SceneDelegate へ移す

scene 移行後、UIKit は AppDelegate 側の UI 関連イベントを呼ばなくなります。主な対応関係は以下の通りです。

AppDelegate（旧）SceneDelegate（新）
applicationWillEnterForeground(_:)sceneWillEnterForeground(_:)
applicationDidBecomeActive(_:)sceneDidBecomeActive(_:)
applicationWillResignActive(_:)sceneWillResignActive(_:)
applicationDidEnterBackground(_:)sceneDidEnterBackground(_:)
application(_:open:options:)（URL スキーム）scene(_:openURLContexts:)。新規 scene 作成時は connectionOptions.urlContexts
application(_:continue:restorationHandler:)(Universal Links / Handoff)scene(_:continue:)。新規 scene 作成時は connectionOptions.userActivities

application(_:didFinishLaunchingWithOptions:) などプロセスレベルのイベントは引き続き AppDelegate に残ります。「プロセスの寿命は AppDelegate、UI の寿命は SceneDelegate」という役割分担のようです。

ここで見落としやすいのが、URL スキームや Universal Links でアプリがコールドスタートしたケースです。起動済み scene へ渡される場合は scene(_:openURLContexts:) / scene(_:continue:) が呼ばれますが、新しい scene の作成理由として渡される場合は scene(_:willConnectTo:options:) の connectionOptions 側を読む必要があります。

なお、必須なのはあくまで scene ベースのライフサイクル採用であって、マルチシーン対応(UIApplicationSupportsMultipleScenes = true)は必須ではありません。データモデルの再設計が必要になる場合もあるので、ここは無理に踏み込まなくて大丈夫です。

注意したいのは、プッシュ通知やディープリンクまわりの分岐が AppDelegate に集中しているアプリや、サードパーティ SDK が AppDelegate のイベントに依存しているケースです。機械的な置き換えだけでは済まないことが多く、テストを含めた工数が読みにくい部分です。

【リジェクト】Launch Screen の必須化

地味ながら、見落とすとApp Storeへの提出時に問題となるのがこちらです。iOS 27 リリースノートより。

“iOS and iPadOS apps built with the 27.0 SDK or later are required to include a launch screen. Your app’s Info.plist must contain one of the following keys: UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen, or UILaunchScreens. Apps that don’t include a launch screen are rejected when the App Store begins accepting apps built with the 27.0 SDK.”
（iOS 27.0 SDK 以降でビルドされた iOS / iPadOS アプリは launch screen を含むことが必須になります。Info.plist に UILaunchStoryboardName、UILaunchStoryboards、UILaunchScreen、UILaunchScreens のいずれかのキーが必要です。含まないアプリは、App Store が 27.0 SDK ビルドの受付を開始した時点でリジェクトされます）

該当しない場合、アップロード時に ITMS-90870: Missing launch screen. エラーで弾かれます。App Store だけでなく代替マーケットプレイス経由の配布も対象です。この要件は、2027 年春の最新 SDK 必須化を待たず、App Store が iOS 27 SDK ビルドの受付を開始した時点から、その SDK でビルドした提出物に適用されます。

対応は簡単で、Info.plist に上記4キーのいずれかがあれば OK です。

  • Storyboard で launch screen を作っている場合: UILaunchStoryboardName が既にあるはずなので対応不要
  • SwiftUI プロジェクト: Generate Info.plist File / Launch Screen (Generation) ビルド設定が有効なら Xcode が UILaunchScreen を自動で入れてくれます
  • launch screen を持たない古いプロジェクト: 空でもよいので UILaunchScreen キー(dictionary)を追加するのが最短です

「なぜ今さら launch screen？」と思うかもしれませんが、Apple のテクニカルノート TN3208 には「launch screen はマルチタスキングや dynamic resizing といったモダンなシステム機能をサポートするためのもの」と説明されています。後述の resizability 対応と地続きの要件です。

【見た目が変わる】Liquid Glass 強制適用

iOS 26 で導入された Liquid Glass デザインには、Info.plist の UIDesignRequiresCompatibility フラグで従来デザインを維持する逃げ道が用意されていました。WWDC25 の時点で「次のメジャーリリースで削除予定」とアナウンスされていましたが、これも予告通り実行されました。公式ドキュメントより。

“The system ignores this key when you build for iOS 27 or later, iPadOS 27 or later, Mac Catalyst 27 or later, macOS 27 or later, or tvOS 27 or later.”
（iOS 27 以降、iPadOS 27 以降、Mac Catalyst 27 以降、macOS 27 以降、tvOS 27 以降向けにビルドすると、システムはこのキーを無視します）

エラーも警告も出ません。単に無視されて、Liquid Glass が全面適用されます。このフラグで対応を先送りしていたアプリは、Xcode 27 でビルドした瞬間に、初めて本番相当の見た目で Liquid Glass を確認することになります。なお、ダークモードを固定する UIUserInterfaceStyle は今回廃止されていません。

Liquid Glass にはレイアウトに実害が出るポイントがあります。最低限、以下は実機確認しておきたいところです。

  • ナビゲーションバー / タブバーにカスタム背景色を設定している箇所: ガラス表現と競合して意図しない見た目になりがちです
  • フローティングタブバーによる safeArea の変化: 画面下部に FAB やボトムシートを置いている場合、位置がずれる可能性があります
  • スクロールビューと透過バーの組み合わせ: scroll edge appearance の挙動が変わる箇所

昨年 iOS 26 対応で一度 Liquid Glass 対応を済ませているアプリであれば、差分の確認程度で済むはずです。フラグで凌いでいたアプリは、UI 調整の工数がまとまって出ます。

【挙動が変わる】iPhone アプリの resizability 自動 opt-in

iOS 27 SDK でビルドすると、iPhone アプリは iPhone Mirroring（Mac 上）と iPad 上で自由にリサイズ可能になります。opt-in の設定項目があるわけではなく、最新 SDK でビルドした時点で自動的に有効になります。「うちは iPhone 専用だから画面サイズは固定」という前提が、ビルドし直した瞬間に崩れるということです。

この方針転換の背景や、セッションでどう説明されていたかについては、別記事「WWDC2026のUI関連セッションから見る、折りたたみ型iPhoneの可能性」で詳しく書いているので、そちらに譲ります。ここでは「何を対応しなければならないか」に絞って押さえます。

  • userInterfaceIdiom をレイアウト判断に使わない: iPad 上で動く iPhone アプリは、リサイズ可能になっても idiom は .phone のままです。「.phone なら幅は狭い」という推論がもう成り立ちません。size class(horizontalSizeClass / verticalSizeClass)へ置き換えます
  • interfaceOrientation もレイアウト判断に使わない: iOS 27 では、サポートする画面方向はシステムへの「希望」として扱われ、リサイズ可能な環境では無視されます。こちらも size class と view の bounds ベースへ
  • UIRequiresFullScreen の挙動変更に注意: リサイズからの完全除外ではなく、サポートする画面方向を尊重した「離散的なリサイズ」に変換されるようになりました。「フルスクリーン指定しておけばリサイズ対応不要」はもう通用しません。連続リサイズに耐えるレイアウトができているなら、フラグ自体を外すことも検討しましょう
  • Device Hub の resize mode で動作確認: Xcode 27 の Device Hub では、シミュレータや iPhone Mirroring のウィンドウ端をドラッグして、任意のサイズ・アスペクト比でレイアウト崩れを確認できます

UIDevice.current.userInterfaceIdiom == .pad や UIApplication.shared.statusBarOrientation で分岐しているコードは、この機会に洗い出しておきましょう。

非推奨 API の整理

Xcode 27 ビルドに合わせて片付けておきたい非推奨 API と挙動変更をまとめます。

UIScreen.main への参照を除去する

iPhone Mirroring や iPad の外部ディスプレイでは、scene に紐付く screen が動的に切り替わるため、UIScreen.main は「いまアプリが表示されている画面」を指す保証がなくなりました（セッションでの説明は前掲の別記事を参照してください）。置き換え先は用途別に以下の通りです。

// 画面(screen)そのものが必要な場合
let screen = window?.windowScene?.screen
// スケールファクタが欲しかった場合
let scale = traitCollection.displayScale
// scene に割り当てられた有効領域を SceneDelegate 側で見たい場合
let sceneSize = windowScene.effectiveGeometry.coordinateSpace.bounds.size
// view / view controller 内で「使える領域のサイズ」が欲しかった場合
let size = view.bounds.size

UIApplication の status bar 系アクセサ

beta 3 リリースノートの Known Issues によると、iOS 27 SDK ビルドでは UIApplication の非推奨アクセサ statusBarFrame / statusBarOrientation / statusBarStyle / isStatusBarHidden が NaN や null を返すことがあります。これは beta 時点の既知の問題であり、正式リリースまでに修正される可能性があります。ただし API 自体が非推奨であることは変わらないため、UIWindowScene.statusBarManager から取得するように置き換えるのが適切です。

On Demand Resources → Background Assets

iOS 27 リリースノートより。

“On Demand Resources and the NSBundleResourceRequest API are deprecated. Use Background Assets instead.”
（On Demand Resources と NSBundleResourceRequest API は非推奨になりました。代わりに Background Assets を使ってください）

ODR でアセットを遅延ダウンロードしているアプリは、Background Assets への移行計画を立てましょう。Background Assets には ODR 相当の on-demand ダウンロードポリシーが用意されています。

開発環境まわりの変更

Xcode 27 自体の要件も確認しておきましょう。公式リリースノートより。

  • Apple silicon 専用: “Xcode 27 will only install and run on Apple silicon Macs.”（Xcode 27 は Apple silicon Mac にのみインストール・実行できます）。Intel Mac で開発しているメンバーがいるチームは、iOS アプリのビルド・検証環境としては対応改修の開始までにマシンの更新が必要です。なお macOS SDK は引き続き Universal なので、macOS / Mac Catalyst アプリの Intel 向けビルドやバックデプロイそのものが消えるわけではありません。
  • macOS Tahoe 26.4 以降が必要（beta 3 時点）
  • Swift 6.4 と各プラットフォームの 27 SDK を同梱
  • 実機デバッグは iOS 17 以降をサポート。それより古い OS の実機検証が必要な場合は旧 Xcode の併用が必要です

また、Xcode 27 には移行作業を支援する仕組みも用意されています。Coding agent 向けの modernization skill を使うと、UIScene 移行や UIScreen.main の置き換えといった機械的な作業をエージェントに任せられます。人力でやると単調でミスの出やすい類の作業なので、活用を検討する価値はあるでしょう。

受託案件でクライアントと握っておきたいこと

ここまでは技術対応の話でしたが、受託開発だと今回の変更はエンジニアの作業だけで閉じません。仕様や見積もり、保守契約に波及する項目を挙げておきます。

  • Liquid Glass 対応はデザイン工数として見積もる: compatibility フラグの撤廃で、見た目の変化は「対応するかどうか」ではなく「いつ誰が確認するか」の問題になりました。クライアントのブランドガイドラインに沿ったカスタム UI ほど調整が重く、デザイナーのレビューとクライアント側の承認リードタイムが必要です。エンジニアリング工数だけで見積もると足りません。App Store 掲載用スクリーンショットの撮り直しが発生する点も見落としがちです
  • 「画面の向きの固定」という仕様が保証できなくなる: resizability の自動 opt-in により、サポートする画面方向はシステムへの希望として扱われ、iPad や iPhone Mirroring 上では無視されます。仕様書に「縦固定」と書かれている画面（カメラ撮影、署名、業務入力フォームなど）は、縦横比が変わっても機能が成立するかを再確認する必要があります。逆方向も同じで、動画再生や横向き前提のグラフ表示のように画面を強制的に横に回転させる仕様も、リサイズ可能な環境では保証されません。既存の仕様書の前提を崩す変更なので、開発側だけで判断せず、発注側と合意を取り直すのが安全です
  • 実機デバッグ・検証の下限が iOS 17 になる: Xcode 27 の実機デバッグは iOS 17 以降のみです。deployment target 自体はもっと下げられますが、デバッグできない OS を保守契約のサポート対象に残すのはリスクでしかありません。サポート範囲を iOS 17 以降（端末でいうと iPhone XS / XR 以降）へ改定する提案を、SDK 必須化の前にクライアントへ出しておきたいところです。逆にサポート対象外になるのは、iOS 16 で更新が止まっている iPhone X / 8 / 8 Plus とそれ以前の機種です

どれも判断にクライアントを巻き込む必要がある項目です。営業や PM も含めた案件単位の棚卸しは、2027年春の SDK 必須化を待たずに始めておきたいところです。

対応チェックリスト

ここまでの内容を、要件の性質と未対応時の影響度順にまとめます。「必須」はビルドまたは提出の成立条件、「実質必須」は対象機能を正しく動かすための対応、「計画対応」は非推奨化に備えた中期対応です。

#区分対応事項未対応時の影響対応時期の目安
1必須UIScene ライフサイクル移行アプリが起動しない～2026年度末
2必須Launch Screen キーの追加アップロードがリジェクト(ITMS-90870)2026年夏〜秋（iOS 27 SDK ビルドの申請受付開始後の初回更新まで）
3実質必須Liquid Glass 対応（compatibility フラグ撤廃）意図しない見た目・レイアウト崩れ～2026年度末
4実質必須resizability 対応（idiom / orientation 分岐の除去、size class 化）リサイズ環境でレイアウト崩れ～2026年度末
5実質必須UIScreen.main 参照の除去リサイズ・ミラーリング環境で誤動作～2026年度末
6推奨status bar 系アクセサの置き換えbeta 3 では NaN / null による誤動作の可能性2026年9月ごろ（正式版で再確認）
7計画対応On Demand Resources → Background Assets将来の削除リスク2026年度内に移行計画を策定
8環境要件Intel Mac からの移行Xcode 27 が動かないXcode 27 対応開始前

1〜2 は起動・提出の最低条件、3〜5 は対象環境で正しく動かすための実質的な条件です。6〜8 は現時点で即時必須ではありませんが、非推奨 API と将来の削除に備えて計画的に進める項目です。

おわりに

今年の対応事項を並べると、UIScene は適応型 UI の基盤となり、Liquid Glass と resizability への対応はレイアウトの前提を size class と bounds ベースに寄せる話に着地します。Launch Screen は提出要件として別途確実に満たす必要があります。個別タスクとしてバラバラに片付けるより、関連する UI の前提合わせを一括でやったほうが手戻りは少ないはずです。その先に何があるのか、という考察は別記事「WWDC2026のUI関連セッションから見る、折りたたみ型iPhoneの可能性」に譲ります。

例年通りであれば、すべての更新で iOS 27 SDK ビルドが求められるのは 2027 年春と見込まれます。ただし、Xcode 27 でビルドした更新をそれ以前に提出するなら、UIScene と Launch Screen はその最初の更新までに対応が必要です。UIScene 移行はサードパーティ SDK やプッシュ通知まわりに波及しやすく、テストを含めると想像より重くなりがちです。「Xcode 27 の正式リリース後、最初のアップデートまでに 1〜2 を完了、年内に 3〜5 と非推奨 API の棚卸しを進める」くらいのスケジュール感で、早めに着手することをおすすめします。

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

参考・引用元

この記事は iOS 27 / Xcode 27 beta 3（2026年7月11日時点）の公式ドキュメントとセッショントランスクリプトに基づく個人的な見解のまとめであり、Apple Inc. の公式見解を代表するものではありません。正式リリース時には内容が変わる可能性があります。



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