Refactor large SwiftUI views into small dedicated subview types with MV-first data flow, stable view trees, side effects pulled out of body, and non-optional @State observation. USE WHEN a SwiftUI view or body has grown too large, mixes business logic with layout, or needs splitting into explicit, testable components.
Instrucciones de origen · Vista previa de solo lectura
name
swiftui-view-refactor
description
Refactor large SwiftUI views into small dedicated subview types with MV-first data flow, stable view trees, side effects pulled out of body, and non-optional @State observation. USE WHEN a SwiftUI view or body has grown too large, mixes business logic with layout, or needs splitting into explicit, testable components.
cluster
native-ios
version
1.0.0
origin
antigravity-awesome-skills (MIT)
risk
safe
source
Dimillian/Skills (MIT)
date_added
2026-03-25
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.
When to Use
When cleaning up a large SwiftUI view or splitting long body implementations.
When you need smaller subviews, explicit dependency injection, or better Observation usage.
Core Guidelines
1) View ordering (top → bottom)
Enforce this ordering unless the existing file has a stronger local convention you must preserve.
Environment
private/publiclet
@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 when they have state, async work, branching, or deserve their own preview.
Keep computed some View helpers rare and small. Do not build an entire screen out of private var header: some View-style fragments.
Pass small, explicit inputs (data, bindings, callbacks) into extracted subviews instead of handing down the entire parent state.
If an extracted subview becomes reusable or independently meaningful, move it to its own file.
If a view model exists or is explicitly required, replace optional view models with a non-optional @State view model initialized in init.
Confirm Observation usage: @State for root @Observable models on iOS 17+, legacy wrappers only when the deployment target requires them.
Keep behavior intact: do not change layout or business logic unless requested.
Notes
Prefer small, explicit view types over large conditional blocks and large computed some View properties.
Keep computed view builders below body and non-view computed vars above init.
A good SwiftUI refactor should make the view read top-to-bottom as data flow plus layout, not as mixed layout and imperative logic.
For MV-first guidance and rationale, see references/mv-patterns.md.
Large-view handling
When a SwiftUI view file exceeds ~300 lines, split it aggressively. Extract meaningful sections into dedicated View types instead of hiding complexity in many computed properties. Use private extensions with // MARK: - comments for actions and helpers, but do not treat extensions as a substitute for breaking a giant screen into smaller view types. If an extracted subview is reused or independently meaningful, move it into its own file.
Limitations
Use this skill only when the task clearly matches the scope described above.
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
