Swift 新功能總覽（2026）：WWDC26 更新

Apple 在同一個 WWDC 週期內推出了兩個 Swift 版本：6.3 與 6.4 同時登場，而「What’s new in Swift」議程把兩者視為一條連貫的工作主軸來介紹¹。這樣的框架很重要，因為這些變更清楚地分成兩種受眾。大多數開發者得到的是更小、日常可用的人體工學改善（去掉 any 選擇性型別外圍的括號、把十幾個 @available 平台名稱收斂成一個 anyAppleOS、在剛好一個宣告中消除棄用警告）。另一群撰寫對效能敏感程式碼的較小族群,則迎來醞釀多年的成果：所有權系統現在延伸到了 for 迴圈、計算屬性,乃至於標準函式庫本身。

2026 年的 Swift 也明顯是一個跨平台、跨語言的專案。Apple 宣布了一套官方的 Android 版 Swift SDK,透過 swift.org 發布⁶、藉由 WebAssembly 達成更快的 JavaScript 橋接、能用全新的 @C 屬性把 Swift 函式匯出回 C,以及一個如今預設驅動 Swift Package Manager 的 Swift Build 後端¹。本文走過定義 2026 年 Swift 故事的四場議程:語言與函式庫更新（262）、Swift Testing 遷移路徑（267）、用 gRPC 打造即時服務（265）,以及用 MLX Swift 進行數值運算（328）。

摘要

• Swift 6.3 與 6.4 在 WWDC26 一同推出。日常人體工學:不帶括號的選擇性 any/some、anyAppleOS 可用性、用於逐宣告控制警告的 @diagnose 屬性,以及處理名稱衝突的模組選擇器（::）¹。
• 所有權系統延伸至一般程式碼:全新的 Iterable 協定讓 for 迴圈借用（borrow）元素而非複製它們,而 borrow/mutate 存取器取代 get/set,以避免在計算屬性中複製大型值¹。
• 新的標準函式庫型別推出了舊有不安全模式的安全版本:UniqueArray、UniqueBox、單次恢復的 Continuation,以及用於在變數中保有借用或變動的 Ref/MutableRef¹。
• Swift Testing 現在與 XCTest 雙向互通,提供四種模式（limited、complete、strict、none）；Xcode 27 預設啟用互通性²。@Test、@Suite、#expect 與 #require 介面記載於 Apple 的 Swift Testing 參考文件⁵。
• gRPC Swift 已成熟到你能從一個 .proto 檔產生型別化的用戶端,得到一元（unary）加上雙向串流 RPC,並可部署到雲端的 Linux 容器³。
• MLX Swift 為 Swift 帶來 NumPy 風格的陣列運算,具備自動 GPU 執行與 grad 自動微分,在 Swift、Python、C++ 與 C 前端間共用同一個引擎⁴。

語言人體工學:惱人之處消失了

這場議程一開始介紹的變更,「你可能幾乎不會注意到,只會覺得一些小惱人之處消失了」¹。這些變更值得一一點名,因為它們移除了過去十年間在這門語言累積下來的摩擦。

Swift 團隊的 Becca 與 Evan 帶你走過 Swift 6.3 與 6.4。語言段落約從 0:45 開始。

現在你可以直接寫 any P?,而不必用括號把它包起來。當 Swift Concurrency 任務默默丟棄一個被擲出的錯誤時,你會收到警告,提示你要不在任務中處理它,要不就把任務存起來稍後檢查。過去禁止在 defer 區塊中呼叫 async 函式的限制已經消失,因此非同步清理現在能像延遲的同步清理一直以來的運作方式那樣執行（SE-0493,Swift 6.4）⁷。一個僅因 weak var 屬性而需要 @unchecked Sendable 的類別,可以把該屬性改成 weak let,從而符合正規的 Sendable 檢查。一個不該是 Sendable 的型別,可以用全新的 ~Sendable 語法明確表態,而這並不會阻止其子類別成為 Sendable¹。

有兩項變更你一定會注意到。第一是可用性:Apple 去年對齊了其作業系統版本號,而 Swift 更進一步,讓你能把每一個平台名稱濃縮成一個 anyAppleOS。當你在意的各平台可用性一致時,就一次指定全部；當有例外切割時,就把 anyAppleOS 設為預設,再為例外加上平台專屬的屬性。同樣的名稱也適用於 #if os(...) 條件式¹。

第二是 @diagnose 屬性,它能在單一宣告內改變特定警告的行為。你可以告訴 Swift 在某個函式中忽略 deprecated declaration 警告群組,以便你遷移到新的 API,而不必在整個專案範圍內把它消音。你也能反向操作:在某個攸關安全的函式內開啟嚴格記憶體安全,或是把一個未來會變成錯誤的警告當下就升級為錯誤¹。Swift 團隊的工程經理 Holly Borla 在收尾 WWDC26 時把它列為她的亮點:「我最喜歡的新功能之一是 @Diagnose 屬性,它讓你控制程式碼中警告的行為,這讓你能做到像是抑制棄用警告之類的事,但它也讓你能做到像是以更細的粒度選擇加入嚴格記憶體安全或嚴格並行診斷,這對於例如遷移到 Swift 6 語言模式很有幫助。」⁸ 她以同樣的方式定位整個 6.4 版本:這些更新「移除了那些摩擦點」,好讓開發者能專注於用清晰、優美的程式碼表達他們的想法⁸。

接著是模組選擇器。當兩個被匯入的模組都宣告了一個名為 View 的型別時,過去的解法是用點語法（Rocket.SaturnV）,但當一個名為 Rocket 的模組裡也含有一個名為 Rocket 的型別時,這招就行不通了,因為 Swift 會優先選型別,然後找不到成員。Swift 6.3 引入了 ::,其中左側的名稱永遠是模組名稱,所以 Rocket::SaturnV 會直接指向該模組。這個選擇器也適用於方法與屬性名稱。Apple 的指引很明確:把它用於你無法掌控的模組之間的衝突,以及在巨集產生的程式碼中防禦性地使用,但不要刻意設計會互相衝突的 API,然後再倚賴選擇器來消除歧義¹。

標準函式庫與 Foundation

標準函式庫增添了針對性的功能。一個任務取消防護罩（withTaskCancellationShield,SE-0504,Swift 6.4）會執行一小段取消檢查永遠回傳 false 的區域,因此即使外圍任務已被取消,像是完成一筆寫入磁碟的非同步清理仍會執行⁷。mapKeyedValues 會把鍵與舊值都傳入映射閉包,取代了當你需要鍵時 mapValues 強迫你做的手動字典重建。一個以 Swift System 中的型別為基礎的新檔案路徑型別,則處理了路徑表示法在各平台間的差異¹。

Foundation 持續其為期多年、從 Objective-C 遷移到 Swift 的歷程。Apple 現代化了更多 Data（更快的 span 存取、相等性檢查、迭代與變動）,並把 NSURL 與 CFURL 統一成單一的 Swift 實作,執行更快且使用更少記憶體。ProgressManager 是一個為 async/await 打造的全新進度回報型別,而 Subprocess 套件達到了 1.0,具備簡化的執行型別、以 AsyncBufferSequence 串流的輸出,以及一個在尊重字素叢集邊界的同時逐行讀取輸出的 strings() 方法¹。

所有權延伸至一般程式碼

效能這條故事線值得細讀,因為它代表一個耗時多年的編譯器專案,終於變成你能用在日常型別上的東西。核心問題在於複製:你的資料在某處,而你需要它在另一處,於是程式就複製它。當儲存空間維持已配置狀態、且兩側都遵循 Swift 的互斥規則時,這次複製是不必要的。借用（borrow）授予對既有儲存空間的讀取存取而不複製它；變動（mutate）則授予獨占的寫入存取。編譯器會在編譯期驗證這兩者,而這正是讓這項技術在原始 UnsafePointer 辦不到的地方依然安全的原因¹。

所有權與效能調校段落約從 19:55 開始,涵蓋內聯（inlining）控制、特化（specialization）與新的存取器。

有幾個協定現在不需要複製就能運作。Equatable、Comparable 與 Hashable 可用於不可複製（noncopyable）型別,而 Equatable 與 Comparable 更延伸到不可逃逸（non-escapable）型別。關聯型別現在也可以是不可複製或不可逃逸的,而這正是讓那項招牌功能得以實現的關鍵:一個 for 迴圈直接支援的全新 Iterable 協定¹。

人人皆知的 Sequence 協定會在迭代時把元素複製出來。Iterable 則讓迴圈改為借用它們,這意味著它能與不可複製元素搭配運作,並在物件與寫入時複製（copy-on-write）型別上略過參考計數。它能像 AsyncSequence 那樣在迭代過程中擲出錯誤。由於借用禁止變動,互斥檢查會阻止你在迴圈過程中變動該集合（這是 Sequence 常見的效能陷阱）。for 迴圈在 Sequence 可用時會優先採用,並退而求其次使用 Iterable,而 Iterable 迭代器是以 span 的批次回傳元素,而非一次一個,這讓那些能在單一 span 內交回所有東西的型別,在迴圈上的效率有可衡量的提升¹。

存取器也得到了同樣的待遇。Apple 的範例是一個持有 256 個 Int 的 InlineArray 的 UniqueBox,在 64 位元裝置上是個兩 KB 的結構。使用 get/set 時,改變其中一個元素會把整個陣列複製出來再複製回去。把該計算屬性換成 borrow 存取器（不複製的唯讀存取）與 mutate 存取器（獨占的就地修改）後,Swift 就能就地改變單一元素,也讓該型別能持有不可複製的值¹。

有幾個新的標準函式庫型別推出了過去需要不安全程式碼的模式之安全替代品:

• UniqueArray 行為像 Array,但是不可複製,因此它能儲存不可複製元素,並在不必固定大小的前提下避免參考計數的額外開銷。
• UniqueBox 是一個使用新存取器的真正的標準函式庫型別。
• Continuation 會在編譯期檢查你剛好恢復它一次,使它比 CheckedContinuation 更安全,又與 UnsafeContinuation 一樣高效。
• Ref 與 MutableRef 的作用就像針對單一值的 Span:一個用來裝載借用或變動的容器,你可以把它存進變數、傳遞、回傳,並用於泛型型別中。你以前綴 & 從一次寫入存取建構一個 MutableRef,而由於 ref 是不可逃逸的,Swift 知道當變數離開作用域時該次存取便告結束¹。

UniqueArray 與固定容量的 RigidArray 落腳於一個全新的 Containers 模組（SE-0527,原則上已接受）,而你今天就能透過 swift-collections 1.3 使用這兩者,等它們日後再正式進入標準函式庫⁷。

至於最佳化器控制,Swift 6.4 新增了 @inline(always),以對應由來已久的 @inline(never)（在類別方法上請搭配 final 使用,因為可覆寫的方法仍可能不會內聯）,而 Swift 6.3 新增了 @specialized,其中一個 where 子句會告訴編譯器,為你最常用的具體型別預先產生一個泛型函式的特化版本¹。你很少會需要這些。當你真的需要時,正如議程所說的,「你會慶幸自己有它們」¹。

Swift Testing:遷移現在是雙向的

Swift Testing 在 Xcode 16 中推出,是現代化、以巨集為基礎、預設並行的測試函式庫²。2026 年的故事是遷移,而關鍵的新增功能是測試框架互通性:能在一個框架的測試主體內呼叫另一個框架 API 的能力,而且是雙向的²。

Swift Testing 團隊的 Jerry 示範從 Swift Testing 測試呼叫 XCTest 輔助函式。互通性的逐步講解約從 5:48 開始。

Apple 建議的遷移策略沒有改變:讓大多數 XCTest 維持原狀、用 Swift Testing 撰寫新測試,並遷移你最常碰的那些。兩個框架原本就已在同一個 target 中共存。新的地方在於,你可以重複使用你以 XCTest 建構的輔助程式碼。當一個 Swift Testing 測試呼叫一個包裹了 XCTFail 的 assertUnique 輔助函式時,那會產生一個跨框架問題,而 Xcode 現在會以四種模式來處理它²:

• Limited: 來自 XCTest 的跨框架問題是警告。在 Xcode 27 之前建立的測試計畫會繼承此模式,而 swift-tools-version: 6.3 的 Swift 套件預設採用它。
• Complete: 那些相同的問題會維持為錯誤。Xcode 27 對新專案使用 complete 模式;Swift 套件則藉由升級到 swift-tools-version: 6.4 或更新版本來選擇加入。
• Strict: 來自 XCTest 的跨框架問題會以致命錯誤中止測試,指出每一處需要替換 XCTest API 的地方。
• None: 完全退出（請僅暫時使用,因為那些問題可能標示出真正的臭蟲）。

來自 Swift Testing 的跨框架問題在每一種模式下都維持為錯誤,因此你可以安全地從 XCTestCase 內部呼叫 #expect 與 #require。你可以在套件中用 SWIFT_TESTING_XCTEST_INTEROP_MODE 環境變數覆寫預設值（模式名稱用小寫）²。XCTest 議程 262 確認了相對應的標準函式庫端:從 Swift Testing 呼叫時,XCTest 斷言失敗現在會以測試問題的形式浮現,因此你在遷移時不會悄悄失去測試涵蓋率¹。

這份遷移食譜涵蓋了常見的模式。XCTSkip 變成 Test.cancel（或者更好的做法,是用一個把啟用邏輯移出測試主體的 .enabled/.disabled 特徵）。continueAfterFailure = false 變成 #require,它會在失敗時擲出並中止測試,讓你能逐一針對每個期望選擇哪些失敗要停止執行²。互通性支援一組有限但實用的 API:所有 XCTest 斷言、兩個期望巨集（#expect 與 #require）、把 XCTest 失敗標示為已知的 known-issue API,以及用來略過 XCTest 案例的 Test.cancel²。

至於 API 介面本身(那些巨集、特徵詞彙、哪些留在 XCTest),姊妹文章 Swift Testing vs. XCTest 涵蓋了其心智模型。有兩點要從那裡延續過來:UI 自動化與效能測試依然僅限 XCTest,而會擲出 Objective-C 例外的程式碼必須留在以 Objective-C 撰寫的 XCTest 中,因為 Swift 程式碼無法安全地處理那些例外²。一旦完成遷移,你就能得到參數化測試(每個引數是一個獨立案例,全部並行執行),以及在子行程中執行預期會當機的程式碼以驗證其終止的退出測試,可用於 macOS、Linux、FreeBSD 與 Windows²。

gRPC Swift:型別化的即時服務

伺服器這條故事線最清楚地展現了 Swift 如今能用一種語言橫跨用戶端與後端。這場 gRPC 議程打造了一個與 Swift 伺服器對話的 iOS app,完全從一份 .proto 規格產生而來³。

Swift Server 團隊的 George 解說四種 RPC 型別。串流段落,包含雙向串流,約從 11:06 開始。

gRPC 是 Cloud Native Computing Foundation 的一個專案,你在其中把 API 定義為帶有型別化輸入與輸出的函式,而非 HTTP 端點,並從規格產生用戶端程式碼³。工作流程如下:在一個 .proto 檔中定義服務、把 grpc-swift-nio-transport（基於 SwiftNIO 的網路）與 grpc-swift-protobuf（建置外掛）加為套件相依、附加 GRPCProtobufGenerator 這個 run-build-tool 外掛,然後重新編譯以產生型別化的用戶端。

像 ListRaces 這樣的一元 RPC 會送出一個請求並取得一個回應。議程的卡丁車示範用 withGRPCClient 把它接進一個 SwiftUI 視圖,接著重構為透過 SwiftUI 環境共用單一用戶端,好讓各視圖重複使用連線,並在場景進入背景時中斷連線³。Protobuf 把訊息以欄位編號(而非欄位名稱)為鍵序列化成二進位,這讓一則訊息「大約是等價 JSON 訊息的一半大小」³,在訊號不佳的行動網路上是實實在在的優勢。Apple 指出同樣的效率也驅動著它自己的基礎設施:gRPC Swift 在開源的 Containerization 框架中驅動跨行程通訊,並支撐著 Private Cloud Compute、iCloud Keychain 與照片,以及 SharePlay 檔案分享³。

串流支援正是促成即時功能的關鍵。除了一元 RPC,還有用戶端串流(多個請求、一個回應)、伺服器串流(一個請求、多個回應,像一道即時轉播動態)以及雙向串流。這個示範把雙向串流用於即時賽事更新:用戶端串流它想要哪些事件型別,同時伺服器串流符合條件的事件。在伺服器端,那會變成一個 async 函式,其請求參數是一個訊息的 AsyncSequence,其回應參數是一個寫入器,並以一個任務群組與一組受互斥鎖保護的已訂閱事件型別來處理³。部署則是一個多階段的 Containerfile(用 swift:latest 建置、把 release 二進位檔複製進 swift:slim),以 HTTP/2 在 Google Cloud Run 上執行,接著用戶端把它的傳輸安全性從明文切換為 TLS³。

MLX Swift:讀起來像數學的數值運算

這場 MLX 議程鎖定的是截然不同的開發者:任何撰寫模擬、訊號處理、算繪或模型訓練的人。MLX Swift 以 n 維陣列作為其核心抽象,做法和 NumPy 一樣,因此「大多數 NumPy 程式碼只需極少的更動就能轉譯成 MLX Swift」⁴。

David Koski 帶你走過 Mandelbrot 範例。對比純 Swift 的陣列運算約從 4:28 開始。

MLX 是與既有的 Apple 數值技術堆疊並存,而非取而代之:Accelerate 提供手工調校的 CPU 向量原語、BNNS 提供神經網路的建構區塊、Metal Performance Shaders 提供直接的 GPU 核心,而 Swift Numerics 提供 Complex 型別。當目標是「以著眼於效能的方式撰寫數學程式碼」、且你希望程式碼看起來就像數學時,你就會選用 MLX Swift⁴。

有兩項功能讓這成為可能。惰性求值(lazy evaluation)會在你撰寫陣列運算時建立一張運算圖,並在你呼叫 eval 或讀取一個值之前什麼都不執行,這正是為什麼一個迴圈會在每一步呼叫 eval 以維持運算圖精簡。惰性求值也驅動了自動 GPU 執行,以及透過 grad 函式轉換達成的自動微分⁴。Mandelbrot 範例把一個逐像素的純量迴圈濃縮成兩行(對整個格點套用 z = z * z + c,再計算有界迭代的數量),預設在 GPU 上執行,而議程指出「快上 10 倍當然是有可能的」⁴。一個熱傳導求解器把 Jacobi 迭代表達為單一一次 conv2d 呼叫。曲線擬合範例則用 grad 在沒有任何手寫導數的情況下計算精確梯度,這正是訓練每一個 ML 模型背後的同一個概念⁴。

MLX Swift 採用 MIT 授權的開放原始碼,可透過 Swift Package Manager 安裝,是共用同一套運算與惰性求值模型的四個前端(Swift、Python、C++ 與 C)之一,因此你能「用 Python 製作原型,再用 Swift 出貨」⁴。其生態系包含 mlx-swift(核心框架)、mlx-swift-lm(語言模型實作),以及 mlx-swift-examples(可執行的 LLM、擴散與訓練範例)⁴。關於圍繞它的裝置端 ML 脈絡,請參閱 MLX on-device ML on Apple Silicon。

該先採用什麼

依你的身分來安排這些工作的先後。

如果你出貨 app 且很少動到編譯器的效能旋鈕,現在就採用人體工學改善,並忽略所有權系統。在你的平台一致之處,用 anyAppleOS 取代層層堆疊的 @available 行;用 @diagnose 在你正進行遷移之處精準地消除棄用警告;並在下次某個相依套件與 SwiftUI 在像 View 這樣的名稱上衝突時,動用模組選擇器(::)¹。

如果你維護一套龐大的 XCTest 測試,今天就開啟互通性並開始用 Swift Testing 撰寫新測試。把既有的測試計畫移到 complete 模式,讓跨框架問題成為你不會錯過的錯誤;透過互通性重複使用你的 XCTest 輔助函式,而非一開始就重寫它們;並遷移你最常碰的那些檔案。把 UI 自動化、效能測試與 Objective-C 例外測試留在 XCTest 中¹²。

如果你撰寫對效能敏感的程式碼,所有權的新增功能就是重頭戲。稽核那些持有大型值的熱點計算屬性,把它們從 get/set 換成 borrow/mutate。在你過去退而使用 UnsafePointer 之處,看看 Ref/MutableRef、UniqueArray 與單次恢復的 Continuation。在動用 @inline(always) 或 @specialized 之前先做衡量,因為最佳化器通常是對的,而強迫它可能讓二進位檔變得更大也更慢¹。

如果你的工作偏伺服器端或數值運算,這些新套件是可用於正式環境的進入點:gRPC Swift 從一份 .proto 檔給你一個型別化用戶端與雙向串流,而 MLX Swift 給你 GPU 加速的陣列運算,以及讀起來就像數學的自動微分³⁴。

常見問題

Swift 6.3 與 Swift 6.4 有什麼差別?

Apple 在同一個 WWDC26 週期內開發並推出兩者,並將它們一同呈現。大致而言,Swift 6.3 引入了模組選擇器(::)與 @specialized 屬性,並交付了首套官方的 Android 版 Swift SDK。Swift 6.4 加入了 anyAppleOS 可用性、不帶括號的選擇性 any/some、用於 for 迴圈的 Iterable 協定、borrow/mutate 存取器、@inline(always)、用於把 Swift 函式匯出到 C 的 @C 屬性,以及嵌入式 Swift 的除錯改善。議程把兩者視為一個連貫的工作整體來介紹¹。

我一定要從 XCTest 遷移到 Swift Testing 嗎?

不必。XCTest 依然有出貨且依然能用,而 Apple 的建議是漸進式的:用 Swift Testing 撰寫新測試,並在你碰到舊測試時順手遷移它們。測試框架互通性讓兩者能在同一個 target 中共存並互相呼叫對方的 API,因此你能從 Swift Testing 測試重複使用 XCTest 輔助函式。UI 自動化、效能測試,以及會擲出 Objective-C 例外的程式碼則留在 XCTest 中¹²。

全新的 Iterable 協定能做到 Sequence 做不到的什麼事?

Sequence 會在迭代時把元素複製出來。Iterable 則讓 for 迴圈改為借用元素,因此它能與不可複製元素搭配運作,並在物件與寫入時複製型別上略過參考計數。它以 span 的批次回傳元素,而非一次一個,效率更高,而且它能在迭代過程中擲出錯誤。由於借用禁止變動,你無法在迴圈過程中變動該集合。for 迴圈在 Sequence 可用時會優先採用,並退而求其次使用 Iterable¹。

我何時該用 MLX Swift,而非 Accelerate 或 Metal Performance Shaders?

當你的首要目標是以著眼於效能的方式撰寫數學程式碼、且你希望程式碼讀起來就像數學,具備自動 GPU 執行與透過 grad 的自動微分時,就用 MLX Swift。Accelerate 仍是手工調校 CPU 向量原語的首選、BNNS 用於神經網路建構區塊,而 Metal Performance Shaders 用於直接存取 GPU 核心。MLX 是與它們並存,而非取而代之⁴。

gRPC Swift 只適用於後端服務嗎?

不是。這場 WWDC 議程把一個 iOS app 打造成 gRPC 用戶端,從一份 .proto 檔產生型別化用戶端,並展示一元加上雙向串流 RPC 驅動即時 UI 更新。Protobuf 的二進位編碼產出的訊息大約是等價 JSON 的一半大小,這在訊號不佳的行動網路上很有幫助。Apple 也把 gRPC Swift 用於跨行程通訊,以及包含 Private Cloud Compute、iCloud Keychain 與照片,以及 SharePlay 檔案分享在內的服務中³。

Apple 生態系叢集

Swift 的 2026 更新貫穿了 Apple 生態系系列的其餘部分:測試模型的 Swift Testing vs. XCTest 拆解、並行變更所觸及的 Observable internals in SwiftUI、框架層級的 what SwiftUI is made of,以及作為數值運算脈絡的 MLX on-device ML on Apple Silicon。這一切的樞紐是 Apple Ecosystem Series。至於把 AI 代理納入流程來打造 iOS app,請參閱 iOS Agent Development guide。

參考資料