swiftui-dev

SwiftUI Dev

Use this skill for SwiftUI development, architecture, structure, performance, and Apple native app profiling. It combines:

• SwiftUI view refactor and Observation/MV guidance.
• SwiftUI code-first performance audit.
• Native macOS/iOS Time Profiler CLI workflow with xctrace, atos, and included scripts.

Do not use this skill for web performance, server profiling, generic PR review, product planning, or non-Apple UI frameworks. For ordinary implementation work without SwiftUI architecture/performance/native profiling concerns, use the development skill.

Route The Work

User intent	Read
Refactor SwiftUI View structure, split large body, review Observation boundaries	SwiftUI refactor
Decide whether MV, framework-native state, or a ViewModel is justified	MV patterns
SwiftUI page is slow, scrolling janks, or body updates too often	SwiftUI performance
Build a dependency/update mental model before deeper profiling	WWDC23 performance model
Inspect current SwiftUI Instrument lanes or Cause & Effect evidence	SwiftUI Instruments workflow and SwiftUI timeline guide
Diagnose a main-thread hang or run-loop stall	App hangs guide
Record/analyze macOS or iOS native Time Profiler traces from CLI, symbolicate and rank hotspots through the standard Orkas Skill Runner	Native trace workflow

If the user provides only symptoms, start with code-first SwiftUI review. Ask for trace/screenshots only when code review is inconclusive or the user explicitly wants trace analysis.

Required Inputs

For SwiftUI code review:

• Target view or feature code.
• Data flow: @State, @Binding, @Environment, @Observable, @Query, services, models.
• Symptoms and reproduction steps.
• Device/OS/build configuration when performance is involved.

For native profiling:

• App name and binary path, or existing .trace bundle.
• Attach PID or launch binary path.
• Slow interaction to exercise during capture.
• Capture duration, defaulting to 90 seconds.
• Matching symbols / binary and permission to launch or attach.

Proceed with explicit assumptions for code-only reviews. Stop before profiling if required tools or permissions are missing.

Core Workflow

1. Classify the task: SwiftUI structure/refactor, SwiftUI performance, or native trace profiling.
2. Start code-first for SwiftUI: inspect structure, data flow, Observation ownership, identity, layout, and body work before requesting heavier tooling.
3. Use Instruments evidence when available: treat traces/screenshots/CSV as evidence, not as the whole answer.
4. Make targeted recommendations: order issues by likely impact and confidence.
5. Verify with the same scenario: compare before/after CPU, frame drops, memory peak, sample counts, or the specific user-visible symptom when data exists.

Boundaries

• Do not invent metrics, trace findings, sample counts, call stacks, device settings, or benchmark results.
• Do not run xctrace unless the user has provided a local target, trace, or explicit permission and the environment is macOS with Xcode tools.
• Do not interpret stale symbols as real hotspots. Binary, trace, and load address must match.
• Do not introduce ViewModels by default. Prefer SwiftUI-native state/data flow unless existing code or user requirements justify a view model.
• Do not change business logic during refactor unless the user explicitly asks.
• If source files must be edited, follow the existing project style and verify with relevant build/tests/profiling.

Output Format

Use this concise structure unless a reference template is more specific:

# SwiftUI Dev Review: [Target]

## Inputs And Assumptions

## Findings
| Priority | Finding | Evidence | Recommendation | Confidence |
|---|---|---|---|---|

## Suggested Changes

## Verification Plan

## Risks / Limits

## Handoff To Next Stage

For native trace analysis, use the report structure in the native trace workflow.

Quality Checklist

Before finalizing, verify:

• The task is Apple-native or SwiftUI-specific.
• SwiftUI structure recommendations preserve clear data ownership and framework-native state flow.
• Findings cite code, trace evidence, screenshots, or clearly labeled assumptions.
• Recommendations are targeted, not generic "optimize everything" advice.
• Refactors preserve behavior unless requested otherwise.
• Profiling commands, trace path, binary path, load address, and confidence are reported when CLI profiling is used.
• The user gets a concrete verification plan.