@MainActor

@MainActor and main-thread isolation

@MainActor is a concurrency boundary, not just a naming convenience. It tells Swift that the annotated code must be executed on the main actor, which is the right fit for UI state, view models, and other APIs that are tied to a single, user-facing execution context.

That isolation matters because it gives the compiler a way to prevent accidental cross-thread access to state that is not safe to mutate concurrently. The practical effect is fewer race conditions, fewer reentrancy surprises, and clearer ownership of UI-bound work.

How main actor isolation shapes code flow

When a function, property, or type is isolated to the main actor, callers outside that context must hop to it explicitly or await the transition. That changes the shape of the code: synchronous access patterns become constrained, and asynchronous boundaries become part of the design rather than an implementation detail.

This is especially important when code reads from shared state and then updates the interface, because the compiler can enforce the same execution context at both points. In practice, @MainActor helps developers express, “this state belongs to the UI thread,” in a way the type system can check.

For teams that want a broader concurrency model, main actor isolation is one piece of a larger safety story. Apple’s concurrency guidance and the Swift language rules are the primary references for when to isolate code, when to hop actors, and how to avoid accidental thread hops in UI paths.

Where @MainActor is typically applied

The attribute is commonly used on view models, controllers, delegate callbacks, and any API that directly drives screen updates or user interaction. It can also be applied to an entire type when most of its state is UI-facing, which reduces repetitive annotations and makes the threading contract easier to see.

Used well, it becomes a design signal: code that is not related to presentation can remain outside the main actor, while UI state stays protected by a single isolation domain. That separation helps keep responsiveness high because work that does not need the main thread can be moved elsewhere.

Compiler enforcement and runtime consequences

Swift’s compiler is the key value here. It can flag illegal access to main-actor-isolated members from the wrong context, which turns many thread-safety mistakes into build-time errors instead of flaky runtime bugs.

That enforcement does not remove the need for good concurrency design, because blocking work on the main actor can still freeze the UI. The attribute protects access, but it does not make expensive computation safe to run there.

When code uses @MainActor correctly, the result is a clearer contract between asynchronous work and user-facing state, which is one of the most useful patterns in modern Swift application development.