Tuist Swift Review

This skill is intentionally narrow. Generic Swift style, formatting, naming, and lint hygiene are already covered by SwiftFormat and SwiftLint in continuous integration. Do not flag those. Focus on the rules below.

For each finding, cite path:line and quote the relevant snippet.

---

1. Prefer structs over classes

Default to struct for new types. Reach for class only when reference semantics, identity, inheritance, or deinit are actually required.

Flag

• A new class declaration that has no stored mutable identity, no inheritance, no deinit, and is not bridged to an Objective-C / Cocoa API. Recommend converting it to a struct. Severity: medium.

Do not flag

• Existing classes left unchanged by the diff.
• Classes that subclass a framework type (NSObject, XCTestCase, Operation, etc.) or conform to a protocol that requires reference semantics.
• Types that genuinely need reference identity (caches, long-lived coordinators, actors-with-state-shared-by-reference).
• final class declarations whose Sendable conformance is backed by a stored Synchronization.Mutex<State> (or another ~Copyable synchronization primitive). Mutex cannot be a stored property of a Copyable struct, the compiler emits stored property '...' of 'Copyable'-conforming struct '...' has non-Copyable type 'Mutex<...>', and a ~Copyable struct cannot be captured by a @Sendable closure. A final class with the Mutex and Sendable conformance is the correct expression of this pattern.

2. Avoid @unchecked Sendable

@unchecked Sendable opts out of the compiler's concurrency safety checks and shifts the burden of correctness onto every reader. Prefer proper synchronization primitives that the compiler can verify.

Flag