Sendable is a central concept in Swift 6, especially with strict concurrency checking enabled by default. If actor isolation protects state through execution boundaries, Sendable protects data as it crosses those boundaries.
This article examines Sendable, @unchecked Sendable, and how to use them correctly to achieve concurrency safety without breaking existing architecture.
What is Sendable?
Sendable is a protocol that marks a value as safe to transfer across concurrency domains, such as between tasks, actors, or async boundaries.
In Swift 6, the compiler requires any data crossing a concurrency boundary to conform to Sendable, otherwise compilation fails.
Why does Swift 6 enforce Sendable?
In Swift 5, passing reference types across threads relied heavily on discipline and assumptions. Swift 6 removes those assumptions by requiring proof of safety.
Sendable forces developers to reason explicitly about ownership, immutability, and data lifetime.
Value types, reference types, and Sendable
Pure value types such as immutable structs often conform to Sendable automatically. Reference types do not, as they can be mutated from multiple contexts.
As a result, many legacy classes cannot be Sendable without redesign.
@unchecked Sendable – a cautious escape hatch
@unchecked Sendable allows developers to assert safety manually when the compiler cannot verify it.
It is necessary for some legacy code, but overuse undermines the safety guarantees of Swift 6 concurrency.
Migration strategies for Sendable
A safe approach prioritizes value types, minimizes shared mutable state, and wraps sensitive reference types inside actors.
@unchecked Sendable should be treated as a temporary measure with a clear refactoring plan.
Conclusion
Sendable is not an obstacle but a tool that enables Swift 6 to deliver safe concurrency. Understanding and applying it correctly is critical for a successful migration.
