Swift 6.4 Development Snapshots Bring Full Existential Types and Untyped Throws to Embedded Swift
Doug Gregor detailed Embedded Swift additions landing ahead of Swift 6.4: broader `any` type support, untyped throws, and full metatype support.
Overview
Embedded Swift, the compiler mode that targets microcontrollers and other resource-constrained hardware, is gaining a set of language features in development snapshots ahead of Swift 6.4, according to a Swift.org blog post by Doug Gregor, a member of the Swift Language Steering Group. The post, published August 20, 2026, describes broader support for existential (any) types, untyped throws, and metatypes — capabilities that were previously restricted or entirely unsupported in Embedded Swift’s compilation model.
Swift 6.4 was previously reported to have landed at WWDC 2026 with features including async defer and a Borrowing Iterable protocol, but that coverage did not touch Embedded Swift, which follows its own improvement cadence detailed in a recurring blog series tied to each Swift release.
What We Know
- Embedded Swift now supports all
anytypes, not just those constrained toAnyObject, according to Gregor’s post. The post notes that even with this expansion, “a generic function cannot be called on ananytype” because of Embedded Swift’s compilation model, which avoids the dynamic dispatch machinery used in regular Swift. - Untyped throws — throwing a value of
any Errorrather than a specific typed error — is now fully supported. Gregor writes that “Typed throws should still be preferred” for code that wants to avoid heap allocations, since throwingany Errortypically requires one. The same wording appears in the associated Swift Forums announcement thread, which Gregor also posted August 20. - Complete support for metatype instances has been added, including existential metatypes such as
any (DefaultInitializable.Type), according to the blog post. - The compiler now surfaces warnings for constructs with dynamic runtime costs through a
PerformanceHintsdiagnostic group, per the post. - On the library side, the post lists floating-point parsing from strings and concurrency error handling for throwing tasks and task groups as newly available in Embedded Swift.
- The changes are available now in Swift development snapshots, not in a released version — GitHub’s release listing for the swift-lang/swift repository shows no
swift-6.4-RELEASEtag yet, with Swift 6.3.3 the latest stable release. - Untyped throws and calling generic functions on existential values were previously flagged as unsupported constructs under a diagnostic group Swift 6.3 introduced called
EmbeddedRestrictions, according to the Swift 6.3 edition of the same blog series — confirming that untyped throws is a genuinely new capability rather than a restatement of existing support. - Embedded Swift is described on Swift.org’s Embedded Swift page as a “firmware‑optimized compilation mode that produces compact binaries with predictable performance for bare‑metal devices,” targeting chips such as ARM and RISC-V, with example platforms including the Raspberry Pi Pico, STM32 chips, and ESP32 microcontrollers. The page cites a Conway’s Game of Life implementation compiled to 788 bytes for the Playdate handheld as an illustration of the binary sizes the mode targets.
What We Don’t Know
- Swift.org’s post does not give a target ship date for Swift 6.4 itself; the features are described only as available in current development snapshots.
- The post does not specify how many additional existential-type or throws-related use cases remain unsupported in Embedded Swift after this round of changes, beyond noting that generic functions still cannot be called on
anytypes.
Analysis
Embedded Swift’s restrictions have largely tracked the tradeoffs of avoiding a full runtime on bare-metal hardware: existential types and untyped error handling both typically rely on dynamic dispatch or heap allocation, mechanisms Embedded Swift was designed to minimize or eliminate. Bringing broader any type support and untyped throws into the mode, even with the stated caveats around generics and allocation, narrows the gap between what firmware developers can write in Embedded Swift and what’s available in general-purpose Swift — without changing the compilation model’s core goal of producing compact, predictable binaries for microcontroller-class devices.