swift

Swift

Purpose

Write Swift that leans on value semantics and the concurrency model rather than fighting them: structs by default, actors for shared mutable state, and no force-unwrapping.

When to Use

• Writing Swift for Apple platforms or server-side Swift.
• Migrating callback or Combine code to async/await.
• Resolving data-race warnings under strict concurrency checking.
• Designing SwiftUI state and view models.
• Diagnosing retain cycles and memory growth.

Capabilities

• Value vs reference semantics and copy-on-write.
• Optional handling: guard let, optional chaining, Result types.
• Protocol-oriented design with associated types and generics.
• Structured concurrency: async let, task groups, actors, Sendable.
• SwiftUI: @State, @Observable, and unidirectional data flow.

Inputs

• Source target, Swift version, minimum deployment target.
• Concurrency checking level (minimal, targeted, complete).

Outputs

• Code free of force-unwraps and implicit unwrapped optionals.
• Concurrency that compiles cleanly under strict checking.
• View models with a single source of truth.

Workflow

1. Prefer structs — Reach for a class only when identity or shared mutation is required.
2. Eliminate optionals early — Unwrap once at the boundary with guard; the rest of the function works with non-optionals.
3. Isolate mutable state — Any shared mutable state becomes an actor or is confined to the main actor.
4. Model async explicitly — Replace completion handlers with async functions; use task groups for concurrency.
5. Gate — Build with strict concurrency checking and treat warnings as errors.

Best Practices

• ! is a crash waiting for a user to find it. The only acceptable uses are IBOutlets and genuinely proven invariants with a comment.
• Capture lists ([weak self]) on every escaping closure that captures self in a class.
• Mark types Sendable deliberately; suppressing the warning with @unchecked Sendable requires a documented reason.
• SwiftUI views are cheap and disposable — put logic in the model, not the view body.
• Prefer async let for a fixed set of concurrent calls; use TaskGroup when the count is dynamic.
• Long-running work never runs on the main actor.