Agent skill · software engineering · aiskillstore
swiftui-view-refactor
Refactor and review SwiftUI view files for consistent structure, dependency injection, and Observation usage. Use when asked to clean up a SwiftUI view’s layout/ordering, handle view models safely (non-optional when possible), or standardize how dependencies and @Observable state are initialized and passed.
Why this skill is useful
Provides specific patterns and guidelines for structuring SwiftUI views that the AI wouldn't reliably generate on its own.
What it needs
About 3k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
SwiftUI View Refactor Overview Apply a consistent structure and dependency pattern to SwiftUI views, with a focus on ordering, Model-View (MV) patterns, careful view model handling, and correct Observation usage. Core Guidelines 1) View ordering (top → bottom) Environment private/public let @State / other stored properties computed var (non-view) init body computed view builders / other view helpers helper / async functions 2) Prefer MV (Model-View) patterns Default to MV: Views are lightweight state expressions; models/services own business logic. Favor @State, @Environment, @Query, and task/onChange for orchestration. Inject services and shared models via @Environment; keep views small and composable. Split large views into subviews rather than introducing a view model. 3) Split large bodies and view properties If body grows beyond a screen or has multiple logical sections, split it into smaller subviews. Extract large computed view properties (var header: some View { ... }) into dedicated View types when they carry state or complex branching. It's fine to keep related subviews as computed view properties in the same file; extract to a standalone View struct only when it structurally makes sense or when reuse is intended. Prefer passing small inputs (data, bindings, callbacks) over reusing the entire parent view state. Example (extracting a section): Example (long body → shorter body + computed views in the same file): Example (extracting a complex computed view): 4) View model handling (only if already present) Do not introduce a view model unless the request or existing code clearly calls for one. If a view model exists, make it non-optional when possible. Pass dependencies to the view via init, then pass them into the view model in the view's init. Avoid bootstrapIfNeeded patterns. Example (Observation-based): 5) Observation usage For @Observable reference types, store them as @State in the root view. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/swiftui-view-refactor