Ios swiftui architecture review

Skill Desquared/agents-rules-skills/skills/ios-swiftui-architecture-review

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.From its SKILL.md

Install

npx -y skills add Desquared/agents-rules-skills --skill ios-swiftui-architecture-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.3 KB, as published. Nobody here has run it

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-analyst Agent 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

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.