Understanding Actors in Swift

Actors are at the heart of Swift's concurrency model. Introduced with Swift 5.5, they elegantly solve the data race problem by isolating mutable state. With Swift 6.2, their usage becomes even more intuitive thanks to MainActor by default. This guide covers everything you need to know to master them.

Before Actors, protecting shared state required locks, queues, or semaphores. It was verbose and error-prone:

This code works, but the compiler cannot verify that you haven't forgotten to use the queue somewhere. A single omission is enough to create a data race.

An Actor is a reference type that automatically isolates its state. The compiler guarantees that only one call can access the state at a time:

No more queues, no more locks. The compiler takes care of everything. Each Actor maintains an internal queue (executor) that serializes access.

From outside an Actor, every access to an isolated property or method requires await:

The await keyword indicates a potential suspension point. Your code waits its turn in the Actor's queue before accessing the state.

Inside the Actor, you access properties and methods directly without await:

Some properties or methods don't need isolation. Use nonisolated to exempt them:

Constants declared with let are automatically nonisolated because they are immutable and therefore thread-safe.

A common case: conforming an Actor to a synchronous protocol like CustomStringConvertible:

MainActor is a predefined global actor that represents the main thread. All UI code must run on it:

With @MainActor on the class, all properties and methods execute on the main thread. @Published properties can be modified safely.

If you only have a small portion of code to execute on MainActor:

When you know a callback will be called on the main thread but the compiler can't verify it:

Warning: assumeIsolated crashes if you're not actually on MainActor at runtime.

You can create your own global actors to isolate specific resources:

All accesses to FileManager are now serialized on DiskActor, avoiding file access conflicts.

When data crosses Actor boundaries, it must be Sendable. The Sendable protocol guarantees that a type can be shared between concurrent contexts without data races.

Some types are Sendable by default:

Classes require special attention:

For types with internal synchronization that the compiler can't verify:

Warning: @unchecked Sendable disables compiler checks. You are responsible for thread-safety. Prefer Mutex (iOS 18+) when possible:

Closures passed between concurrent contexts must be @Sendable:

Swift 6.2 introduces defaultIsolation which fundamentally changes the approach:

With this setting, all code without explicit annotation runs on MainActor:

If you want to explicitly leave MainActor:

Swift 6.2 allows restricting a protocol conformance to an actor:

Without @MainActor Equatable, the compiler could execute == on any thread, violating the class isolation.

A crucial point: Actors are reentrant. When you await inside an Actor, other calls can execute while waiting:

Capture necessary values before await:

Or use a transactional approach:

Each await is a point where state can change. Group operations together:

An Actor should have a single responsibility:

Switching between Actors has a cost:

Actors only have async methods from the outside. Watch out for designs that create circular dependencies:

Actors are the foundation of safe concurrency in Swift. Master them before moving on to advanced concepts: