Swift Concurrency Performance

Swift Concurrency Performance

Purpose

Use this skill to review, diagnose, and improve Swift Concurrency code when async work affects UI responsiveness, throughput, memory, cancellation, task lifetime, actor contention, or correctness under load.

This skill is not a general Swift Concurrency tutorial. It is a performance and responsiveness review workflow.

When to use this skill

Use this skill when the task involves:

• UI stalls, slow interactions, hangs, or frame drops related to async work;
• excessive Task creation, task groups, detached tasks, or unstructured concurrency;
• MainActor bottlenecks, actor hopping, actor queue buildup, or actor contention;
• cancellation that does not stop work, navigation leaks, or tasks outliving their owner;
• AsyncSequence, AsyncStream, long-running streams, buffering, or producer cleanup;
• continuation bridges, delegate/callback wrappers, or async wrappers around legacy APIs;
• blocking calls inside async contexts, semaphores, synchronous I/O, locks, or cooperative pool starvation;
• actor reentrancy, duplicate in-flight work, cache stampedes, or inconsistent actor state after await;
• Swift 6 isolation behavior, explicit isolation, @concurrent, nonisolated, or Sendable boundaries;
• Instruments traces, logs, or production signals that point to concurrency-related latency, memory growth, or throughput loss.

When not to use this skill

Do not use this skill for:

• basic async/await syntax questions with no performance, lifetime, or responsiveness concern;
• general architecture discussions where concurrency is not part of the critical path;
• purely SwiftUI rendering issues unless async lifecycle work contributes to the symptom;
• launch performance unless async startup work, task lifetime, or actor isolation is part of the launch path;
• runtime-level allocation, ARC, generics, or existential costs unless they interact with concurrency behavior;
• server-side concurrency questions unless the task is specifically about Swift Concurrency performance patterns.

Prefer another skill when a more specific domain dominates the task:

• use ios-launch-performance for app startup, first frame, first interaction, pre-main, dyld, or SDK launch work;
• use swiftui-performance for SwiftUI invalidation, identity, layout, scrolling, or body cost;
• use ios-performance-profiling when the main task is choosing or interpreting profiling tools;
• use swift-runtime-performance for allocations, ARC traffic, dispatch, existentials, generics, or copy-on-write costs.

Core workflow

1. Identify the user-visible symptom: UI stall, slow interaction, low throughput, memory growth, duplicate work, leaked task, missed cancellation, actor contention, or blocked cooperative threads.
2. Locate the async boundary: Task, task group, actor method, MainActor, continuation, stream, lifecycle callback, delegate bridge, or legacy blocking API.
3. Determine the lifetime owner: view, view model, service, actor, request, app session, stream consumer, or detached background process.
4. Separate required work from optional or deferrable work.
5. Check whether concurrency is being used to express structure, isolation, and cancellation rather than as a vague performance fix.
6. Look for blocking work inside async contexts.
7. Check whether work that affects UI state is isolated narrowly and whether CPU-heavy work is kept off the main actor.
8. Check cancellation propagation, especially across task groups, streams, continuations, loops, and navigation lifetimes.
9. Check for actor reentrancy after every await inside actor-isolated methods.
10. Propose the smallest safe change that improves lifetime, cancellation, isolation, or throughput.
11. Include a validation path before calling the change a performance improvement.

Decision rules

• Treat async as suspension, not as automatic background execution.
• Do not assume concurrency improves performance. More tasks can increase scheduling overhead, memory pressure, actor contention, and cancellation complexity.
• Prefer structured concurrency when the parent owns the lifetime of the work.
• Use unstructured tasks only when the lifetime is deliberately independent and cancellation ownership is explicit.
• Use Task.detached only as an explicit escape hatch from inherited context, priority, task-local values, and actor isolation.
• Bound parallel work when the input size can grow.
• Keep MainActor work short and focused on UI state, presentation coordination, and main-thread-only APIs.
• Move CPU-heavy work outside main-actor isolation, but do not cross isolation boundaries casually.
• Batch actor calls on hot paths when repeated hops dominate latency.
• After an await inside an actor, assume actor state may have changed.
• Use checked continuations by default and verify every path resumes exactly once.
• Treat stream termination and producer cleanup as part of the API contract.
• Prefer cancellation-aware loops and pipelines for long-running or high-volume work.
• Connect every performance claim to evidence or a validation plan.

Gotchas

• Do not recommend adding async or Task simply because code is slow.
• Do not move work off the MainActor if the API or UI state must remain main-actor isolated.
• Do not leave CPU-heavy computation in a @MainActor type just because the type also owns UI state.
• Do not use Task.detached to silence isolation errors without explaining the lifetime, cancellation, priority, and data-safety consequences.
• Do not create one child task per item for large or unbounded collections without limiting concurrency.
• Do not swallow cancellation with broad catch blocks.
• Do not assume cancelling a parent automatically stops legacy callbacks, streams, delegates, or manually retained producers.
• Do not wrap a blocking API in async if the underlying work still blocks a cooperative executor thread.
• Do not treat actor isolation as a duplicate-work prevention mechanism when the actor method suspends during a cache miss.
• Do not use unsafe continuations unless profiling shows checked continuation overhead matters and the resume contract is proven.
• Do not call an optimization successful without before/after validation.