swift-concurrency-performance

Name: swift-concurrency-performance
Author: Livsy90

88stars5forks

How to install swift-concurrency-performance?

livsy90/ios-performance-agent-skills/swift-concurrency-performance

$npx -y skills add Livsy90/iOS-Performance-Agent-Skills --skill swift-concurrency-performance

Installs into the current project.

Summary

Use this skill when reviewing Swift Concurrency performance and responsiveness, including task explosions, actor hopping, MainActor bottlenecks, cancellation, AsyncSequence cleanup, continuations, reentrancy, executor behavior, blocking async work, or async work that affects UI l

Files · 1

View on GitHub

SKILL.md

1	# Swift Concurrency Performance
2
3	## Purpose
4
5	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.
6
7	This skill is not a general Swift Concurrency tutorial. It is a performance and responsiveness review workflow.
8
9	## When to use this skill
10
11	Use this skill when the task involves:
12
13	* UI stalls, slow interactions, hangs, or frame drops related to async work;
14	* excessive `Task` creation, task groups, detached tasks, or unstructured concurrency;
15	* `MainActor` bottlenecks, actor hopping, actor queue buildup, or actor contention;
16	* cancellation that does not stop work, navigation leaks, or tasks outliving their owner;
17	* `AsyncSequence`, `AsyncStream`, long-running streams, buffering, or producer cleanup;
18	* continuation bridges, delegate/callback wrappers, or async wrappers around legacy APIs;
19	* blocking calls inside async contexts, semaphores, synchronous I/O, locks, or cooperative pool starvation;
20	* actor reentrancy, duplicate in-flight work, cache stampedes, or inconsistent actor state after `await`;
21	* Swift 6 isolation behavior, explicit isolation, `@concurrent`, `nonisolated`, or Sendable boundaries;
22	* Instruments traces, logs, or production signals that point to concurrency-related latency, memory growth, or throughput loss.
23
24	## When not to use this skill
25
26	Do not use this skill for:
27
28	* basic `async`/`await` syntax questions with no performance, lifetime, or responsiveness concern;
29	* general architecture discussions where concurrency is not part of the critical path;
30	* purely SwiftUI rendering issues unless async lifecycle work contributes to the symptom;
31	* launch performance unless async startup work, task lifetime, or actor isolation is part of the launch path;
32	* runtime-level allocation, ARC, generics, or existential costs unless they interact with concurrency behavior;
33	* server-side concurrency questions unless the task is specifically about Swift Concurrency performance patterns.
34
35	Prefer another skill when a more specific domain dominates the task:
36
37	* use `ios-launch-performance` for app startup, first frame, first interaction, pre-main, dyld, or SDK launch work;
38	* use `swiftui-performance` for SwiftUI invalidation, identity, layout, scrolling, or body cost;
39	* use `ios-performance-profiling` when the main task is choosing or interpreting profiling tools;
40	* use `swift-runtime-performance` for allocations, ARC traffic, dispatch, existentials, generics, or copy-on-write costs.
41
42	## Core workflow
43
44	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.
45	2. Locate the async boundary: `Task`, task group, actor method, `MainActor`, continuation, stream, lifecycle callback, delegate bridge, or legacy blocking API.
46	3. Determine the lifetime owner: view, view model, service, actor, request, app session, stream consumer, or detached background process.
47	4. Separate required work from optional or deferrable work.
48	5. Check whether concurrency is being used to express structure, isolation, and cancellation rather than as a vague performance fix.
49	6. Look for blocking work inside async contexts.
50	7. Check whether work that affects UI state is isolated narrowly and whether CPU-heavy work is kept off the main actor.
51	8. Check cancellation propagation, especially across task groups, streams, continuations, loops, and navigation lifetimes.
52	9. Check for actor reentrancy after every `await` inside actor-isolated methods.
53	10. Propose the smallest safe change that improves lifetime, cancellation, isolation, or throughput.
54	11. Include a validation path before calling the change a performance improvement.
55
56	## Decision rules
57
58	* Treat `async` as suspension, not as automatic background execution.
59	* Do not assume concurrency improves performance. More tasks can increase scheduling overhead, memory pressure, actor contention, and cancellation complexity.
60	* Prefer structured concurrency when the parent owns the lifetime of the work.
61	* Use unstructured tasks only when the lifetime is deliberately independent and cancellation ownership is explicit.
62	* Use `Task.detached` only as an explicit escape hatch from inherited context, priority, task-local values, and actor isolation.
63	* Bound parallel work when the input size can grow.
64	* Keep `MainActor` work short and focused on UI state,

People who liked this also viewed

6 picks

Type

swift-concurrency-performance

88stars5forks

View on GitHub

How to install swift-concurrency-performance?

livsy90/ios-performance-agent-skills/swift-concurrency-performance

$npx -y skills add Livsy90/iOS-Performance-Agent-Skills --skill swift-concurrency-performance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Swift Concurrency Performance
2
3	## Purpose
4
5	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.
6
7	This skill is not a general Swift Concurrency tutorial. It is a performance and responsiveness review workflow.
8
9	## When to use this skill
10
11	Use this skill when the task involves:
12
13	* UI stalls, slow interactions, hangs, or frame drops related to async work;
14	* excessive `Task` creation, task groups, detached tasks, or unstructured concurrency;
15	* `MainActor` bottlenecks, actor hopping, actor queue buildup, or actor contention;
16	* cancellation that does not stop work, navigation leaks, or tasks outliving their owner;
17	* `AsyncSequence`, `AsyncStream`, long-running streams, buffering, or producer cleanup;
18	* continuation bridges, delegate/callback wrappers, or async wrappers around legacy APIs;
19	* blocking calls inside async contexts, semaphores, synchronous I/O, locks, or cooperative pool starvation;
20	* actor reentrancy, duplicate in-flight work, cache stampedes, or inconsistent actor state after `await`;
21	* Swift 6 isolation behavior, explicit isolation, `@concurrent`, `nonisolated`, or Sendable boundaries;
22	* Instruments traces, logs, or production signals that point to concurrency-related latency, memory growth, or throughput loss.
23
24	## When not to use this skill
25
26	Do not use this skill for:
27
28	* basic `async`/`await` syntax questions with no performance, lifetime, or responsiveness concern;
29	* general architecture discussions where concurrency is not part of the critical path;
30	* purely SwiftUI rendering issues unless async lifecycle work contributes to the symptom;
31	* launch performance unless async startup work, task lifetime, or actor isolation is part of the launch path;
32	* runtime-level allocation, ARC, generics, or existential costs unless they interact with concurrency behavior;
33	* server-side concurrency questions unless the task is specifically about Swift Concurrency performance patterns.
34
35	Prefer another skill when a more specific domain dominates the task:
36
37	* use `ios-launch-performance` for app startup, first frame, first interaction, pre-main, dyld, or SDK launch work;
38	* use `swiftui-performance` for SwiftUI invalidation, identity, layout, scrolling, or body cost;
39	* use `ios-performance-profiling` when the main task is choosing or interpreting profiling tools;
40	* use `swift-runtime-performance` for allocations, ARC traffic, dispatch, existentials, generics, or copy-on-write costs.
41
42	## Core workflow
43
44	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.
45	2. Locate the async boundary: `Task`, task group, actor method, `MainActor`, continuation, stream, lifecycle callback, delegate bridge, or legacy blocking API.
46	3. Determine the lifetime owner: view, view model, service, actor, request, app session, stream consumer, or detached background process.
47	4. Separate required work from optional or deferrable work.
48	5. Check whether concurrency is being used to express structure, isolation, and cancellation rather than as a vague performance fix.
49	6. Look for blocking work inside async contexts.
50	7. Check whether work that affects UI state is isolated narrowly and whether CPU-heavy work is kept off the main actor.
51	8. Check cancellation propagation, especially across task groups, streams, continuations, loops, and navigation lifetimes.
52	9. Check for actor reentrancy after every `await` inside actor-isolated methods.
53	10. Propose the smallest safe change that improves lifetime, cancellation, isolation, or throughput.
54	11. Include a validation path before calling the change a performance improvement.
55
56	## Decision rules
57
58	* Treat `async` as suspension, not as automatic background execution.
59	* Do not assume concurrency improves performance. More tasks can increase scheduling overhead, memory pressure, actor contention, and cancellation complexity.
60	* Prefer structured concurrency when the parent owns the lifetime of the work.
61	* Use unstructured tasks only when the lifetime is deliberately independent and cancellation ownership is explicit.
62	* Use `Task.detached` only as an explicit escape hatch from inherited context, priority, task-local values, and actor isolation.
63	* Bound parallel work when the input size can grow.
64	* Keep `MainActor` work short and focused on UI state,

People who liked this also viewed

6 picks

Type