write-swift

Work down a fixed list: first stop sharing the object by giving each concurrent job its own instance, then make it a Sendable value type, then isolate it to an actor, and only as a last resort use Mutex, Atomics, or @unchecked Sendable. Most real errors are fixed at step one.

Use @concurrent to move your own CPU-heavy work off the main thread after profiling shows a hang. Use an actor only when you need to move mutable state off the main actor because tasks are hopping back constantly. Start single-threaded and add concurrency only with a measured reason.

some P keeps one fixed underlying type per scope, preserving associated-type relationships and enabling compiler specialization. any P is a type-erased box for heterogeneous storage, but it erases associated types and blocks optimization. Default to some and switch to any only when you need heterogeneous collections.

No. Since Swift 6.2, an async function runs on the caller's actor by default. To guarantee background execution you must mark it @concurrent, and nonisolated makes it run wherever it is called from, which is the right default for library APIs.

Use Swift Testing for new tests: @Test functions, #expect expressions, parameterized arguments, and trait-based filtering. XCTest remains required only for UI automation with XCUIApplication, performance metrics with XCTMetric, and Objective-C exception testing.

Actors guarantee mutual exclusion, not transactions, and they are not FIFO. A common bug is checking state, awaiting, then writing, which lets two tasks interleave. Mutate actor state in synchronous methods and re-check assumptions after every await.