$npx -y skills add Livsy90/iOS-Performance-Agent-Skills --skill swift-runtime-performanceUse this skill when reviewing Swift code for runtime-level performance costs, including heap allocation, ARC traffic, stack vs heap storage, closure capture contexts, method dispatch, protocol witness dispatch, existentials vs generics, opaque types, copy-on-write, SIL optimizer
| 1 | # Swift Runtime Performance |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Use this skill to review Swift code for runtime-level performance costs without turning every abstraction into a problem. Focus on concrete costs such as allocation, ARC traffic, dispatch, specialization, copying, optimizer visibility, and unsafe memory boundaries. |
| 6 | |
| 7 | This skill should help the agent distinguish real hot-path runtime costs from theoretical micro-optimizations. |
| 8 | |
| 9 | ## When to use this skill |
| 10 | |
| 11 | Use this skill when the task involves Swift runtime behavior such as: |
| 12 | |
| 13 | - heap allocation, stack vs heap storage, object layout, boxed values, or closure contexts; |
| 14 | - ARC retain/release traffic, ownership, lifetime, weak/unowned references, or closure captures; |
| 15 | - direct dispatch, class dispatch, Objective-C dispatch, witness dispatch, or dynamic dispatch in hot paths; |
| 16 | - `any Protocol`, `some Protocol`, generics, type erasure, specialization, or unspecialized hot code; |
| 17 | - copy-on-write collections, large values, custom COW storage, or repeated copies; |
| 18 | - optimized SIL inspection, compiler optimization, inlining, devirtualization, or specialization evidence; |
| 19 | - unsafe Swift, pointer lifetime, memory binding, aliasing, buffer mutation, or safe wrappers around unsafe regions; |
| 20 | - module boundaries that affect optimizer visibility, `@inlinable`, `@usableFromInline`, `@frozen`, or public API resilience trade-offs. |
| 21 | |
| 22 | ## When not to use this skill |
| 23 | |
| 24 | Do not use this skill for: |
| 25 | |
| 26 | - general Swift syntax or API usage questions with no runtime performance concern; |
| 27 | - app launch investigations where the main issue is pre-main, dyld, static initializers, SDK startup, first frame, or first interaction; |
| 28 | - SwiftUI performance issues where the main issue is identity, invalidation, state scope, layout, drawing, animation, or scrolling; |
| 29 | - Swift Concurrency issues where the main issue is task lifetime, actor isolation, MainActor responsiveness, cancellation, AsyncSequence cleanup, reentrancy, or executor behavior; |
| 30 | - profiling workflow questions where the main task is choosing tools, interpreting traces, designing signposts, XCTest metrics, MetricKit, or production signals; |
| 31 | - broad architecture questions unless there is a specific runtime cost in a hot path. |
| 32 | |
| 33 | If another skill is more specific, route there first and use this skill only for the runtime subproblem. |
| 34 | |
| 35 | ## Neighbor skill boundaries |
| 36 | |
| 37 | Use these boundaries before applying runtime advice: |
| 38 | |
| 39 | - Use `swift-concurrency-performance` when the task centers on actors, tasks, MainActor, cancellation, AsyncSequence, continuations, task groups, executor behavior, or responsiveness under async work. |
| 40 | - Use `ios-launch-performance` when the task centers on cold launch, warm launch, pre-main, dyld, framework loading, static initializers, AppDelegate, SwiftUI `App`, first frame, first interaction, or launch metrics. |
| 41 | - Use `swiftui-performance` when the task centers on SwiftUI body evaluation, invalidation, identity, state ownership, dependency scope, `List`, `LazyVStack`, layout, drawing, animation, or lifecycle work in views. |
| 42 | - Use `ios-performance-profiling` when the task centers on choosing Instruments templates, interpreting traces, XCTest metrics, MetricKit, signposts, memory graphs, hangs, hitches, CPU, allocations, disk I/O, networking, or production telemetry. |
| 43 | - Use this skill when a neighboring task reveals a Swift runtime-level cost such as allocation churn, ARC traffic, existential boxing, witness dispatch, unspecialized generics, repeated COW copies, or unsafe memory boundaries. |
| 44 | |
| 45 | ## Core principle |
| 46 | |
| 47 | Do not optimize based only on how the source code looks. |
| 48 | |
| 49 | First identify: |
| 50 | |
| 51 | 1. whether the code is on a hot path; |
| 52 | 2. what runtime cost is suspected; |
| 53 | 3. whether the cost is visible in measurement, compiler output, or a small benchmark; |
| 54 | 4. whether the proposed change preserves semantics and improves the measured path; |
| 55 | 5. what trade-off the change introduces. |
| 56 | |
| 57 | A runtime optimization is useful only when it reduces cost in a path that matters. |
| 58 | |
| 59 | ## Runtime cost taxonomy |
| 60 | |
| 61 | Classify the suspected issue before recommending a change. |
| 62 | |
| 63 | Use these categories: |
| 64 | |
| 65 | - **Allocation** — heap objects, boxes, closure contexts, existential containers, temporary objects, intermediate collections. |
| 66 | - **ARC** — retain/release traffic, closure captures, weak/unowned access, bridged object lifetime, reference-backed value storage. |
| 67 | - **Dispatch** — dynamic dispatch, witness dispatch, Objective-C dispatch, closure calls, missed |