Overview
SwiftUI for building native iOS, macOS, watchOS, and tvOS apps. Covers declarative UI, state management, navigation, Core Data, and Apple ecosystem integration.
Capabilities
- Build declarative UIs with SwiftUI views and modifiers
- Implement state management (@State, @Binding, @Observable)
- Design navigation with NavigationStack and NavigationLink
- Integrate with Core Data, HealthKit, and Apple services
- Submit to App Store via TestFlight
When to Use
Trigger phrases:
"ios swiftui"
"SwiftUI development — declarative UI, state management, navigation, and Apple ec"
Building native iOS/macOS apps
Need deep Apple ecosystem integration (HealthKit, CarPlay, widgets)
Target iOS 16+ for modern SwiftUI features
Team has Swift experience
When NOT to Use
- Task is about deployment, not development (use deploy skills)
- Task is about code review, not writing (use review skills)
- You need to understand existing code first (use research skills)
- Task is about testing only (use test skills)
- Requirements are unclear (clarify first)
- Task is trivially simple (single line fix)
Pseudo Code
The ios-swiftui workflow follows a standard pipeline pattern.
Core flow:
# ios-swiftui primary flow
input = prepare(raw_data)
result = process(input, config={apple, declarative, development, ecosystem, integration})
validate(result)
deliver(result)
Error handling:
on error:
log(error_details)
retry_with_backoff(max=3)
if still_failing: alert_and_escalate()
SwiftUI View
struct ContentView: View {
@State private var items: [Item] = []
var body: some View {
NavigationStack {
List(items) { item in
NavigationLink(item.name) {
DetailView(item: item)
}
}
.navigationTitle("Items")
.task { await loadItems() }
}
}
func loadItems() async {
items = try? await APIService.fetchItems()
}
}
Observable Pattern
@Observable
class ItemStore {
var items: [Item] = []
func fetch() async throws {
items = try await APIService.fetchItems()
}
}
Common Patterns
- @Observable: Use the new @Observable macro (iOS 17+) over ObservableObject
- NavigationStack: Use NavigationStack over NavigationView (deprecated)
- Task modifier: Use .task {} for async loading instead of .onAppear
- PreviewProvider: Always include previews for rapid development
How to Use
- Understand the requirement and existing codebase patterns
- Design the solution with error handling and testability in mind
- Implement incrementally with tests for each change
- Verify against expected outcomes (manual and automated)
- Document usage, edge cases, and integration points
- Review with team before merging to shared branches
Red Flags
- Skipping tests to ship faster: Untested code breaks in production when you least expect it
- No error handling in production code: Unhandled errors crash services and lose user data
- Hardcoded configuration values: Hardcoded values prevent environment switching and leak secrets
- Ignoring security implications: Missing input validation, auth bypasses, and injection vulnerabilities
- Over-engineering simple solutions: Premature abstraction adds complexity without proportional benefit
Verification
Process
- Analyze the task requirements
- Apply domain expertise
- Verify output quality
Anti-Rationalization Table
| Rationalization |
Reality |
| "Tests slow me down" |
Bugs slow you down 10x more. Tests are speed, not overhead. |
| "I will refactor later" |
Technical debt compounds. Refactor as you go. |
| "It works on my machine" |
If it is not in CI, it does not work. Ship proof, not claims. |
1---2name: ios-swiftui3description: Use when swiftUI development — declarative UI, state management, navigation, and Apple ecosystem integration. Use when working with ios swiftui.4license: Apache-2.05---6789## Overview1011SwiftUI for building native iOS, macOS, watchOS, and tvOS apps. Covers declarative UI, state management, navigation, Core Data, and Apple ecosystem integration.1213## Capabilities1415- Build declarative UIs with SwiftUI views and modifiers16- Implement state management (@State, @Binding, @Observable)17- Design navigation with NavigationStack and NavigationLink18- Integrate with Core Data, HealthKit, and Apple services19- Submit to App Store via TestFlight2021## When to Use22**Trigger phrases:**23- "ios swiftui"24- "SwiftUI development — declarative UI, state management, navigation, and Apple ec"252627- Building native iOS/macOS apps28- Need deep Apple ecosystem integration (HealthKit, CarPlay, widgets)29- Target iOS 16+ for modern SwiftUI features30- Team has Swift experience3132## When NOT to Use3334- Task is about deployment, not development (use deploy skills)35- Task is about code review, not writing (use review skills)36- You need to understand existing code first (use research skills)37- Task is about testing only (use test skills)38- Requirements are unclear (clarify first)39- Task is trivially simple (single line fix)404142## Pseudo Code4344The ios-swiftui workflow follows a standard pipeline pattern.4546Core flow:47```48# ios-swiftui primary flow49input = prepare(raw_data)50result = process(input, config={apple, declarative, development, ecosystem, integration})51validate(result)52deliver(result)53```5455Error handling:56```57on error:58 log(error_details)59 retry_with_backoff(max=3)60 if still_failing: alert_and_escalate()61```626364### SwiftUI View65```swift66struct ContentView: View {67 @State private var items: [Item] = []68 69 var body: some View {70 NavigationStack {71 List(items) { item in72 NavigationLink(item.name) {73 DetailView(item: item)74 }75 }76 .navigationTitle("Items")77 .task { await loadItems() }78 }79 }80 81 func loadItems() async {82 items = try? await APIService.fetchItems()83 }84}85```8687### Observable Pattern88```swift89@Observable90class ItemStore {91 var items: [Item] = []92 93 func fetch() async throws {94 items = try await APIService.fetchItems()95 }96}97```9899## Common Patterns100101- **@Observable**: Use the new @Observable macro (iOS 17+) over ObservableObject102- **NavigationStack**: Use NavigationStack over NavigationView (deprecated)103- **Task modifier**: Use .task {} for async loading instead of .onAppear104- **PreviewProvider**: Always include previews for rapid development105106## How to Use1071081. Understand the requirement and existing codebase patterns1092. Design the solution with error handling and testability in mind1103. Implement incrementally with tests for each change1114. Verify against expected outcomes (manual and automated)1125. Document usage, edge cases, and integration points1136. Review with team before merging to shared branches114115## Red Flags116117- **Skipping tests to ship faster**: Untested code breaks in production when you least expect it118- **No error handling in production code**: Unhandled errors crash services and lose user data119- **Hardcoded configuration values**: Hardcoded values prevent environment switching and leak secrets120- **Ignoring security implications**: Missing input validation, auth bypasses, and injection vulnerabilities121- **Over-engineering simple solutions**: Premature abstraction adds complexity without proportional benefit122123## Verification124125- [ ] Skill output matches expected behavior126127## Process1281291. Analyze the task requirements1302. Apply domain expertise1313. Verify output quality132133## Anti-Rationalization Table134135| Rationalization | Reality |136|---|---|137| "Tests slow me down" | Bugs slow you down 10x more. Tests are speed, not overhead. |138| "I will refactor later" | Technical debt compounds. Refactor as you go. |139| "It works on my machine" | If it is not in CI, it does not work. Ship proof, not claims. |