Swift

Swift Skill

Swift concurrency and testing: async/await, Actors, TaskGroups, Sendable, structured concurrency, XCTest, Swift Testing framework, and async test patterns.

Reference Loading Table

| Signal | Reference | Size |

|--------|-----------|------|

| async/await, Task, Sendable | references/fundamentals.md | ~20 lines |

| Actor, @MainActor, nonisolated | references/actor-isolation.md | ~20 lines |

| TaskGroup, AsyncSequence, AsyncStream, cancellation | references/task-patterns.md | ~20 lines |

| Failure modes, common mistakes | references/preferred-patterns.md | ~20 lines |

| concurrency overview, structured concurrency patterns | references/swift-concurrency.md | ~30 lines |

| XCTest, Swift Testing, test doubles, async tests, UI tests | references/swift-testing.md | ~250 lines |

Loading rule. Read the references whose signals match the task before responding.

Core Rules (Always Apply)

Concurrency

• Prefer structured concurrency -- use TaskGroup over loose Task { } whenever possible; structured tasks propagate cancellation and errors automatically.
• Mark types Sendable -- enable strict concurrency checking (-strict-concurrency=complete) and resolve all warnings before they become errors in Swift 6.
• Use actors for shared mutable state -- avoid manual locks; actors provide compiler-verified safety.
• Cancel what you create -- every Task stored in a property should have a corresponding cancellation path.
• Minimize @MainActor surface -- isolate only the UI layer; keep business logic and networking off the main actor.

Testing

• One assertion per concept -- a single test can have multiple assertions if they verify the same logical behavior, but avoid testing unrelated things together.
• Arrange-Act-Assert -- structure every test into setup, execution, and verification phases.
• Name tests descriptively -- testFetchUser_withExpiredToken_throwsAuthError is better than testFetch2.
• Prefer Swift Testing for new code -- use @Test and #expect when targeting Swift 5.9+; fall back to XCTest for older targets or UI tests.
• Ensure test independence -- each test must be runnable in isolation; always produce self-contained test state.

Phase 1: ASSESS

Determine what kind of Swift work is needed:

| Request type | Load references | Action |

|-------------|----------------|--------|

| Concurrency patterns | fundamentals, actor-isolation, task-patterns | Pattern guidance |

| Concurrency mistakes | preferred-patterns | Failure mode detection |

| Write tests | swift-testing | Test authoring |

| Async test patterns | swift-testing + fundamentals | Async test guidance |

| Full concurrency review | swift-concurrency + all concurrency refs | Full review pass |

Gate: Request classified and relevant references loaded.

Phase 2: EXECUTE

Apply loaded reference knowledge to the user's code or question.

For concurrency work:

• Verify structured concurrency used where possible
• Check Sendable conformance
• Validate actor isolation boundaries
• Confirm cancellation paths exist

For testing work:

• Use Swift Testing (@Test, #expect) for new code on Swift 5.9+
• Use @dataProvider-style parameterized tests with arguments:
• Use protocol-based mock injection
• Use XCTest for UI tests and older targets

Gate: Specific, reference-backed feedback or code provided.

Phase 3: VERIFY

Run the test suite and confirm:

swift test --enable-code-coverage
swift build

Gate: All tests pass. Build succeeds with strict concurrency checking.