Swift language mode, SDK availability and actor isolation answer different questions. Enabling checks reveals mismatches; it does not repair ownership or make CPU work safe on the main actor.
- 1Inspect build settings
- 2Locate isolation boundary
- 3Apply minimal correction
- 4Compile and exercise
Work through the example
Review a model's state mutations before adding MainActor. A detached task and an async function are not interchangeable escape hatches.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
@Observable grants no isolation
@Observable is a macro that generates observation plumbing. It says nothing
about which actor owns the state. An unannotated @Observable class is
nonisolated, so any task may mutate it while SwiftUI reads it.
@Observable final class Model { var items: [Item] = [] } // nonisolated — racy
@MainActor @Observable final class Model { … } // correct
Under Swift 6 language mode the first form produces isolation errors as soon as
you touch it from an async context. Under Swift 5 mode with strict concurrency
checking set to minimal, it compiles silently and races at runtime.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Inspect build settings | Confirm the input and environment | Preserve the failure and return to this step |
| Locate isolation boundary | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Apply minimal correction | Run the focused check | Preserve the failure and return to this step |
| Compile and exercise | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
The local concurrency fixture has recorded static before/after findings; it is not proof that one setting fixes every migration.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- How can I catch Swift concurrency review findings before accepting an agent’s changes?
A real before-and-after MCP review with file and line evidence, plus the limits of text-based concurrency checks.
What to do next
Next: Getting an agent to run checks: hooks, Stop conditions and verification limits