What's New in Swift (2026): The WWDC26 Update

Apple shipped two Swift releases in one WWDC cycle: 6.3 and 6.4 landed together, and the “What’s new in Swift” session covered both as a single arc of work¹. The framing matters because the changes split cleanly into two audiences. Most developers get smaller, daily-use ergonomics (drop the parentheses around any optionals, collapse a dozen @available platform names into one anyAppleOS, silence a deprecation warning in exactly one declaration). A smaller group writing performance-sensitive code gets a years-in-the-making payoff: the ownership system now reaches for loops, computed properties, and the standard library itself.

Swift in 2026 is also visibly a cross-platform, cross-language project. Apple announced an official Swift SDK for Android, distributed through swift.org⁶, faster JavaScript bridging through WebAssembly, the ability to export Swift functions back to C with a new @C attribute, and a Swift Build backend that now powers Swift Package Manager by default¹. This post walks the four sessions that define the 2026 Swift story: the language and library updates (262), the Swift Testing migration path (267), real-time services with gRPC (265), and numerical computing with MLX Swift (328).

TL;DR

• Swift 6.3 and 6.4 shipped together at WWDC26. Daily ergonomics: optional any/some without parentheses, anyAppleOS availability, the @diagnose attribute for per-declaration warning control, and module selectors (::) for name collisions¹.
• The ownership system reached ordinary code: a new Iterable protocol lets for loops borrow elements instead of copying them, and borrow/mutate accessors replace get/set to avoid copying large values in computed properties¹.
• New standard-library types ship the safe versions of old unsafe patterns: UniqueArray, UniqueBox, a single-resume Continuation, and Ref/MutableRef for holding a borrow or mutation in a variable¹.
• Swift Testing now interoperates with XCTest in both directions, with four modes (limited, complete, strict, none); Xcode 27 enables interoperability by default². The @Test, @Suite, #expect, and #require surface is documented in Apple’s Swift Testing reference⁵.
• gRPC Swift reached the point where you generate a typed client from a .proto file and get unary plus bidirectional streaming RPCs, deployable to Linux containers in the cloud³.
• MLX Swift brings NumPy-style array computing to Swift, with automatic GPU execution and grad automatic differentiation, sharing one engine across Swift, Python, C++, and C front-ends⁴.

Language Ergonomics: The Annoyances Go Away

The session opens with changes that “you might barely notice except as little annoyances going away”¹. They are worth naming because they remove friction that accumulated over a decade of the language.

Becca and Evan from the Swift team walk through Swift 6.3 and 6.4. The language section starts around 0:45.

You can now write any P? without wrapping it in parentheses. You get a warning when a Swift Concurrency task silently drops a thrown error, prompting you to either handle it in the task or save the task and check later. The old restriction on calling async functions from a defer block is gone. A class that only needed @unchecked Sendable because of a weak var property can switch that property to weak let and qualify for proper Sendable checking. A type that should not be Sendable can say so explicitly with the new ~Sendable syntax, which does not stop subclasses from being Sendable¹.

Two changes you will definitely notice. The first is availability: Apple aligned its OS version numbers last year, and Swift takes that further by letting you condense every platform name into one, anyAppleOS. When availability lines up across the platforms you care about, you specify all of them at once; when there are carve-outs, you set anyAppleOS as the default and add platform-specific attributes for the exceptions. The same name works in #if os(...) conditions¹.

The second is the @diagnose attribute, which changes the behavior of specific warnings inside a single declaration. You can tell Swift to ignore the deprecated declaration warning group in one function while you migrate to a new API, without silencing it project-wide. You can run it the other direction too: turn on strict memory safety inside a security-critical function, or promote a future-error warning to an error right now¹.

Then there are module selectors. When two imported modules both declare a type named View, the old fix was dot syntax (Rocket.SaturnV), which breaks down when a module named Rocket also contains a type named Rocket, because Swift prefers the type and then fails to find the member. Swift 6.3 introduces ::, where the name on the left is always a module name, so Rocket::SaturnV goes straight to the module. The selector works on method and property names too. Apple’s guidance is pointed: use it for conflicts between modules you do not control, and defensively in macro-generated code, but do not design APIs that intentionally collide and then lean on selectors to disambiguate¹.

Standard Library and Foundation

The standard library picked up targeted additions. A task cancellation shield runs a short region where cancellation checks always return false, so you can finish writing data to disk after the surrounding task was cancelled. mapKeyedValues passes both the key and the old value into the mapping closure, replacing the manual dictionary reconstruction that mapValues forced when you needed the key. A new file-path type, based on the one from Swift System, handles the platform differences in path representation¹.

Foundation continued its multi-year migration off Objective-C and onto Swift. Apple modernized more of Data (faster span accesses, equality checks, iteration, and mutation) and unified NSURL and CFURL into a single Swift implementation that runs faster and uses less memory. ProgressManager is a new progress-reporting type built for async/await, and the Subprocess package reached 1.0 with a simplified execution type, streamed output as AsyncBufferSequence, and a strings() method that reads output line by line while respecting grapheme cluster boundaries¹.

Ownership Reaches Ordinary Code

The performance story is the one to read closely, because it represents the moment a multi-year compiler project becomes something you can use in everyday types. The core problem is copying: you have data in one place, you need it in another, so the program copies it. When the storage stays allocated and both sides follow Swift’s exclusivity rules, the copy is unnecessary. A borrow grants read access to existing storage without copying it; a mutate grants exclusive write access. The compiler verifies both at compile time, which is what makes the technique safe where raw UnsafePointer was not¹.

The ownership and performance-tuning section begins around 19:55, covering inlining control, specialization, and the new accessors.

Several protocols now work without copying. Equatable, Comparable, and Hashable can be used on noncopyable types, and Equatable and Comparable extend to non-escapable types. Associated types can now be noncopyable or non-escapable, which is what makes the headline feature possible: a new Iterable protocol that for loops support directly¹.

The Sequence protocol everyone knows copies elements out as it iterates. Iterable lets the loop borrow them instead, which means it works with noncopyable elements and skips reference counting on objects and copy-on-write types. It can throw during iteration the way an AsyncSequence can. Because borrowing forbids mutation, exclusivity checking stops you from mutating the collection while looping over it (a frequent performance trap with Sequence). A for loop prefers Sequence when available and falls back to Iterable, and the Iterable iterator returns elements in batches of spans rather than one at a time, which makes the loop measurably more efficient for types that can hand back everything in one span¹.

Accessors got the same treatment. Apple’s example is a UniqueBox holding an InlineArray of 256 Ints, a two-kilobyte struct on a 64-bit device. With get/set, changing one element copies the whole array out and back. Switching the computed property to a borrow accessor (read-only access without copying) and a mutate accessor (exclusive in-place modification) lets Swift change one element in place, and lets the type hold noncopyable values¹.

Several new standard-library types ship the safe replacements for patterns that previously required unsafe code:

• UniqueArray behaves like Array but is noncopyable, so it stores noncopyable elements and avoids reference-counting overhead without committing to a fixed size.
• UniqueBox is a real standard-library type using the new accessors.
• Continuation checks at compile time that you resume it exactly once, making it safer than CheckedContinuation and as efficient as UnsafeContinuation.
• Ref and MutableRef act like a Span for a single value: a container for a borrow or mutation that you can store in a variable, pass, return, and use in generic types. You build a MutableRef from a write access with a prefix &, and because refs are non-escapable, Swift knows the access ends when the variable leaves scope¹.

For optimizer control, Swift 6.4 adds @inline(always) to match the long-standing @inline(never) (pair it with final on class methods, since an overridable method may still not inline), and Swift 6.3 adds @specialized, where a where clause tells the compiler to pre-generate a specialized version of a generic function for the concrete types you use most¹. You will rarely need these. When you do, as the session puts it, “you’ll be glad you have them”¹.

Swift Testing: Migration Is Now Bidirectional

Swift Testing shipped in Xcode 16 as the modern, macro-based, parallel-by-default testing library². The 2026 story is migration, and the key addition is test framework interoperability: the ability to call API from one framework inside a test body from the other, in both directions².

Jerry from the Swift Testing team demonstrates calling XCTest helpers from Swift Testing tests. The interoperability walkthrough starts around 5:48.

The migration strategy Apple recommends has not changed: leave most XCTests in place, write new tests in Swift Testing, and migrate the ones you touch most often. Both frameworks already coexist in one target. What is new is that you can reuse the helper code you built on XCTest. When a Swift Testing test calls an assertUnique helper that wraps XCTFail, that produces a cross-framework issue, and Xcode now handles it with four modes²:

• Limited: cross-framework issues from XCTest are warnings. Test plans created before Xcode 27 inherit this mode, and Swift packages on swift-tools-version: 6.3 default to it.
• Complete: those same issues stay as errors. Xcode 27 uses complete mode for new projects; Swift packages opt in by bumping to swift-tools-version: 6.4 or newer.
• Strict: cross-framework issues from XCTest stop the test with a fatal error, pointing you at every spot to replace XCTest API.
• None: opt out entirely (use only temporarily, since those issues can flag real bugs).

Cross-framework issues from Swift Testing stay errors in every mode, so you can safely call #expect and #require from inside an XCTestCase. You override the default in a package with the SWIFT_TESTING_XCTEST_INTEROP_MODE environment variable (mode name in lowercase)². The XCTest session 262 confirms the matching standard-library side: XCTest assertion failures now surface as test issues when called from Swift Testing, so you migrate without quietly losing coverage¹.

The migration cookbook covers the common patterns. XCTSkip becomes Test.cancel (or, better, an .enabled/.disabled trait that moves the enablement logic out of the test body). continueAfterFailure = false becomes #require, which throws on failure and halts the test, letting you choose per-expectation which failures stop execution². Interoperability supports a limited but practical API set: all XCTest assertions, both expectation macros (#expect and #require), the known-issue API to mark XCTest failures as known, and Test.cancel to skip XCTest cases².

For the API surface itself (the macros, the trait vocabulary, what stays in XCTest), the companion post on Swift Testing vs. XCTest covers the mental model. Two notes carry forward from there: UI automation and performance testing remain XCTest-only, and code that throws Objective-C exceptions must stay in XCTests written in Objective-C, because Swift code cannot safely handle those exceptions². Once migrated, you get parameterized tests (each argument a separate case, all running in parallel) and exit tests that run code expected to crash in a child process to verify the termination, available on macOS, Linux, FreeBSD, and Windows².

gRPC Swift: Typed Real-Time Services

The server story is the clearest demonstration that Swift now spans client and backend with one language. The gRPC session builds an iOS app talking to a Swift server, generated entirely from a .proto specification³.

George from the Swift Server team explains the four RPC types. The streaming section, including bidirectional streaming, starts around 11:06.

gRPC is a Cloud Native Computing Foundation project where you define APIs as functions with typed inputs and outputs rather than HTTP endpoints, and generate the client code from the spec³. The workflow: define the service in a .proto file, add grpc-swift-nio-transport (networking on SwiftNIO) and grpc-swift-protobuf (the build plugin) as package dependencies, attach the GRPCProtobufGenerator run-build-tool plugin, and recompile to generate the typed client.

A unary RPC like ListRaces sends one request and gets one response. The session’s go-karts demo wires it into a SwiftUI view with withGRPCClient, then refactors to share a single client through the SwiftUI environment so views reuse connections, and disconnects when the scene enters the background³. Protobuf serializes messages to binary keyed by field number rather than field name, which makes a message “roughly half the size of the equivalent JSON message”³, a real win on poor mobile networks. Apple notes the same efficiency drives its own infrastructure: gRPC Swift powers interprocess communication in the open-source Containerization framework and underpins Private Cloud Compute, iCloud Keychain and Photos, and SharePlay file sharing³.

The streaming support is what enables real time. Beyond unary RPCs there are client-streaming (many requests, one response), server-streaming (one request, many responses, like a live commentary feed), and bidirectional streaming. The demo uses bidirectional streaming for live race updates: the client streams which event types it wants while the server streams matching events. On the server side that becomes an async function whose request parameter is an AsyncSequence of messages and whose response parameter is a writer, handled with a task group and a mutex-protected set of subscribed event types³. Deployment is a multi-stage Containerfile (build with swift:latest, copy the release binary into swift:slim), run on Google Cloud Run with HTTP/2, then the client flips its transport security from plaintext to TLS³.

MLX Swift: Numerical Computing That Reads Like Math

The MLX session targets a different developer entirely: anyone writing simulations, signal processing, rendering, or model training. MLX Swift uses n-dimensional arrays as its central abstraction, the way NumPy does, so “most NumPy code can be translated to MLX Swift with minimal changes”⁴.

David Koski walks through the Mandelbrot example. The array-computing comparison against plain Swift begins around 4:28.

MLX sits alongside the existing Apple numerical stack rather than replacing it: Accelerate for hand-tuned CPU vector primitives, BNNS for neural-network building blocks, Metal Performance Shaders for direct GPU kernels, and Swift Numerics for the Complex type. You reach for MLX Swift when the goal is “writing mathematical code with an eye for performance” and you want the code to look like the math⁴.

Two features make that possible. Lazy evaluation builds a compute graph as you write array operations and runs nothing until you call eval or read a value, which is why a loop calls eval each step to keep the graph small. Lazy evaluation also powers automatic GPU execution and automatic differentiation through the grad function transformation⁴. The Mandelbrot example collapses a per-pixel scalar loop into two lines (z = z * z + c applied to the whole grid, then a count of bounded iterations), runs on the GPU by default, and the session notes “10x faster is certainly possible”⁴. A heat-distribution solver expresses Jacobi iteration as a single conv2d call. The curve-fitting example uses grad to compute exact gradients with no hand-written derivatives, the same idea behind training every ML model⁴.

MLX Swift is open source under an MIT license, installable through Swift Package Manager, and one front-end among four (Swift, Python, C++, and C) sharing the same operations and lazy-evaluation model, so you can “prototype in Python and ship in Swift”⁴. The ecosystem includes mlx-swift (the core framework), mlx-swift-lm (language-model implementations), and mlx-swift-examples (runnable LLM, diffusion, and training samples)⁴. For the on-device-ML context around it, see MLX on-device ML on Apple Silicon.

What to Adopt First

Order the work by who you are.

If you ship apps and rarely touch the compiler’s performance knobs, adopt the ergonomics now and ignore the ownership system. Replace stacked @available lines with anyAppleOS where your platforms align, use @diagnose to silence deprecation warnings exactly where you are mid-migration, and reach for module selectors (::) the next time a dependency collides with SwiftUI on a name like View¹.

If you maintain a large XCTest suite, turn on interoperability and start writing new tests in Swift Testing today. Move existing test plans to complete mode so cross-framework issues are errors you cannot miss, reuse your XCTest helpers through interoperability rather than rewriting them up front, and migrate the files you touch most. Keep UI automation, performance tests, and Objective-C-exception tests in XCTest¹².

If you write performance-sensitive code, the ownership additions are the headline. Audit hot computed properties that hold large values and switch them from get/set to borrow/mutate. Where you previously dropped to UnsafePointer, look at Ref/MutableRef, UniqueArray, and the single-resume Continuation. Measure before reaching for @inline(always) or @specialized, because the optimizer is usually right and forcing it can make the binary larger and slower¹.

If your work is server-side or numerical, the new packages are production-ready entry points: gRPC Swift gives you a typed client and bidirectional streaming from a .proto file, and MLX Swift gives you GPU-accelerated array computing and automatic differentiation that reads like the math³⁴.

FAQ

What is the difference between Swift 6.3 and Swift 6.4?

Apple developed and shipped both in the same WWDC26 cycle and presented them together. Roughly, Swift 6.3 introduced module selectors (::) and the @specialized attribute, and delivered the first official Swift SDK for Android. Swift 6.4 added anyAppleOS availability, optional any/some without parentheses, the Iterable protocol for for loops, borrow/mutate accessors, @inline(always), the @C attribute for exporting Swift functions to C, and the embedded-Swift debugging improvements. The session covers the two as one continuous body of work¹.

Do I have to migrate from XCTest to Swift Testing?

No. XCTest still ships and still works, and Apple’s recommendation is incremental: write new tests in Swift Testing and migrate old ones as you touch them. Test framework interoperability lets the two coexist in one target and call each other’s API, so you can reuse XCTest helpers from Swift Testing tests. UI automation, performance testing, and code that throws Objective-C exceptions stay in XCTest¹².

What does the new Iterable protocol do that Sequence does not?

Sequence copies elements out as it iterates. Iterable lets the for loop borrow elements instead, so it works with noncopyable elements and skips reference counting on objects and copy-on-write types. It returns elements in batches of spans rather than one at a time, which is more efficient, and it can throw during iteration. Because borrowing forbids mutation, you cannot mutate the collection while looping over it. A for loop prefers Sequence when available and falls back to Iterable¹.

When should I use MLX Swift instead of Accelerate or Metal Performance Shaders?

Use MLX Swift when your primary goal is writing mathematical code with an eye for performance and you want the code to read like the math, with automatic GPU execution and automatic differentiation through grad. Accelerate remains the choice for hand-tuned CPU vector primitives, BNNS for neural-network building blocks, and Metal Performance Shaders for direct GPU kernel access. MLX sits alongside them rather than replacing them⁴.

Is gRPC Swift only for backend services?

No. The WWDC session builds an iOS app as the gRPC client, generating a typed client from a .proto file, and shows unary plus bidirectional streaming RPCs driving live UI updates. Protobuf’s binary encoding produces messages roughly half the size of equivalent JSON, which helps on poor mobile networks. Apple also uses gRPC Swift for interprocess communication and in services including Private Cloud Compute, iCloud Keychain and Photos, and SharePlay file sharing³.

The Apple Ecosystem Cluster

Swift’s 2026 update threads through the rest of the Apple Ecosystem series: the Swift Testing vs. XCTest breakdown of the testing model, the Observable internals in SwiftUI that the concurrency changes touch, what SwiftUI is made of at the framework level, and MLX on-device ML on Apple Silicon for the numerical-computing context. The hub for all of it is the Apple Ecosystem Series. For building iOS apps with AI agents in the loop, see the iOS Agent Development guide.

References