iOS 27.0 發行說明：棄用項目、破壞性變更與修正

iOS 27.0 與 iPadOS 27.0 已於 2026年9月14日（星期一）以組建 24A437 正式發布，與 Apple 在 9 月 11 日公布的 RC 是同一個組建；Xcode 27（27A266a）內附的 SDK 同日推出，App Store Connect 也從同一天起接受以 27.0 正式版 SDK 建置的 App。¹³ 現在有三個組建編號都在回答「哪一個 iOS 27.0？」：裝置上執行的是 24A437，Xcode 27 內的 SDK 自稱 24A430，模擬器執行環境則是 24A434。⁴ 這份發行說明涵蓋 93 個分區，共有 65 項新功能、197 個已解決的問題、23 個已知問題與 11 項棄用；對既有程式碼真正重要的，是那些在改用 27.0 SDK 建置的當下就會生效的變更、SDK 自身標頭檔所證實的棄用項目，以及一項 Foundation 修正：同一個二進位檔在 iOS 26.5 與 iOS 27.0 執行環境上分別重現出修正前後的行為。²⁴ {.answer-block}

重點摘要

• 組建編號。 裝置 24A437、SDK 24A430、模擬器執行環境 24A434；RC 與正式版共用同一個裝置組建，而 SDK 的編號並不是裝置的編號，錯誤回報要求提供版號時，這一點很重要。¹⁴
• 連結 27 SDK 後才生效的行為。 共 12 類、23 條變更會在改用 27.0 SDK 建置的那一刻改變 App 的行為：啟動畫面規定、場景生命週期強制要求、TabView 選到隱藏分頁時當機、可選取的 Text 改用系統文字選取、被呈現的視圖控制器改變 trait 繼承方式、內嵌式範圍列、外接顯示器場景不再自動提供、sheet 與 popover 內的控制項修飾器被重設、containerRelativeFrame 的安全區域計算、狀態列存取器、UIRequiresFullScreen 下的 iPad 縮放規則，以及選單與捲動至頂端兩處較小的 SwiftUI 變化。²
• 不重新編譯就會當機。 MetricKit 的 HitchTimeMetric.ratio 現在以新的 HitchTimeRatio 單位計量，ScrollHitchTimeMetric 則已從 Swift API 移除；Apple 表示要用最新 SDK 重新編譯，才能避免啟動時當機與符號遺失造成的當機，SDK 介面也證實該型別已不存在。²⁴
• 11 項棄用，多數不會出聲。 canOpenURL:（標頭檔標示 ios(3.0, 27.0)）、On Demand Resources（ios(9.0, 27.0)）、PHAssetResource.originalFilename（ios(9, 27)）、原始的 MetricKit API（標為 API_TO_BE_DEPRECATED，屬於軟性棄用）、ScrollHitchTimeMetric、FileDocument、calendar.deleteEvents 改名為 calendar.deleteEvent、PencilKit 的一項改名、場景強制要求、AirPort Utility，以及一則 Weather Highlights 的語言說明。三項硬性棄用只有在部署目標為 27.0 時才會發出警告；設為 17.0 或 26.0 時，同一個檔案編譯起來毫無異狀。²⁴
• 兩項 Foundation 變更，已實測。 +[NSURL URLWithString:] 在為字串中其他位置的空格進行跳脫時，不再把原本合法的 %20 重複編碼：同一個模擬器二進位檔在 iOS 26.5 執行環境上輸出 %2520，在 iOS 27.0 執行環境上輸出 %20，而 Mac 版建置的結果與舊行為一致，所以這項修正跟著作業系統走，不跟著 SDK 走。volumeAvailableCapacityKey 截斷至三位有效數字的變更在模擬器上看不出來，模擬器回報的是精確的 55,177,985 個區塊。²⁴

哪個組建編號是哪個？

這三個編號並非筆誤。SDK 是標頭檔與介面的快照，模擬器執行環境是 Apple 另外隨 Xcode 出貨的 cryptex，裝置組建則是使用者實際執行的版本；一份只寫「iOS 27.0」卻沒有註明是哪一個的重現步驟，正好缺了決定修正是否已套用的那個數字。⁴

發行說明本身以兩句話界定範圍：「The iOS & iPadOS 27 SDK provides support to develop apps for iPhone and iPad running iOS & iPadOS 27. The SDK comes bundled with Xcode 27, available from the Mac App Store」（iOS 與 iPadOS 27 SDK 支援開發在 iOS 與 iPadOS 27 上執行的 iPhone 和 iPad App，並隨 Mac App Store 上的 Xcode 27 一同提供），接著逐一列出 93 個分區。逐項計算各標題下的清單項目，得到 65 項新功能、197 個已解決的問題、23 個已知問題與 11 項棄用；光是 Siri 就佔了 38 個已解決與 8 個已知問題，SwiftUI 有 23 項新功能與 13 個已解決，UIKit 有 9 項新功能與 13 個已解決。² Xcode 27 那篇文章談的是工具鏈這一側，您正在讀的這一篇則談作業系統與 SDK 這一側。

改用 27.0 SDK 建置的那一刻會改變什麼？

Apple 把行為變更綁在 App 所連結的 SDK 上，所以這些變更對您已經出貨的版本毫無影響，卻會在從 Xcode 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.」（以 27.0 或更新 SDK 建置的 App 必須包含啟動畫面，Info.plist 需具備上述四個鍵之一；一旦 App Store 開始接受以 27.0 SDK 建置的 App，缺少啟動畫面者將被拒絕。）App Store Connect 自 9 月 9 日起接受以 27.0 RC SDK 建置的上傳，自 9 月 14 日起接受以正式版 SDK 建置的上傳；兩則公告都沒有說明何時開始拒絕，所以請把這兩個日期視為上傳日期，而非強制執行日期。³ 我的啟動畫面文章審查了一份自動產生的 plist。
• 場景生命週期。 列在 UIKit 棄用項目之下：「Apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch.」（以最新 SDK 建置的 App 必須採用場景式生命週期，否則無法啟動。）場景強制要求文章有遷移做法。
• TabView 的選取。 「In apps built with the iOS 27.0 and iPadOS 27.0 SDKs, a TabView enforces that its selection is set to a visible tab. TabView might crash when its selection is set to a hidden or otherwise unavailable tab.」（TabView 現在強制要求選取的必須是可見分頁；選到隱藏或不可用的分頁時可能當機。）要留意的情況是：從 UserDefaults 還原的選取值指向一個您後來隱藏的分頁。
• 可選取的 Text。 「In apps built with the iOS 27.0 and iPadOS 27.0 SDKs, a Text view with .textSelection(.enabled) applied now supports user-interactive selection using the system text selection UI.」（套用 .textSelection(.enabled) 的 Text 視圖現在改用系統文字選取介面。）Apple 補充這類視圖「might include additional gestures for system text selection interactions」（可能會多出系統文字選取互動用的手勢），並建議自訂手勢改用 .highPriorityGesture()；同一版也讓 TextRenderer 能在可選取的 Text 上運作。
• 被呈現的視圖控制器。 「In apps built with the iOS 27.0 SDK, a presented view controller inherits its trait collection by walking up its view’s superview chain through the intermediate views of the presentation, rather than jumping directly to the presentation controller.」（被呈現的視圖控制器現在沿著視圖的 superview 鏈、經過呈現過程中的中介視圖來繼承 trait collection，而不是直接跳到 presentation controller。）會設定 trait 的自訂 UIPresentationController 子類別，就是需要重新測試的對象。
• 範圍列。 「In apps built with the iOS 27.0 SDK, when UISearchController uses center search-bar placement, the scope bar appears inline on the same row as the search field rather than on a separate row beneath it.」（UISearchController 採用置中搜尋列時，範圍列會與搜尋欄位同列內嵌顯示，不再另起一列。）
• 外接顯示器。 「In apps built with the iOS 27.0 SDK, windowExternalDisplayNonInteractive scenes are no longer offered automatically by the system. Use UIViewController.registerSceneAccessory(_:) with a UISceneAccessory.externalNonInteractive instance to display non-interactive content on external display scenes.」（系統不再自動提供 windowExternalDisplayNonInteractive 場景；請改用 UIViewController.registerSceneAccessory(_:) 搭配 UISceneAccessory.externalNonInteractive 實例，在外接顯示器場景上顯示非互動內容。）SwiftUI 也有同樣的入口：.sceneAccessory 搭配 ExternalNonInteractiveAccessory。
• Sheet 與 popover。 列為已修正：「In apps built with the 27.0 SDKs, the controlSize, buttonSizing, buttonRepeatBehavior, menuIndicatorVisibility, and ButtonBorderShape environment values are now reset to their default values in sheets and popovers.」（這幾個環境值在 sheet 與 popover 中現在會重設為預設值。）如果某個 sheet 過去會從呈現它的視圖繼承 .controlSize(.large)，現在不會了。
• containerRelativeFrame。 同樣針對 27.0 SDK 建置修正：它「incorrectly accounts for safe-area insets on a ScrollView’s non-scrollable axis, causing the calculated scrollable content size to be too small」（在 ScrollView 不可捲動的軸向上錯誤計入安全區域內距，導致算出的可捲動內容尺寸過小），所以使用 containerRelativeFrame(.vertical) 的水平 ScrollView 尺寸會改變。
• 狀態列存取器。 針對 27.0 SDK 建置修正：UIApplication 上已棄用的狀態列存取器，說明列出的有 statusBarFrame、statusBarOrientation、statusBarStyle 與 isStatusBarHidden，「might return NaN or null values」（可能回傳 NaN 或空值）。
• iPad 與 iPhone 鏡像輸出的縮放與方向。 UIKit 有九個已解決的問題描述「built with the iOS 27 SDK」（以 iOS 27 SDK 建置）的 App 在場景連接、使用者調整視窗大小或旋轉時應看到的行為：UIRequiresFullScreen 的 App 會得到「a discrete change to a new UIScreen with an updated bounds」（一次切換到邊界已更新的新 UIScreen）而非連續的縮放更新，UIScreen.main 的邊界「should remain fixed once the screen connects」（在螢幕連接後應保持固定），而且「supported interface orientations should no longer be a condition for continuous resizability」（支援的介面方向不再是連續縮放的條件）。
• 選單與捲動至頂端。 兩處較小的 SwiftUI 變化：「In apps built with the 27.0 SDKs, a LabeledContent view used inside a Menu maps its value to the platform menu item’s subtitle」（Menu 內的 LabeledContent 會把它的值對應到平台選單項目的副標題），以及列為已修正的「In apps built with the 2027 SDKs, tapping the status bar to scroll a ScrollView to its top correctly updates a bound scrollPosition」（點按狀態列讓 ScrollView 捲到頂端時，會正確更新繫結的 scrollPosition）。為了排版而帶有值的選單標籤現在會多出一行副標題，而點按狀態列後讀到舊值的 scrollPosition 繫結現在會更新了。

以上 12 類涵蓋了會改變既有行為的條目。位在同一道 SDK 門檻後面的新功能，例如 ReadableDocument 協定、建構在其上的 Document 協定，以及 UIScene.extendStateRestoration，則放在後面的段落；外接顯示器這一類則把 UIKit 的移除與 SwiftUI 的替代方案放在一起。

有兩條 MetricKit 條目也該放在這裡，儘管它們談的是重新編譯而非連結。「HitchTimeMetric.ratio and SignpostIntervalMetric.hitchTimeRatio now use the new HitchTimeRatio type, a Dimension subclass that expresses hitch time as a ratio of milliseconds hitching per second of tracked duration. Recompile your app with the latest SDK to pick up this type change and avoid any crashes on launch.」（這兩個屬性改用新的 HitchTimeRatio 型別，它是 Dimension 的子類別，以每秒追蹤時長中卡頓的毫秒數表示卡頓比例；請用最新 SDK 重新編譯以接受此型別變更，避免啟動時當機。）另一條：「The scrollHitchTime(_:) case of MetricResult and the ScrollHitchTimeMetric type are no longer part of the new Swift MetricKit API, and MetricReport values no longer contain scroll hitch entries. Use the hitchTime(_:) case and HitchTimeMetric instead, which report per-app animation hitch time. Recompile your app with the latest SDK to avoid a missing symbol crash if it references ScrollHitchTimeMetric or scrollHitchTime(_:).」（scrollHitchTime(_:) 與 ScrollHitchTimeMetric 已不再屬於新的 Swift MetricKit API，MetricReport 也不再包含捲動卡頓條目；請改用 hitchTime(_:) 與 HitchTimeMetric，並用最新 SDK 重新編譯，以免引用舊名稱時因符號遺失而當機。）² 在 iOS 27 SDK 的 MetricKit Swift 介面裡，ScrollHitchTimeMetric 與 scrollHitchTime 出現零次，HitchTimeRatio 出現四次，所以任何用 beta SDK 建置、用到其中任一名稱的二進位檔，引用的都是正式版介面不再匯出的符號。⁴ 我的 MetricKit 文章介紹了六月 beta 中的新 API。

27.0 棄用了哪些 API？

發行說明列出 11 項棄用。發行說明裡的棄用是一句話；SDK 裡的棄用則是編譯器會讀取的可用性註記，而兩者說的不一定是同一件事。我拿每一條對照了 Xcode 27 內 iPhoneOS 27.0 SDK 的標頭檔與 Swift 介面：²⁴

有一項軟性棄用和一項改名落在「棄用」標題之外。.roundedBorder 文字欄位樣式在 SwiftUI 介面中帶有 deprecated: 100000.0 註記，其訊息去掉內層反引號後是「Use textFieldStyle(.bordered) with textInputBorderShape(.roundedRectangle)」（請改用 textFieldStyle(.bordered) 搭配 textInputBorderShape(.roundedRectangle)）；這對應到新功能中引入 TextInputBorderShape 的那一條。100000.0 這個版本號是 Apple 表達「已棄用，但還沒生效」的慣例：在預設編譯器設定下編譯器不會出聲，訊息只出現在介面裡。改名這一項比較棘手。UINavigationItem.navigationBarMinimization「replaces UINavigationItem.barMinimizeBehavior and UINavigationItem.barMinimizationSafeAreaAdjustment」（取代了這兩個舊屬性），SwiftUI 的 toolbarMinimizationBehavior 也以同樣方式取代 toolbarMinimizeBehavior；三個舊名稱在 27.0 SDK 的 UIKit 標頭檔以及 UIKit 與 SwiftUI 的 Swift 介面裡都不存在，所以用到它們的程式碼會直接編譯失敗而不是警告，與 deleteEvents 屬於同一類。²⁴

硬性棄用也比表面上安靜。編譯器拿棄用版本比對的是部署目標，而不是 SDK，所以 ios(3.0, 27.0) 只會在最低 iOS 版本為 27.0 的目標裡產生警告。我用 27 SDK 編譯了同一個檔案三次，它會呼叫 canOpenURL、建立 NSBundleResourceRequest，並讀取 originalFilename：在 -target arm64-apple-ios17.0-simulator 與 26.0 下編譯沒有任何診斷訊息，在 27.0 下則產生三則警告：'canOpenURL' was deprecated in iOS 27.0: Prefer attempting to open URLs and handling any failures、'NSBundleResourceRequest' was deprecated in iOS 27.0: Use Background Assets instead.，以及 'originalFilename' was deprecated in iOS 27: Use filename instead。⁴ 最低版本設得務實的 App 不會從編譯器聽到任何一項；在預設編譯器設定下，下方檢查清單裡的 grep 是您唯一會收到的通知。

我驗證了哪些修正？

有兩條 Foundation 條目可以實際執行，而不只是閱讀。發行說明將第一條列為已修正：「+[NSURL URLWithString:] no longer double-encodes the % of valid percent-escape sequences when encoding other invalid characters.」（+[NSURL URLWithString:] 在編碼其他無效字元時，不再把合法百分比跳脫序列中的 % 重複編碼。）² 探測程式用三個字串各自建立 NSURL(string:)，每個字串都含有一個合法跳脫序列和一個 NSURL 必須跳脫的字元，然後印出 absoluteString。我用 Xcode 27 建置了兩次：一次給 Mac，一次給模擬器且最低 iOS 設為 26.0，接著把那一個模擬器二進位檔原封不動地分別在 iOS 26.5 執行環境與 iOS 27.0 執行環境上執行：⁴

第一欄是舊行為：NSURL 跳脫了空格，卻也把原本已經合法的跳脫序列中的 % 變成 %25，於是路徑和跳脫序列原本指的那一個不同了。iOS 27.0 那一欄就是修正後的結果。同一個 Mach-O，其 LC_BUILD_VERSION 為 minos 26.0 與 sdk 27.0，產生了兩個模擬器欄位，所以決定結果的是程式碼所執行的作業系統，不是您編譯時使用的 SDK，也不是建置目標。您今天建置的 App 在我測試的 iOS 26.5 執行環境上仍保留舊編碼，而發行說明也沒有給任何理由讓人期待其他 26.x 版本會有不同結果。

發行說明將第二條列為新功能，而我在能執行程式碼的環境裡無法重現它：「volumeAvailableCapacityKey is truncated to 3 significant decimal digits at the block count level (e.g., 123,456,789 blocks becomes 123,000,000 blocks).」（volumeAvailableCapacityKey 在區塊數層級被截斷為三位有效十進位數字，例如 123,456,789 個區塊會變成 123,000,000 個區塊。）² 在 iOS 27.0 模擬器中，URL.resourceValues(forKeys: [.volumeAvailableCapacityKey]) 回傳 226,009,026,560 位元組，而對同一路徑呼叫 statfs 得到 f_bavail 55,177,985、f_bsize 4,096，相乘正好是同一個數字；若截斷為三位有效數字，區塊數應是 55,100,000，也就是 225,689,600,000 位元組。⁴ 主機 Mac 用同一段程式碼回報 55,177,998 個區塊。我的解讀是，這個截斷發生在裝置的核心而非 Foundation，而模擬器問的是 Mac 核心關於 Mac 磁碟區的資訊，自然顯示不出來；我還沒在實機上跑過這個探測程式，所以請把這一條視為未測試而非錯誤，並預期原本精確的裝置可用空間回報會出現四捨五入。

哪些新功能會改變您已經寫好的程式碼？

HealthKit 的有限歷史記錄。 說明只有一行：「Updated HealthKit permissions flow now lets users grant apps access to limited history or full history」（更新後的 HealthKit 權限流程讓使用者可以授予 App 有限或完整的歷史記錄存取），後果則寫在 API 參考文件裡。²⁵ 在資料類型畫面之後，「a second screen prompts them to choose how much historical data to grant your app, either a recent limited window or their full history」（第二個畫面會請使用者選擇要授予 App 多少歷史資料：近期的有限區間，或完整歷史），而且「Time-bound authorization applies only to sample types」（時間限制的授權只適用於樣本類型）。⁵ 新的 earliestAuthorizedSampleDate(for:) 自 iOS 27.0 與 watchOS 27.0 起提供，回傳一個從 HKObjectType 對應到最早可讀取日期的字典，而邊界不在您以為的位置：「HealthKit evaluates the boundary against a sample’s end date, so the framework might service your query with a sample that begins before the earliest authorization date as long as the sample ends after it.」（HealthKit 以樣本的結束日期判斷邊界，所以只要樣本在最早授權日期之後結束，即使它在該日期之前開始，框架仍可能把它回傳給您的查詢。）⁴⁵ 隱私規則依舊：「Your app can’t distinguish between denied and full access; limited authorization is the only state your app can identify, by design.」（App 無法區分被拒絕與完整存取；有限授權是 App 唯一能辨識的狀態，這是刻意的設計。）⁵ Apple 的指引是把回傳日期之前的一切視為未知而非不存在，並依類型逐一限制每個查詢的起始日期。任何從 HealthKit 算出來的趨勢、基準線或連續記錄，現在都必須在使用者選定的區間上保持正確。HealthKit 文章介紹的是六月新增的功能，並未涵蓋這次權限模型的改變。

StoreKit 優惠代碼。 「Offer code redemption APIs now return a VerificationResult when redemption completes. If a redemption succeeds, your app receives a VerificationResult that contains a Transaction object. If a redemption fails, your app receives an error that describes what caused the redemption to fail.」（優惠代碼兌換 API 現在會在兌換完成時回傳 VerificationResult；成功時內含 Transaction 物件，失敗時則收到描述原因的錯誤。）² 在介面中，presentOfferCodeRedeemSheet(in:) 於 27.0 棄用，訊息為「Use presentOfferCodeRedeemSheet(from:options:) instead.」，替代方案是自 iOS 27.0 起提供的 presentOfferCodeRedeemSheet(from viewController: UIViewController, options: Set<RedeemOption> = []) async throws -> VerificationResult<Transaction>。⁴ 過去先呈現兌換表單、再監聽 Transaction.updates 等結果的程式碼，現在可以直接 await。

背景中的 Core AI。 「The system now restricts background access to the Neural Engine, similar to GPU usage restrictions」（系統現在會限制背景存取 Neural Engine，與 GPU 的使用限制類似），而且「Neural Engine memory usage is now attributed to your app process instead of the system, and appears in the Allocations instrument」（Neural Engine 的記憶體用量現在歸屬於您的 App 程序而非系統，並會顯示在 Allocations 工具中）。背景存取「requires the new entitlement: “com.apple.developer.background-tasks.continued-processing.inference”」（需要這個新的 entitlement）。² 一個在 26 上從背景工作執行推論、從未申請過任何權限的 App，會發現 Neural Engine 在取得該 entitlement 之前都是關閉的，而它所使用的 Neural Engine 記憶體現在會列在它自己的程序名下。

Background Assets。 「You can reduce your app’s storage usage with localized asset packs. The system delivers the appropriately localized asset packs based on the user’s preferred languages.」（您可以用本地化資源包減少 App 的儲存空間用量；系統會依使用者偏好的語言提供對應的本地化資源包。）² 對正要離開 On Demand Resources 的 App 來說，本地化資源包就是取代各語言標籤的那項功能。

重要警示。 發行說明把重要警示的行為列為已修正：「Critical alerts are automatically turned on for any apps that request your permission to enable notifications.」（任何要求您允許通知的 App，都會自動開啟重要警示。）² 這一條沒有更多說明，所以請重新測試在 beta 期間看起來權限過大的任何通知流程。

選單、@State、TLS 與新的架構切片。 有四條各自有專文。iPadOS 27 與 macOS 27 上的選單列與快顯選單「present a reduced set of menu item images」（只顯示較少的選單項目圖像），可用 UIMenuElement 上的 preferredImageVisibility 覆寫：請參閱選單圖像。@State 巨集的改寫是這份說明中的一條 SwiftUI 條目，它改變了 Xcode 27 下哪些程式碼能編譯：重現步驟請參閱 Xcode 27 文章，審查請參閱 @State 巨集文章。針對 MDM、註冊與軟體更新流量更嚴格的 TLS 要求「in 27.0 operating systems」（在 27.0 作業系統中）開始生效：請參閱 TLS 審查。而搭載 CPA2 的 arm64e.x1 適用於「iPhone models with A20 Pro or later chips, Mac computers with M6 or later chips, and Apple Watch models with S11 or later chips」（配備 A20 Pro 或更新晶片的 iPhone、M6 或更新晶片的 Mac，以及 S11 或更新晶片的 Apple Watch）：請參閱 arm64e.x1。²

值得 grep 一下的小條目。 System 新增了 Swift 版的 stat、lstat、fstat 與 fstatat，附帶 Stat 型別和 FilePath.stat()，發行說明也把這些方法與您自己擴充裡未限定的 stat() 之間的衝突列為已修正。NSTextTable「and its related objects and types are available to UIKit clients starting with OS 27 releases」（及其相關物件與型別自 OS 27 版本起開放給 UIKit 用戶端使用）。AsyncImage「now automatically caches downloaded images using HTTP caching protocols」（現在會依 HTTP 快取協定自動快取下載的圖像），並提供 URLRequest 初始化器與 View.asyncImageURLSession(_:) 供調整。「When linked on iOS 27, tvOS 27, macCatalyst 27, or visionOS 27 SDKs」（連結這些 27 SDK 時），UIScene.extendStateRestoration 與 UIScene.completeStateRestoration 把狀態還原延伸到從背景回到前景的轉換。另外 SwiftData 列了一項修正，針對「a deadlock for @Query when saving a ModelContext on a background actor while scheduling new async tasks for a ModelActor」（在背景 actor 上儲存 ModelContext、同時為 ModelActor 排程新非同步工作時，@Query 發生的死結）。²

需要預先規劃的已知問題

• photos.asset 實體無法再編譯。 「Existing entities that conformed to @AppEntity(schema: .photos.asset) in prior releases might no longer compile in the 27 SDKs because new properties were added to the schema in this release.」（先前版本中遵循 @AppEntity(schema: .photos.asset) 的既有實體，在 27 SDK 下可能無法再編譯，因為此版本為該 schema 新增了屬性。）因應方式：「To continue conforming to the schema, adopt the additional properties and move the code behind an availability check.」（若要繼續遵循該 schema，請採用新增的屬性，並把程式碼放到可用性檢查之後。）² 巨集不會告訴您是哪些屬性：一個空的 @AppEntity(schema: .photos.asset) 遵循在 swiftc 下可以乾淨編譯，它的展開只多加了一個帶有 schema 名稱的 AssistantSchemaEntity 遵循。清單來自 Xcode 的 App Intents 中繼資料步驟 appintentsmetadataprocessor，它會讓建置失敗，每缺一個屬性報一個錯誤。我手動對著 27.0 SDK 在那個空遵循上執行，它回報了 12 個，每個都附 fix-it：hasSuggestedEdits: Bool、isFavorite: Bool、isHidden: Bool、creationDate: Date?、location: GeoToolbox.PlaceDescriptor?、assetType: <#PhotoAssetType#>?、filter: <#PhotoFilterEffectType#>?、exposure: Double?、saturation: Double?、warmth: Double?、aperture: Double? 與 isPortraitModeEnabled: Bool?；兩個 <#…#> 占位符代表您要自行對照 .photos.assetType 與 .photos.filterType 列舉 schema 宣告的列舉，介面把它們命名為 PhotoAssetType 與 PhotoFilterEffectType。我無法拿這份清單與 26 SDK 比對差異，因為這台 Mac 上唯一的 Xcode 是 27A266a。⁴
• Now Playing 權杖一律走正式環境。 「RemoteMediaSession and RemoteMediaSessionRepresentable always provision Now Playing start and update push tokens for the production APNs environment, even if the aps-environment configuration is set to development.」（即使 aps-environment 設為 development，這兩個型別仍一律為 production APNs 環境配發 Now Playing 的啟動與更新推播權杖。）因應方式：「Use the production environment for testing and validation.」（測試與驗證請使用 production 環境。）² 該類別位於新的 NowPlaying 框架中，並標示在 macOS 與 visionOS 上不可用。⁴
• SpotlightSearchTool 塞爆裝置端模型。 未加設定時，「the tool’s description and parameter schema alone exceed the on-device model’s context window before any prompt is added」（光是工具描述與參數 schema 就已超出裝置端模型的上下文視窗，連提示都還沒加）。因應方式是使用聚焦的指引：「.focused(.communications), .focused(.calendar), .focused(.documents), .focused(.visualMedia), or .focused(.audio)」。² 這個 API 確實存在：SpotlightSearchTool.Guide.focused(_ domain: ContentDomain = .items) 與 .complete、.dynamic(_:) 並列在 _CoreSpotlight_FoundationModels 介面中。⁴ 我的裝置端 AI 文章介紹了這個工具；六月時的採用步驟把預設設定與系統模型搭在一起，現在已附上一則附日期的更正。
• 從控制中心擷取效能追蹤。 「Gathering PowerProfiler and Lookback traces through the Performance Trace Control Center widget might fail to produce traces.」（透過控制中心的 Performance Trace 小工具擷取 PowerProfiler 與 Lookback 追蹤時，可能無法產生追蹤結果。）Apple 提供的因應方式是「Gather traces on iOS 27.0 beta 1 or earlier」（在 iOS 27.0 beta 1 或更早版本上擷取追蹤），對於已經更新的裝置，大多數團隊都無法採用這個方法。²
• StoreKit 測試。 「Changing the storefront or locale using SKTestSession doesn’t propagate through Storefront.updates」（用 SKTestSession 變更商店或語言環境時，不會透過 Storefront.updates 傳播），而且「Failed purchases using SKTestSession might display error dialogs even when dialogsDisabled is set to true」（即使 dialogsDisabled 設為 true，用 SKTestSession 的失敗購買仍可能顯示錯誤對話框）。²
• 捷徑與 UnionValue。 帶有「two number-related types (for example, both Int and Double)」（兩種數值相關型別，例如同時有 Int 與 Double）的參數會把數值選項顯示兩次；Apple 的因應方式是只宣告一種。²

我這週會怎麼做

1. 從 Xcode 27 封存一次，在送上 TestFlight 之前拿上面那份「連結 27 後才生效」的清單逐項檢查 App：啟動畫面鍵、場景生命週期、任何選取值可能指向隱藏分頁的 TabView，以及任何繼承了控制項修飾器的 sheet。²
2. 出貨前用正式版 SDK 建置 MetricKit 相關程式碼；依 Apple 的描述，仍引用 ScrollHitchTimeMetric 或舊 ratio 型別的二進位檔就是啟動時當機，而介面已不再匯出該名稱。²⁴
3. Grep 一下 canOpenURL、NSBundleResourceRequest、originalFilename、FileDocument、deleteEvents、asObjCRenderState 與 barMinimizeBehavior；前三個只在部署目標為 27.0 時警告，FileDocument 是軟性棄用，後三個會編譯失敗，所以 grep 就是通知。⁴
4. 如果您會讀取 HealthKit，請在授權之後呼叫 earliestAuthorizedSampleDate(for:)，並依類型限制每個查詢的起始日期；然後想清楚在使用者選定的區間上，連續記錄或基準線該怎麼定義。⁵
5. 在錯誤回報中從三個地方記錄組建編號：裝置上的 ProcessInfo、建置機器上 SDK 的 SystemVersion.plist，以及模擬器重現時的 simctl list runtimes。三者並不相同，24A437 裡有的修正，24A434 裡未必有。⁴
6. 如果您用 NSURL(string:) 從字串建立 URL，請繼續在 iOS 26 上測試：修掉 %25 重複編碼的是作業系統，不是您的重新建置；同一個 Xcode 27 二進位檔在 26.5 執行環境上會出現此問題，在 27.0 上則不會。⁴

常見問題

iOS 27.0 何時推出？組建編號是多少？

2026年9月14日（星期一），組建 24A437，與 Apple 在 9 月 11 日（星期五）公布的候選發行版是同一個組建。iPadOS 27.0 共用同一個編號。¹

Xcode 27 SDK 裡的是哪一個 iOS 27.0 組建？

Xcode 27（27A266a）內的 iPhoneOS 27.0 SDK 回報的 ProductBuildVersion 是 24A430，iOS 27.0 模擬器執行環境回報的是 24A434。兩者都不是裝置組建。⁴

iOS 27 棄用了什麼？

發行說明列出 11 條：canOpenURL:、On Demand Resources 與 NSBundleResourceRequest、PHAssetResource.originalFilename、原始的 MetricKit API、ScrollHitchTimeMetric、FileDocument、calendar.deleteEvents schema、__PKStrokeRenderState、UIKit 場景生命週期強制要求、AirPort Utility，以及一則 Weather Highlights 的語言說明。其中三條在 SDK 裡帶有硬性的 27.0 棄用版本、只在部署目標為 27.0 時警告，兩條是軟性棄用，兩條是改名，一條是移除，三條不是 API 變更。²⁴

我的 App 需要為 iOS 27 重新建置嗎？

要繼續運作的話不需要，而這些條目分成三類。SDK 門檻型：上面那 12 類連結 27 後才生效的變更，在您改用 27.0 SDK 建置之前什麼都不會改變。作業系統層級、影響 27.0 裝置上每一個二進位檔的：Neural Engine 的背景限制及其 entitlement、HealthKit 的有限歷史記錄權限流程、針對 MDM 與更新流量的 TLS 強制要求、iPadOS 27 的選單圖像變更、重要警示的修正，以及 NSURL 編碼修正。beta 二進位檔型：用 beta SDK 建置的 MetricKit 程式碼，Apple 說要用正式版 SDK 重新編譯以避免當機。Apple 對 App Store 的 SDK 最低要求自 2026年4月28日起是 26 SDK；27 SDK 的要求是之後的期限，這份說明並未訂定。²³

iOS 27 發行說明在哪裡？

在 Apple 開發者文件網站的 iOS & iPadOS Release Notes 之下，27.0 有一個獨立頁面，依分區組織，每個分區下有 New Features、Resolved Issues、Known Issues 與 Deprecations。本文的計數來自 2026年9月15日擷取的該頁面。²

NSURL 的修正是在 SDK 裡還是作業系統裡？

在作業系統裡。同一個模擬器二進位檔，以 Xcode 27 對 27.0 SDK 建置、最低 iOS 設為 26.0，在 iOS 26.5 執行環境上會重複編碼，在 iOS 27.0 執行環境上則不會；macOS 26.6.2 上的 Mac 版建置也會重複編碼；兩次模擬器執行之間除了作業系統之外沒有任何改變。⁴

資料來源