DataRace

Swift Concurrency fundamentally changed how asynchronous programming works in Swift. Before async/await arrived, developers relied heavily on completion handlers, delegates, Combine pipelines, and Grand Central Dispatch (GCD). These approaches worked, but they often made asynchronous code difficult to reason about, debug, and maintain. With Swift Concurrency, Apple introduced a model centered around tasks, structured concurrency, and actor isolation. One of the most important concepts to understand in this model is the difference between structured and unstructured concurrency. ...

With the introduction of Structured Concurrency and Actors, Apple fundamentally changed how we write asynchronous Swift code. However, simply using async/await or Task does not automatically make your code safe from data races. To achieve true thread safety—and to compile under Swift 6’s Strict Concurrency checks—you must understand concurrency domains and the Sendable protocol. In this post, we will explore what Sendable is, when and how to use it, and the dangerous anti-patterns you must avoid when trying to quiet the compiler. ...

With the introduction of Swift Concurrency, Actors became the ultimate tool for protecting shared mutable state. By isolating their state and ensuring that only one task can access that state at a time, actors eliminate traditional data races. However, they introduce a new, subtle, and incredibly dangerous concept that trips up even experienced developers: Actor Reentrancy. If you assume that an actor behaves exactly like a serial DispatchQueue or an NSLock, you are going to write buggy code. Let’s explore what actor reentrancy is, why it breaks your logic, and how to fix it using a real-world banking scenario. ...