agentleFS
AFK-surfAFK-surf/OpenBridge/.agents/skills/swift-concurrency/SKILL.md

swift-concurrency

Skill430 starsChanged 6 months agoMITView on GitHub

Expert guidance on Swift Concurrency best practices, patterns, and implementation. Use when developers mention: (1) Swift Concurrency, async/await, actors, or tasks, (2) "use Swift Concurrency" or "modern concurrency patterns", (3) migrating to Swift 6, (4) data races or thread safety issues, (5) refactoring closures to async/await, (6) @MainActor, Sendable, or actor isolation, (7) concurrent code architecture or performance optimization, (8) concurrency-related linter warnings (SwiftLint or similar; e.g. async_without_await, Sendable/actor isolation/MainActor lint).

25 other projects use a version of this, 13 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use swiftdata, swift-testing and 6 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Prisma-Labs-DevSkill

    swiftdata

    API reference: SwiftData. Query for @Model, ModelContext, @Query, schema migrations.

    Also in 3 projects that use this

  • pluginagentmarketplaceSkill

    swift-testing

    Test Swift applications - XCTest, Swift Testing, UI tests, mocking, TDD, CI/CD

    Also in 4 projects that use this

  • dadederkSkill

    ios-accessibility

    Expert guidance on iOS accessibility best practices, patterns, and implementation. Use when developers mention: (1) iOS accessibility, VoiceOver, Dynamic Type, or assistive technologies, (2) accessibility labels, traits, hints, or values, (3) automated accessibility testing, auditing, or manual testing, (4) Switch Control, Voice Control, or Full Keyboard Access, (5) inclusive design or accessibility culture, (6) making apps work for users with disabilities.

    Also in 3 projects that use this

  • twostrawsSkill

    swiftdata-pro

    Writes, reviews, and improves SwiftData code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use SwiftData.

    Also in 3 projects that use this

  • malpernSkill

    asc-localize-metadata

    Automatically translate and sync App Store metadata (description, keywords, what's new, subtitle) to multiple languages using LLM translation and asc CLI. Use when asked to localize an app's App Store listing, translate app descriptions, or add new languages to App Store Connect.

    Also in 3 projects that use this

  • malpernSkill

    asc-notarization

    Archive, export, and notarize macOS apps using xcodebuild and asc. Use when you need to prepare a macOS app for distribution outside the App Store with Developer ID signing and Apple notarization.

    Also in 3 projects that use this

  • +1 more from malpern

The file

Show its rules and text

We split this skill into the rules it gives an agent

31 rules. 0 are common, 9 are distinctive, and 22 are very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 22

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before proposing fixes, identify the isolation boundary: @MainActor, custom actor, actor instance isolation, or nonisolated.

    line 14
  2. Very specific:

    Do not recommend @MainActor as a blanket fix.

    line 15
  3. Very specific:

    Prefer structured concurrency (child tasks, task groups) over unstructured tasks.

    line 16
  4. Very specific:

    If recommending @preconcurrency, @unchecked Sendable, or nonisolated(unsafe), require:

    line 17
  5. Distinctive:

    When analyzing Swift projects for concurrency issues:

    line 25
  6. Very specific:

    Use Read on Package.swift for SwiftPM settings (tools version, strict concurrency flags, upcoming features)

    line 28
  7. Very specific:

    Use Grep for SWIFT_STRICT_CONCURRENCY or SWIFT_DEFAULT_ACTOR_ISOLATION in .pbxproj files

    line 29
  8. Very specific:

    Use Grep for SWIFT_UPCOMING_FEATURE_ to find enabled upcoming features

    line 30
  9. Very specific:

    Default actor isolation (is the module default @MainActor or nonisolated?)

    line 38
  10. Very specific:

    Check Package.swift for .defaultIsolation(MainActor.self).

    line 46
  11. Very specific:

    Check for strict concurrency flags: .enableExperimentalFeature("StrictConcurrency=targeted") (or similar).

    line 48
  12. Very specific:

    Check tools version at the top: // swift-tools-version: ...

    line 49
  13. Distinctive:

    If any of these are unknown, ask the developer to confirm them before giving migration-sensitive guidance.

    line 56
  14. Distinctive:

    When a developer needs concurrency guidance, follow this decision tree:

    line 60
  15. Very specific:

    Read references/async-await-basics.md for foundational patterns

    line 63
  16. Very specific:

    Read references/threading.md for thread/task relationship and isolation

    line 83
  17. Very specific:

    Read references/memory-management.md for retain cycle prevention

    line 86
  18. Very specific:

    Use references/linting.md for rule intent and preferred fixes.

    line 91
  19. Very specific:

    Remove async if not required.

    line 93
  20. Very specific:

    Use references/threading.md to avoid thread-centric debugging and rely on isolation + Instruments

    line 101
  21. Very specific:

    Use references/testing.md (await fulfillment(of:) and Swift Testing patterns)

    line 103
  22. Very specific:

    Use references/core-data.md (DAO/NSManagedObjectID, default isolation conflicts)

    line 105
  23. Distinctive:

    Prefer structured concurrency: - Use task groups over unstructured tasks when possible

    line 224
  24. Distinctive:

    Minimize suspension points: - Keep actor-isolated sections small to reduce context switches

    line 225
  25. Distinctive:

    Use @MainActor judiciously: - Only for truly UI-related code

    line 226
  26. Distinctive:

    Handle cancellation: - Check Task.isCancelled in long-running operations

    line 228
  27. Distinctive:

    Avoid blocking: - Never use semaphores or locks in async contexts

    line 229
  28. Distinctive:

    Test concurrent code: - Use proper async test methods and consider timing issues

    line 230
  29. Very specific:

    Run tests, especially concurrency-sensitive ones (see references/testing.md).

    line 236
  30. Very specific:

    If performance-related, verify with Instruments (see references/performance.md).

    line 237
  31. Very specific:

    If lifetime-related, verify deinit/cancellation behavior (see references/memory-management.md).

    line 238

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Swift Concurrency

Overview

This skill provides expert guidance on Swift Concurrency, covering modern async/await patterns, actors, tasks, Sendable conformance, and migration to Swift 6. Use this skill to help developers write safe, performant concurrent code and navigate the complexities of Swift's structured concurrency model.

Agent Behavior Contract (Follow These Rules)

  1. Analyze the project/package file to find out which Swift language mode (Swift 5.x vs Swift 6) and which Xcode/Swift toolchain is used when advice depends on it.
  2. Before proposing fixes, identify the isolation boundary: @MainActor, custom actor, actor instance isolation, or nonisolated.
  3. Do not recommend @MainActor as a blanket fix. Justify why main-actor isolation is correct for the code.
  4. Prefer structured concurrency (child tasks, task groups) over unstructured tasks. Use Task.detached only with a clear reason.
  5. If recommending @preconcurrency, @unchecked Sendable, or nonisolated(unsafe), require:
    • a documented safety invariant
    • a follow-up ticket to remove or migrate it
  6. For migration work, optimize for minimal blast radius (small, reviewable changes) and add verification steps.
  7. Course references are for deeper learning only. Use them sparingly and only when they clearly help answer the developer's question.

Recommended Tools for Analysis

When analyzing Swift projects for concurrency issues:

  1. Project Settings Discovery
    • Use Read on Package.swift for SwiftPM settings (tools version, strict concurrency flags, upcoming features)
    • Use Grep for SWIFT_STRICT_CONCURRENCY or SWIFT_DEFAULT_ACTOR_ISOLATION in .pbxproj files
    • Use Grep for SWIFT_UPCOMING_FEATURE_ to find enabled upcoming features

Project Settings Intake (Evaluate Before Advising)

Concurrency behavior depends on build settings. Always try to determine:

  • Default actor isolation (is the module default @MainActor or nonisolated?)
  • Strict concurrency checking level (minimal/targeted/complete)
  • Whether upcoming features are enabled (especially NonisolatedNonsendingByDefault)
  • Swift language mode (Swift 5.x vs Swift 6) and SwiftPM tools version

Manual checks (no scripts)

  • SwiftPM:
    • Check Package.swift for .defaultIsolation(MainActor.self).
    • Check Package.swift for .enableUpcomingFeature("NonisolatedNonsendingByDefault").
    • Check for strict concurrency flags: .enableExperimentalFeature("StrictConcurrency=targeted") (or similar).
    • Check tools version at the top: // swift-tools-version: ...
  • Xcode projects:
    • Search project.pbxproj for:
      • SWIFT_DEFAULT_ACTOR_ISOLATION
      • SWIFT_STRICT_CONCURRENCY
      • SWIFT_UPCOMING_FEATURE_ (and/or SWIFT_ENABLE_EXPERIMENTAL_FEATURES)

If any of these are unknown, ask the developer to confirm them before giving migration-sensitive guidance.

Quick Decision Tree

When a developer needs concurrency guidance, follow this decision tree:

  1. Starting fresh with async code?
    • Read references/async-await-basics.md for foundational patterns
    • For parallel operations → references/tasks.md (async let, task groups)
  2. Protecting shared mutable state?
    • Need to protect class-based state → references/actors.md (actors, @MainActor)
    • Need thread-safe value passing → references/sendable.md (Sendable conformance)
  3. Managing async operations?
    • Structured async work → references/tasks.md (Task, child tasks, cancellation)
    • Streaming data → references/async-sequences.md (AsyncSequence, AsyncStream)
  4. Working with legacy frameworks?
    • Core Data integration → references/core-data.md
    • General migration → references/migration.md
  5. Performance or debugging issues?
    • Slow async code → references/performance.md (profiling, suspension points)
    • Testing concerns → references/testing.md (XCTest, Swift Testing)
  6. Understanding threading behavior?
    • Read references/threading.md for thread/task relationship and isolation
  7. Memory issues with tasks?
    • Read references/memory-management.md for retain cycle prevention

Triage-First Playbook (Common Errors -> Next Best Move)

  • SwiftLint concurrency-related warnings
    • Use references/linting.md for rule intent and preferred fixes; avoid dummy awaits as “fixes”.
  • SwiftLint async_without_await warning
    • Remove async if not required; if required by protocol/override/@concurrent, prefer narrow suppression over adding fake awaits. See references/linting.md.
  • "Sending value of non-Sendable type ... risks causing data races"
    • First: identify where the value crosses an isolation boundary
    • Then: use references/sendable.md and references/threading.md (especially Swift 6.2 behavior changes)
  • "Main actor-isolated ... cannot be used from a nonisolated context"
    • First: decide if it truly belongs on @MainActor
    • Then: use references/actors.md (global actors, nonisolated, isolated parameters) and references/threading.md (default isolation)
  • "Class property 'current' is unavailable from asynchronous contexts" (Thread APIs)
    • Use references/threading.md to avoid thread-centric debugging and rely on isolation + Instruments
  • XCTest async errors like "wait(...) is unavailable from asynchronous contexts"
    • Use references/testing.md (await fulfillment(of:) and Swift Testing patterns)
  • Core Data concurrency warnings/errors
    • Use references/core-data.md (DAO/NSManagedObjectID, default isolation conflicts)

Core Patterns Reference

When to Use Each Concurrency Tool

async/await - Making existing synchronous code asynchronous

// Use for: Single asynchronous operations
func fetchUser() async throws -> User {
    try await networkClient.get("/user")
}

async let - Running multiple independent async operations in parallel

// Use for: Fixed number of parallel operations known at compile time
async let user = fetchUser()
async let posts = fetchPosts()
let profile = try await (user, posts)

Task - Starting unstructured asynchronous work

// Use for: Fire-and-forget operations, bridging sync to async contexts
Task {
    await updateUI()
}

Task Group - Dynamic parallel operations with structured concurrency

// Use for: Unknown number of parallel operations at compile time
await withTaskGroup(of: Result.self) { group in
    for item in items {
        group.addTask { await process(item) }
    }
}

Actor - Protecting mutable state from data races

// Use for: Shared mutable state accessed from multiple contexts
actor DataCache {
    private var cache: [String: Data] = [:]
    func get(_ key: String) -> Data? { cache[key] }
}

@MainActor - Ensuring UI updates on main thread

// Use for: View models, UI-related classes
@MainActor
class ViewModel: ObservableObject {
    @Published var data: String = ""
}

Common Scenarios

Scenario: Network request with UI update

Task { @concurrent in
    let data = try await fetchData() // Background
    await MainActor.run {
        self.updateUI(with: data) // Main thread
    }
}

Scenario: Multiple parallel network requests

async let users = fetchUsers()
async let posts = fetchPosts()
async let comments = fetchComments()
let (u, p, c) = try await (users, posts, comments)

Scenario: Processing array items in parallel

await withTaskGroup(of: ProcessedItem.self) { group in
    for item in items {
        group.addTask { await process(item) }
    }
    for await result in group {
        results.append(result)
    }
}

Swift 6 Migration Quick Guide

Key changes in Swift 6:

  • Strict concurrency checking enabled by default
  • Complete data-race safety at compile time
  • Sendable requirements enforced on boundaries
  • Isolation checking for all async boundaries

For detailed migration steps, see references/migration.md.

Reference Files

Load these files as needed for specific topics:

  • async-await-basics.md - async/await syntax, execution order, async let, URLSession patterns
  • tasks.md - Task lifecycle, cancellation, priorities, task groups, structured vs unstructured
  • threading.md - Thread/task relationship, suspension points, isolation domains, nonisolated
  • memory-management.md - Retain cycles in tasks, memory safety patterns
  • actors.md - Actor isolation, @MainActor, global actors, reentrancy, custom executors, Mutex
  • sendable.md - Sendable conformance, value/reference types, @unchecked, region isolation
  • linting.md - Concurrency-focused lint rules and SwiftLint async_without_await
  • async-sequences.md - AsyncSequence, AsyncStream, when to use vs regular async methods
  • core-data.md - NSManagedObject sendability, custom executors, isolation conflicts
  • performance.md - Profiling with Instruments, reducing suspension points, execution strategies
  • testing.md - XCTest async patterns, Swift Testing, concurrency testing utilities
  • migration.md - Swift 6 migration strategy, closure-to-async conversion, @preconcurrency, FRP migration

Best Practices Summary

  1. Prefer structured concurrency - Use task groups over unstructured tasks when possible
  2. Minimize suspension points - Keep actor-isolated sections small to reduce context switches
  3. Use @MainActor judiciously - Only for truly UI-related code
  4. Make types Sendable - Enable safe concurrent access by conforming to Sendable
  5. Handle cancellation - Check Task.isCancelled in long-running operations
  6. Avoid blocking - Never use semaphores or locks in async contexts
  7. Test concurrent code - Use proper async test methods and consider timing issues

Verification Checklist (When You Change Concurrency Code)

  • Confirm build settings (default isolation, strict concurrency, upcoming features) before interpreting diagnostics.
  • After refactors:
    • Run tests, especially concurrency-sensitive ones (see references/testing.md).
    • If performance-related, verify with Instruments (see references/performance.md).
    • If lifetime-related, verify deinit/cancellation behavior (see references/memory-management.md).

Glossary

See references/glossary.md for quick definitions of core concurrency terms used across this skill.


Note: This skill is based on the comprehensive Swift Concurrency Course by Antoine van der Lee.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.