UIKit 的 Scene 強制令：哪些情況會在 iOS 27 上無法啟動

Q: 我現有的 App 會在 iOS 27 上停止運作嗎？

光憑這項要求並不會。這項強制令僅適用於「以最新 SDK 建置」的 App。1已以較舊 SDK 上架的二進位檔在 iOS 27 上仍可繼續啟動。失敗發生於您在尚未就位以 Scene 為基礎的生命週期時，便以 iOS 27 SDK 重新建置。

Q: 我怎麼知道我的 App 是否受影響？

檢查兩件事。1如果您的 Info.plist 缺少帶有設定的 UIApplicationSceneManifest 鍵，且您的 app delegate 未實作 scene 設定方法，那麼您就處於 app-delegate 生命週期，App 在以 iOS 27 SDK 建置時將無法啟動。自 iOS 18.4 起，UIKit 便已為受影響的 App 記錄遷移訊息。1

3分鐘閱讀

Apple 的遷移文件用一句話道盡 iOS 27 週期中最嚴苛的要求：「自 iOS 27、iPadOS 27、Mac Catalyst 27、tvOS 27 與 visionOS 27 起，以最新 SDK 建置的 App 必須採用以 Scene 為基礎的生命週期，否則將無法啟動。」¹不是標記為棄用，不是發出警告，也不是執行變慢：而是無法啟動。Session 278 同樣說得直截了當：「以最新 SDK 建置時，現在必須採用 UIScene lifecycle。少了它，您的 App 將不再能啟動。」²每一個仍運行在舊有 app-delegate 生命週期上的 UIKit App，最遲都得在以 iOS 27 SDK 建置之前完成遷移，而警告階段早已持續了數年。

Watch on Apple Developer ↗

此要求在 session 278 的 2:36 處提出。

重點摘要

以 iOS 27 SDK 建置的 App 必須採用 UIKit 以 Scene 為基礎的生命週期，否則將無法啟動，橫跨 iOS、iPadOS、Mac Catalyst、tvOS 與 visionOS 27。¹以較舊 SDK 建置的現有二進位檔仍可繼續運作；門檻取決於您建置時所用的 SDK。
這項升級是分階段進行的：UIKit 早在 iOS 18.4 就開始記錄遷移訊息，並在 iOS 26 改變了訊息內容。到了 iOS 27，這則記錄變成了啟動失敗。¹
只要符合下列任一條件，就需要遷移：您的 Info.plist 沒有帶有設定的 UIApplicationSceneManifest 鍵，或您的 app delegate 未實作 scene 設定方法。¹
最小遷移幅度很小：在 property list 中加入一筆 scene manifest 項目，或為動態設定加入 delegate 方法。支援多個 scene 仍屬選用。¹
Xcode 27 隨附一個 App 現代化 agent skill，可將 App 轉換為 Scene 生命週期、改寫主畫面與方向檢查、在複雜任務上提出釐清問題，並為一次工作階段內無法完成的部分留下註解。²

這是強制令，不是棄用

27 週期有個慣例：在替代方案成熟後一個版本就修剪掉舊 API：ImageCreator 在 iOS 27 停止運作，而 MXMetricManager 在其替代方案推出的同一週帶上了 27.0 的棄用標記。Scene 要求是這個慣例中影響最深遠的一項，因為它管控的是整個 App，而非單一功能。一個從不碰觸 Image Playground 的 App，今年秋天什麼也不會失去。一個忽略 Scene 生命週期的 App，則會在以新 SDK 建置的當天起停止啟動。

這份時程顯示 Apple 在強制執行前耗費了多長的緩衝期。從 iOS 18.4、iPadOS 18.4、Mac Catalyst 18.4、tvOS 18.4 與 visionOS 2.4 起，UIKit 便為尚未遷移的 App 記錄訊息，並在 26 版本中改變了該訊息內容。¹兩個版本的警告之後，地板便塌陷。概念上的鋪墊更為久遠：這場 session 回溯到 WWDC 2014，引用 Bruce Nilo 的說法「裝置旋轉只不過是一次帶動畫的 bounds 變更」，並指出隨著可調整大小的 iPad 視窗與可調整大小的 iPhone App，「這項洞見在今天比以往任何時候都更具意義」。²

有一條界線值得精確說明：這項要求約束的是「以最新 SDK 建置」的 App。¹以 iOS 26 或更早 SDK 建置並已上架的二進位檔仍可繼續啟動。一旦您以 Xcode 27 的 SDK 重新建置以取得任何新功能，Scene 生命週期就會隨之而來。

你真的需要遷移嗎？

文件給出一個雙條件測試。若資訊 property list 中缺少 UIApplicationSceneManifest 鍵（或未指定任何設定），或您的 app delegate 未實作 scene 設定方法，就需要遷移。¹大多數在 2019 年之後啟動的 App 早已過關；Xcode 的範本自那時起便產生以 Scene 為基礎的專案。被這項強制令攔下的，是那些壽命悠長、其 AppDelegate 仍持有視窗的 App。

最小修正有兩條路徑可選。靜態路徑是在 property list 中加入帶有 scene 設定的 UIApplicationSceneManifest 鍵，可透過 target 的 General 設定、於 Deployment Info 下的「Scene manifest」處進行。¹動態路徑則改為實作 scene 設定的 delegate 方法，適用於依使用者活動自訂 scene、或處理不同 scene 角色的 App；文件範例使用工作階段的 role 屬性來判斷要建立哪一個 scene。¹從 storyboard 載入根 view controller 的 App，會在 scene manifest 中包含 storyboard 名稱，系統便會自動設定 window scene 與根 view controller。¹

這項強制令並不要求的，是多個 scene。文件明白指出多 scene 支援仍屬選用，且可能需要將資料模型重構為各 scene 專屬；它要您先衡量使用者體驗是否因此受益，再決定是否啟用。¹遷移意味著把生命週期事件從 App 層級移到 scene 層級，其中 UIApplicationDelegate 保留行程層級的事件，而 scene delegate 接手與 UI 相關的事件。¹有個容易在設定時絆倒人的細節：請指定 UIWindowScene 物件而非單純的 UIScene 物件，而 CarPlay scene 則使用自己的 template-application scene 類型。¹

為何是現在：一切都可調整大小

這項強制令落在同一個讓「可調整大小」變得普及的版本之中，而 session 278 將兩者呈現為同一個故事。在 iOS 與 macOS 27 中，Mac 上的 iPhone Mirroring 視窗可自由調整大小，而僅限 iPhone 的 App 在 iPad 上執行時，也會變得「像任何其他 iPad App 一樣完全可調整大小」。²Scene 生命週期，用這場 session 的話來說，正是「任何 adaptive App 的基礎」：是 session 要您修正的所有其他事項的前提。²

這份修正清單是對以螢幕為中心的各種假設的一次清洗。一旦您的 scene 落在不同的顯示器上，對主畫面的引用便會回傳不正確的資訊，因此 session 建議透過視窗的 window scene 動態存取螢幕，或更好的做法是徹底移除螢幕引用：螢幕縮放比改用 trait collection 的 displayScale，螢幕 bounds 則改用 window scene 的有效幾何資訊、或乾脆改用周圍 view 的尺寸。²自動 trait 追蹤緩和了這次遷移：系統會追蹤哪些 trait 屬性是在 layoutSubviews 這類佈局與繪製方法內讀取的，並在被追蹤的 trait 變更時再次呼叫它們。²

兩個由來已久的訊號徹底失去了佈局上的意義。user-interface idiom「對任何一種佈局決策而言都不再具有意義」，因為 iPhone App 在 iPad 上是完全可調整大小地執行，卻仍回報 phone idiom；而 supported interface orientation 則變成系統在可調整大小環境中會忽略的一項偏好設定，iPhone Mirroring 無論視窗長寬比為何，一律回報直向。²兩者的替代方案都是 size class。遊戲取得的是一種權宜安排，而非豁免：自 iOS 27 起，UIRequiresFullscreen 在 iPhone 的可調整大小環境中會被遵循，但其行為改為離散式調整大小，在每次調整大小時將 scene 轉換到對應的螢幕設定，使遊戲在可用空間中以全畫質呈現。²

測試整個矩陣在同一週期也變得更省事：Device Hub 與 Xcode Previews 新增了「進入調整大小模式」，可自由拖曳裝置邊緣，而 session 建議之後再於 iPhone Mirroring 與 iPad 上進行實機檢查。²

這次遷移有一個 agent skill

Session 在結尾承認了這項要求的規模，並指向 Xcode 27 的解法：一個全新的 App 現代化 skill，對 session 所列舉的「各項 adaptivity 任務有深入的理解」。²當你要求它讓 App 更具適應性時，這個 agent 會把主畫面呼叫轉換為 trait-collection 或 scene-bounds 檢查，並在需要之處加入失效（invalidation）邏輯，以 size class 取代介面方向檢查，甚至「還會把你的 App 轉換為使用 scene lifecycle」。²面對複雜任務，它會提出釐清問題；面對一次工作階段內過於龐大的工作，它會留下註解標示尚未完成的部分。²

其發布方式與 Apple 在這次 WWDC 推動 skills 的整體做法一致：xcrun agent skills export 會產生可匯入其他工具的 markdown 檔案，這正是 Xcode 27 的 agent skills export 所涵蓋的同一機制。²由 SDK 強制執行的遷移，搭配一個會代為執行該遷移的 skill，是 Apple 在 agent 時代期望如何消化破壞性變更的最清晰表達：平台抬高地板，而工具帶著你跨過去。

常見問題

我現有的 App 會在 iOS 27 上停止運作嗎？

光憑這項要求並不會。這項強制令僅適用於「以最新 SDK 建置」的 App。¹已以較舊 SDK 上架的二進位檔在 iOS 27 上仍可繼續啟動。失敗發生於您在尚未就位以 Scene 為基礎的生命週期時，便以 iOS 27 SDK 重新建置。

我怎麼知道我的 App 是否受影響？

檢查兩件事。¹如果您的 Info.plist 缺少帶有設定的 UIApplicationSceneManifest 鍵，且您的 app delegate 未實作 scene 設定方法，那麼您就處於 app-delegate 生命週期，App 在以 iOS 27 SDK 建置時將無法啟動。自 iOS 18.4 起，UIKit 便已為受影響的 App 記錄遷移訊息。¹

這會強迫我支援多視窗嗎？

不會。多 scene 支援仍屬選用，而 Apple 的文件建議在啟用前先權衡使用者體驗是否因此受益，因為這可能需要讓您的資料模型變成各 scene 專屬。¹這項強制令只要求以 Scene 為基礎的生命週期本身：生命週期事件改為依各 scene 處理，而非全域處理。

agent 能完成這次遷移嗎？

Xcode 27 隨附一個 App 現代化 skill，session 表示它能把 App 轉換為 Scene 生命週期、改寫主畫面引用，並以 size class 取代方向檢查，在變更含糊不清之處提出釐清問題，並為未完成的工作留下註解。²它可透過 xcrun agent skills export 匯出到其他工具。²請把它的輸出當作任何由 agent 撰寫的遷移來看待：審查 diff，尤其是狀態還原與視窗設定相關的部分。

這項強制令完成了本週期的一個主題：Apple 在 27 這道界線上強制執行遷移，而非僅僅建議遷移，繼 ImageCreator 的停用在更小的範圍上展現了同樣的分階段升級之後。agent-skill 的解法則連結到更廣的 skills 脈絡，見 Xcode 27 推出可匯出至任何地方的 Agent Skills。完整系列匯整於 Apple 生態系系列。

參考資料

Apple, Transitioning to the UIKit scene-based life cycle, Apple Developer Documentation. Source for the requirement (“Beginning in iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27, and visionOS 27, apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch”), the staged warnings (UIKit logging a migration message starting in iOS 18.4, iPadOS 18.4, Mac Catalyst 18.4, tvOS 18.4, and visionOS 2.4, with the message changing in the 26 releases), the two-condition migration test (missing UIApplicationSceneManifest key or no scene-configuration delegate method), the property-list and dynamic-configuration migration routes including the General settings “Scene manifest” location and the session-role example, the storyboard-name note with automatic window-scene configuration, multiple-scene support remaining optional with the data-model caution, the app-versus-scene split of life-cycle responsibilities, the guidance to specify UIWindowScene objects rather than UIScene objects, and the CarPlay scene type. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple, WWDC 2026 session 278, Modernize your UIKit app. Official transcript; presented by Michael Ochs, engineering manager on the UI Frameworks team. Source for the requirement statement (“UIScene lifecycle is now required when building with the latest SDKs. Without it, your application will no longer launch”), iPhone Mirroring resizing and iPhone-only apps running fully resizable on iPad, the scene life cycle as “the basis for any adaptive app,” the main-screen guidance (dynamic access through the window scene, displayScale via the trait collection, effective geometry and surrounding-view size over screen bounds), automatic trait tracking across layout and drawing methods, the idiom and interface-orientation guidance including the always-portrait behavior in iPhone Mirroring and the move to size classes, the UIRequiresFullscreen discrete-resizing behavior for games, the Bruce Nilo WWDC 2014 quote (“a device rotation is only an animated bounds change”) and its framing, the Device Hub and Xcode Previews resize mode, and the app modernization skill (deep understanding of the adaptivity tasks, converting main-screen calls with invalidation logic, replacing orientation checks with size classes, converting apps to the scene life cycle, clarifying questions, progress comments, and export through xcrun agent skills export). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩