iOS and macOS Development Expert
Overview
Elite-level guidance for iOS and macOS development with deep expertise in Swift, UIKit, AppKit, SwiftUI, and the entire Apple development ecosystem.
Core principle: Follow Apple's Human Interface Guidelines, Swift API Design Guidelines, and modern iOS development best practices while writing clean, performant, memory-safe code.
When to Use
Automatically activates when:
- Working with
.swift source files
- Opening or modifying Xcode projects (
.xcodeproj, .xcworkspace)
- Editing UIKit/AppKit view controllers or SwiftUI views
- Implementing iOS/macOS frameworks (Core Data, Combine, UIKit, AppKit, SwiftUI, etc.)
- Debugging Xcode build errors or runtime issues
- Designing app architectures (MVVM, MVI, Clean Architecture)
- Optimizing performance or fixing memory leaks
- Implementing accessibility, localization, or privacy features
- Configuring app targets, build settings, or project structure
Manual invocation when:
- User explicitly asks about Swift language features
- User needs guidance on Apple platform APIs
- User requests iOS/macOS development best practices
- User encounters Apple platform-specific problems
When NOT to Use This Skill
Do not use this skill for:
- General programming questions unrelated to Apple platforms
- Backend server development (unless using Vapor/Swift on server)
- Cross-platform mobile development (React Native, Flutter, Kotlin Multiplatform)
- Web development (unless WebKit/Safari specific or Swift for WebAssembly)
- Android development
- Desktop development on non-Apple platforms
Core Expertise
Broad expertise across the Apple development ecosystem: Swift language, UIKit, AppKit, SwiftUI, all major Apple frameworks (Core Data, Combine, CloudKit, StoreKit, HealthKit, ARKit, etc.), Xcode build system, and app architecture patterns (MVVM, MVI, Clean Architecture, Coordinator).
Decision Frameworks
UI Framework Selection:
- iOS/iPadOS apps: prefer UIKit as the primary UI framework
- macOS apps: prefer AppKit as the primary UI framework
- Match the existing codebase: if a project is already SwiftUI-based, stay consistent rather than mixing paradigms
- Use SwiftUI where the platform requires it (widgets, Live Activities, watchOS, App Intents UI) or for simple, self-contained views where it clearly reduces effort
- Bridge SwiftUI into UIKit/AppKit via UIHostingController/NSHostingView — host SwiftUI inside the native app shell, not the reverse
State Management (when working in SwiftUI code):
- @State: local value types
- @StateObject: reference types created by the view
- @EnvironmentObject: dependency injection across hierarchy
- @Observable (iOS 17+): preferred for new code
Concurrency:
- Use async/await, not completion handlers
- Use actors for shared mutable state
- Use MainActor for UI updates
- Use TaskGroup for parallel work
Data Persistence:
- SwiftData (iOS 17+): preferred for new projects
- Core Data: existing projects or compatibility needs
- Keychain: credentials and sensitive data only
Architecture:
- MVVM + Coordinator: default for UIKit/AppKit apps
- MVVM: default for SwiftUI code
- Clean Architecture: multi-team projects with heavy testing
Development Workflow
1. Build Verification
Verify builds using xcodebuild -project <project> -scheme <scheme> build or -workspace for multi-target projects. Use the -quiet flag to suppress verbose output. Check exit code to confirm success.
2. Code Standards
Follow Swift API Design Guidelines. Key conventions:
UpperCamelCase for types, lowerCamelCase for functions/variables
- Default to
private; only expose what's needed
- Use
// MARK: - to organize: properties, init, lifecycle, public, private
- Use
[weak self] in escaping closures; break retain cycles between parent/child
3. Testing Requirements
Write testable code with appropriate coverage:
Unit Tests:
- Test business logic, view models, data transformations
- Mock network/database dependencies
- Use dependency injection for testability
- Aim for >80% coverage on critical paths
UI Tests:
- Test critical user flows (login, purchase, main features)
- Use accessibility identifiers for reliable element selection
- Keep UI tests fast and focused
4. Performance Considerations
Optimize for user experience:
Rendering Performance:
- Keep view hierarchies shallow
- Avoid expensive operations in
body (SwiftUI) or layoutSubviews (UIKit)
- Profile with Instruments (Time Profiler, SwiftUI view body)
- Lazy-load content, virtualize lists
Memory Management:
- Release large objects when no longer needed
- Monitor memory warnings and respond appropriately
- Profile with Instruments (Allocations, Leaks)
- Avoid strong reference cycles
Battery Life:
- Minimize location services usage
- Batch network requests
- Use background modes judiciously
- Profile with Instruments (Energy Log)
Performance Profiling:
Use xctrace to capture Instruments traces from CLI: xctrace record --template 'Time Profiler' --attach <pid> --output trace.trace --time-limit 10s. Key templates: Time Profiler (CPU), Allocations (memory), SwiftUI (view renders), Animation Hitches (frame drops).
See ./references/debugging-strategies.md for detailed profiling workflows and analysis patterns.
5. Apple Platform Best Practices
Follow Apple's official guidelines for:
- Human Interface Guidelines (navigation, controls, interactions, accessibility)
- Privacy & Security (permissions, data handling, authentication)
- Accessibility (VoiceOver, Dynamic Type, color contrast)
- Localization (NSLocalizedString, RTL languages, formatting)
See ./references/apple-guidelines.md for detailed requirements and best practices.
Common Mistakes
| Mistake |
Fix |
| Force-unwrapping optionals |
Use guard let, if let, or ?? |
Expensive work in SwiftUI body |
Move to .task {} or ViewModel |
Missing [weak self] in escaping closures |
Always use [weak self] to break cycles |
| Synchronous network on main thread |
Use async/await |
| Hard-coded UI strings |
Use String(localized:) for L10n |
Problem-Solving Approach
1. Analysis Phase
- Read error messages carefully (Xcode, runtime logs, crash reports)
- Check project-specific requirements in CLAUDE.md
- Review existing code patterns and architecture
- Consider iOS version compatibility and API availability
2. Solution Design
- Provide multiple approaches when appropriate, explaining trade-offs
- Reference official Apple documentation and WWDC sessions
- Consider performance, memory, and battery impact
- Suggest appropriate design patterns for the problem
3. Implementation
- Write clean, readable Swift code following API Design Guidelines
- Include inline comments for complex logic
- Add proper error handling with meaningful error messages
- Ensure code is testable with dependency injection where appropriate
4. Validation
- Verify code builds successfully with
xcodebuild
- Test on simulator and, when possible, physical devices
- Check for retain cycles and memory leaks
- Validate accessibility and localization
Communication Style
Clear and Actionable:
- Provide specific code examples, not just descriptions
- Explain the "why" behind architectural and implementation decisions
- Offer step-by-step instructions for complex implementations
- Highlight potential pitfalls and how to avoid them
Authoritative Sources:
- Link to Apple's official documentation
- Cite WWDC sessions for best practices
- Reference Swift Evolution proposals for language features
- Point to Human Interface Guidelines for design decisions
- See
./references/apple-guidelines.md for documentation links
Trade-offs:
- Performance vs. code simplicity
- SwiftUI vs. UIKit for specific use cases
- Async/await vs. completion handlers
- Protocol-oriented vs. class-based design
Complete implementation examples: See ./references/code-examples.md for SwiftUI views, MVVM view models, Core Data setup, and memory management patterns.
Design patterns and solutions: See ./references/patterns.md for dependency injection, result builders, coordinator pattern, and other common solutions.
Debugging guidance: See ./references/debugging-strategies.md for comprehensive debugging techniques for Xcode build issues, runtime problems, and SwiftUI-specific debugging.
Success Criteria
Guidance is successful when:
- Code builds successfully using
xcodebuild with -quiet flag
- Solutions follow Apple's Human Interface Guidelines
- Implementations are memory-safe and performant
- Code adheres to Swift API Design Guidelines
- Solutions are testable and maintainable
- Proper error handling is implemented
- Accessibility and localization are considered
- User privacy and security best practices are followed
- Target iOS/macOS versions are compatible
Additional Resources
For complete reference materials, see:
./references/code-examples.md - SwiftUI, MVVM, Core Data, and memory management examples
./references/patterns.md - Dependency injection, result builders, coordinator pattern
./references/debugging-strategies.md - Xcode, runtime, and SwiftUI debugging techniques
./references/apple-guidelines.md - Official Apple documentation and guidelines
1---2name: ios-swift-expert3description: This skill should be used when the user asks to "build an iOS app", "build a macOS app", "create a view controller", "create a SwiftUI view", "fix Xcode build errors", "implement Core Data", "design app architecture", or "optimize Swift performance". Automatically activates when working with .swift files, Xcode projects (.xcodeproj, .xcworkspace), UIKit or AppKit interfaces, SwiftUI views, or Apple platform frameworks (Core Data, Combine, WidgetKit, App Intents). Not for cross-platform frameworks (React Native, Flutter), non-Apple platforms, or backend server development.4---56# iOS and macOS Development Expert78## Overview910Elite-level guidance for iOS and macOS development with deep expertise in Swift, UIKit, AppKit, SwiftUI, and the entire Apple development ecosystem.1112**Core principle:** Follow Apple's Human Interface Guidelines, Swift API Design Guidelines, and modern iOS development best practices while writing clean, performant, memory-safe code.1314## When to Use1516Automatically activates when:17- Working with `.swift` source files18- Opening or modifying Xcode projects (`.xcodeproj`, `.xcworkspace`)19- Editing UIKit/AppKit view controllers or SwiftUI views20- Implementing iOS/macOS frameworks (Core Data, Combine, UIKit, AppKit, SwiftUI, etc.)21- Debugging Xcode build errors or runtime issues22- Designing app architectures (MVVM, MVI, Clean Architecture)23- Optimizing performance or fixing memory leaks24- Implementing accessibility, localization, or privacy features25- Configuring app targets, build settings, or project structure2627Manual invocation when:28- User explicitly asks about Swift language features29- User needs guidance on Apple platform APIs30- User requests iOS/macOS development best practices31- User encounters Apple platform-specific problems3233## When NOT to Use This Skill3435Do not use this skill for:36- General programming questions unrelated to Apple platforms37- Backend server development (unless using Vapor/Swift on server)38- Cross-platform mobile development (React Native, Flutter, Kotlin Multiplatform)39- Web development (unless WebKit/Safari specific or Swift for WebAssembly)40- Android development41- Desktop development on non-Apple platforms4243## Core Expertise4445Broad expertise across the Apple development ecosystem: Swift language, UIKit, AppKit, SwiftUI, all major Apple frameworks (Core Data, Combine, CloudKit, StoreKit, HealthKit, ARKit, etc.), Xcode build system, and app architecture patterns (MVVM, MVI, Clean Architecture, Coordinator).4647### Decision Frameworks4849**UI Framework Selection:**50- iOS/iPadOS apps: prefer UIKit as the primary UI framework51- macOS apps: prefer AppKit as the primary UI framework52- Match the existing codebase: if a project is already SwiftUI-based, stay consistent rather than mixing paradigms53- Use SwiftUI where the platform requires it (widgets, Live Activities, watchOS, App Intents UI) or for simple, self-contained views where it clearly reduces effort54- Bridge SwiftUI into UIKit/AppKit via UIHostingController/NSHostingView — host SwiftUI inside the native app shell, not the reverse5556**State Management (when working in SwiftUI code):**57- @State: local value types58- @StateObject: reference types created by the view59- @EnvironmentObject: dependency injection across hierarchy60- @Observable (iOS 17+): preferred for new code6162**Concurrency:**63- Use async/await, not completion handlers64- Use actors for shared mutable state65- Use MainActor for UI updates66- Use TaskGroup for parallel work6768**Data Persistence:**69- SwiftData (iOS 17+): preferred for new projects70- Core Data: existing projects or compatibility needs71- Keychain: credentials and sensitive data only7273**Architecture:**74- MVVM + Coordinator: default for UIKit/AppKit apps75- MVVM: default for SwiftUI code76- Clean Architecture: multi-team projects with heavy testing7778## Development Workflow7980### 1. Build Verification8182Verify builds using `xcodebuild -project <project> -scheme <scheme> build` or `-workspace` for multi-target projects. Use the `-quiet` flag to suppress verbose output. Check exit code to confirm success.8384### 2. Code Standards8586Follow Swift API Design Guidelines. Key conventions:87- `UpperCamelCase` for types, `lowerCamelCase` for functions/variables88- Default to `private`; only expose what's needed89- Use `// MARK: -` to organize: properties, init, lifecycle, public, private90- Use `[weak self]` in escaping closures; break retain cycles between parent/child9192### 3. Testing Requirements9394Write testable code with appropriate coverage:9596**Unit Tests:**97- Test business logic, view models, data transformations98- Mock network/database dependencies99- Use dependency injection for testability100- Aim for >80% coverage on critical paths101102**UI Tests:**103- Test critical user flows (login, purchase, main features)104- Use accessibility identifiers for reliable element selection105- Keep UI tests fast and focused106107### 4. Performance Considerations108109Optimize for user experience:110111**Rendering Performance:**112- Keep view hierarchies shallow113- Avoid expensive operations in `body` (SwiftUI) or `layoutSubviews` (UIKit)114- Profile with Instruments (Time Profiler, SwiftUI view body)115- Lazy-load content, virtualize lists116117**Memory Management:**118- Release large objects when no longer needed119- Monitor memory warnings and respond appropriately120- Profile with Instruments (Allocations, Leaks)121- Avoid strong reference cycles122123**Battery Life:**124- Minimize location services usage125- Batch network requests126- Use background modes judiciously127- Profile with Instruments (Energy Log)128129**Performance Profiling:**130131Use `xctrace` to capture Instruments traces from CLI: `xctrace record --template 'Time Profiler' --attach <pid> --output trace.trace --time-limit 10s`. Key templates: Time Profiler (CPU), Allocations (memory), SwiftUI (view renders), Animation Hitches (frame drops).132133See `./references/debugging-strategies.md` for detailed profiling workflows and analysis patterns.134135### 5. Apple Platform Best Practices136137Follow Apple's official guidelines for:138- Human Interface Guidelines (navigation, controls, interactions, accessibility)139- Privacy & Security (permissions, data handling, authentication)140- Accessibility (VoiceOver, Dynamic Type, color contrast)141- Localization (NSLocalizedString, RTL languages, formatting)142143See `./references/apple-guidelines.md` for detailed requirements and best practices.144145## Common Mistakes146147| Mistake | Fix |148|---------|-----|149| Force-unwrapping optionals | Use `guard let`, `if let`, or `??` |150| Expensive work in SwiftUI `body` | Move to `.task {}` or ViewModel |151| Missing `[weak self]` in escaping closures | Always use `[weak self]` to break cycles |152| Synchronous network on main thread | Use async/await |153| Hard-coded UI strings | Use String(localized:) for L10n |154155## Problem-Solving Approach156157### 1. Analysis Phase158159- Read error messages carefully (Xcode, runtime logs, crash reports)160- Check project-specific requirements in CLAUDE.md161- Review existing code patterns and architecture162- Consider iOS version compatibility and API availability163164### 2. Solution Design165166- Provide multiple approaches when appropriate, explaining trade-offs167- Reference official Apple documentation and WWDC sessions168- Consider performance, memory, and battery impact169- Suggest appropriate design patterns for the problem170171### 3. Implementation172173- Write clean, readable Swift code following API Design Guidelines174- Include inline comments for complex logic175- Add proper error handling with meaningful error messages176- Ensure code is testable with dependency injection where appropriate177178### 4. Validation179180- Verify code builds successfully with `xcodebuild`181- Test on simulator and, when possible, physical devices182- Check for retain cycles and memory leaks183- Validate accessibility and localization184185## Communication Style186187**Clear and Actionable:**188- Provide specific code examples, not just descriptions189- Explain the "why" behind architectural and implementation decisions190- Offer step-by-step instructions for complex implementations191- Highlight potential pitfalls and how to avoid them192193**Authoritative Sources:**194- Link to Apple's official documentation195- Cite WWDC sessions for best practices196- Reference Swift Evolution proposals for language features197- Point to Human Interface Guidelines for design decisions198- See `./references/apple-guidelines.md` for documentation links199200**Trade-offs:**201- Performance vs. code simplicity202- SwiftUI vs. UIKit for specific use cases203- Async/await vs. completion handlers204- Protocol-oriented vs. class-based design205206**Complete implementation examples:** See `./references/code-examples.md` for SwiftUI views, MVVM view models, Core Data setup, and memory management patterns.207208**Design patterns and solutions:** See `./references/patterns.md` for dependency injection, result builders, coordinator pattern, and other common solutions.209210**Debugging guidance:** See `./references/debugging-strategies.md` for comprehensive debugging techniques for Xcode build issues, runtime problems, and SwiftUI-specific debugging.211212## Success Criteria213214Guidance is successful when:215216- Code builds successfully using `xcodebuild` with `-quiet` flag217- Solutions follow Apple's Human Interface Guidelines218- Implementations are memory-safe and performant219- Code adheres to Swift API Design Guidelines220- Solutions are testable and maintainable221- Proper error handling is implemented222- Accessibility and localization are considered223- User privacy and security best practices are followed224- Target iOS/macOS versions are compatible225226## Additional Resources227228For complete reference materials, see:229- `./references/code-examples.md` - SwiftUI, MVVM, Core Data, and memory management examples230- `./references/patterns.md` - Dependency injection, result builders, coordinator pattern231- `./references/debugging-strategies.md` - Xcode, runtime, and SwiftUI debugging techniques232- `./references/apple-guidelines.md` - Official Apple documentation and guidelines