swiftui-dev
Use for SwiftUI development work, including SwiftUI architecture/refactor, Observation and MV patterns, SwiftUI performance audit, Instruments evidence, and xctrace/Time Profiler hotspot analysis.
What this skill does
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 / MV / ViewModel boundaries | references/swiftui-refactor.md | | SwiftUI page is slow, scrolling janks, body updates too often, Instruments trace needs interpretation | references/swiftui-performance.md | | Record/analyze macOS or iOS native Time Profiler traces from CLI, symbolicate and rank hotspots | references/native-trace.md | | Need deeper Apple/WWDC context for SwiftUI update causes, hangs, Instruments lanes | Read the specific Apple summary files listed in the relevant reference |
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
.tracebundle. - 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
- Classify the task: SwiftUI structure/refactor, SwiftUI performance, or native trace profiling.
- Start code-first for SwiftUI: inspect structure, data flow, Observation ownership, identity, layout, and body work before requesting heavier tooling.
- Use Instruments evidence when available: treat traces/screenshots/CSV as evidence, not as the whole answer.
- Make targeted recommendations: order issues by likely impact and confidence.
- 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
xctraceunless 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 StageFor native trace analysis, use the report structure in references/native-trace.md.
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.
Files in this skill
- _meta.json
- references/demystify-swiftui-performance-wwdc23.md
- references/mv-patterns.md
- references/native-trace.md
- references/optimizing-swiftui-performance-instruments.md
- references/swiftui-performance.md
- references/swiftui-refactor.md
- references/understanding-hangs-in-your-app.md
- references/understanding-improving-swiftui-performance.md
- scripts/extract_time_samples.py
- scripts/record_time_profiler.py
- scripts/top_hotspots.py
- SKILL.md
How to use in Orkas
Open the Orkas desktop app, go to the marketplace, and install this item with one click. Don't have Orkas yet? Download Orkas.
用于 SwiftUI 开发专项:审查和重构 SwiftUI View 结构、Observation、MV 模式、依赖边界和 ViewModel 选择;审计 SwiftUI 渲染、状态更新、滚动、布局和 Instruments 证据;或用 xctrace / Time Profiler CLI 脚本采样、导出、符号化并排序 macOS/iOS 原生热点;适合"重构这个 SwiftUI View""检查 SwiftUI 架构""SwiftUI 页面为什么卡""根据 Instruments trace 找热点""用 xctrace 分析原生 App 性能";触发词:SwiftUI 开发、SwiftUI 架构、View 重构、Observation、MV、ViewModel、SwiftUI 性能、Instruments、Time Profiler、xctrace、卡顿、掉帧、hang、hitch、body 更新
该技能的功能
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 / MV / ViewModel boundaries | references/swiftui-refactor.md | | SwiftUI page is slow, scrolling janks, body updates too often, Instruments trace needs interpretation | references/swiftui-performance.md | | Record/analyze macOS or iOS native Time Profiler traces from CLI, symbolicate and rank hotspots | references/native-trace.md | | Need deeper Apple/WWDC context for SwiftUI update causes, hangs, Instruments lanes | Read the specific Apple summary files listed in the relevant reference |
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
.tracebundle. - 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
- Classify the task: SwiftUI structure/refactor, SwiftUI performance, or native trace profiling.
- Start code-first for SwiftUI: inspect structure, data flow, Observation ownership, identity, layout, and body work before requesting heavier tooling.
- Use Instruments evidence when available: treat traces/screenshots/CSV as evidence, not as the whole answer.
- Make targeted recommendations: order issues by likely impact and confidence.
- 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
xctraceunless 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 StageFor native trace analysis, use the report structure in references/native-trace.md.
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.
技能包含的文件
- _meta.json
- references/demystify-swiftui-performance-wwdc23.md
- references/mv-patterns.md
- references/native-trace.md
- references/optimizing-swiftui-performance-instruments.md
- references/swiftui-performance.md
- references/swiftui-refactor.md
- references/understanding-hangs-in-your-app.md
- references/understanding-improving-swiftui-performance.md
- scripts/extract_time_samples.py
- scripts/record_time_profiler.py
- scripts/top_hotspots.py
- SKILL.md
如何在 Orkas 中使用
打开 Orkas 桌面应用,进入市场,一键安装此项。还没有 Orkas? 下载 Orkas.