ios-swiftui-architecture-review
Skill4 starsChanged 3 months agoMITView on GitHub
Analyze SwiftUI view hierarchies and suggest MVVM or other architectural improvements. Use when **reviewing existing SwiftUI code**, creating new SwiftUI components, analyzing view structure, or when the user asks about SwiftUI architecture patterns. Best for code review and refactoring guidance.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- accessibility-annotationsSkill
- android-accessibility-validatorSkill
- android-compose-architecture-reviewSkill
- android-kotlin-api-design-reviewerSkill
- android-performance-profilerSkill
- flutter-accessibility-validatorSkill
- flutter-bug-investigationSkill
- flutter-code-reviewSkill
- flutter-design-architectureSkill
- flutter-feature-analysisSkill
- flutter-feature-implementationSkill
- flutter-performance-optimizerSkill
- ios-accessibility-validatorSkill
- ios-performance-profilerSkill
- ios-swift-api-design-reviewerSkill
- shared-bug-investigationSkill
- shared-perf-comparison-videoSkill
- shared-product-motion-videoSkill
- shared-task-workflowSkill
The file
Files
SwiftUI Architecture Review
When to Use This Skill:
- Reviewing EXISTING SwiftUI views/ViewModels
- Code review for architectural violations
- Refactoring guidance for specific files
- Validating state management patterns
When to Use
project-architecture-analystAgent Instead:
- Planning NEW features (uncertain file placement)
- Understanding project-wide architecture
- Major changes affecting multiple modules
- Need to discover existing patterns before implementing
Review Checklist
Separation of Concerns
- Views: presentation only (no business logic, network, DB)
- ViewModels: state + business logic (@Observable or ObservableObject)
- Data access separated from views
State Management
@State- view-local state only@StateObject- view-owned ViewModels (avoid in List rows)@ObservedObject- passed-in ViewModels@Bindable- two-way binding to Observable objects (iOS 17+)@Environment- shared state (read-only preferred)@EnvironmentObject- injected dependencies (check for missing inject)
State Lifecycle Issues
- No retained cycles in ViewModels (@Published closures)
- Proper cleanup in deinit or .onDisappear
- @StateObject not recreated on parent refresh
- Environment values exist before access
Dependency Injection
- Dependencies injected (check project: Swinject, Resolver, Factory, manual)
- No hardcoded singletons in views
- ViewModels receive dependencies
View Composition
- Views are small (single responsibility)
- Complex views broken into components
- Reusable components extracted
Common Issues
| Issue | Fix |
| Business logic in view | Extract to ViewModel |
| Network call in view | Move to ViewModel with task |
| Singleton in view | Inject via DI or @Environment |
| 200+ line view | Break into components |
Severity
- 🔴 Critical: Architecture violation
- 🟡 Improvement: Better pattern available
- 🟢 Enhancement: Optional optimization
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.