← ClaudeAtlas

swiftui-view-refactorlisted

Refactor SwiftUI view files into stable, testable structure. Use when splitting large views, tightening data flow, or cleaning Observation ownership.
flaqai/ios-application-development-skills · ★ 4 · Web & Frontend · score 75
Install: claude install-skill flaqai/ios-application-development-skills
# SwiftUI View Refactor ## Overview Refactor SwiftUI views toward small, explicit, stable view types. Default to vanilla SwiftUI: local state in the view, shared dependencies in the environment, business logic in services/models, and view models only when the request or existing code clearly requires one. ## Core Guidelines ### 1) View ordering (top → bottom) - Enforce this ordering unless the existing file has a stronger local convention you must preserve. - Environment - `private`/`public` `let` - `@State` / other stored properties - computed `var` (non-view) - `init` - `body` - computed view builders / other view helpers - helper / async functions ### 2) Default to MV, not MVVM - Views should be lightweight state expressions and orchestration points, not containers for business logic. - Favor `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)`, and `onChange` before reaching for a view model. - Inject services and shared models via `@Environment`; keep domain logic in services/models, not in the view body. - Do not introduce a view model just to mirror local view state or wrap environment dependencies. - If a screen is getting large, split the UI into subviews before inventing a new view model layer. ### 3) Strongly prefer dedicated subview types over computed `some View` helpers - Flag `body` properties that are longer than roughly one screen or contain multiple logical sections. - Prefer extracting dedicated `View` types for non-trivial sections, especially wh