# Swiftui View Refactor

Refactor and review SwiftUI view files with strong defaults for small dedicated...

- Repository: https://github.com/Dimillian/Skills (4021 stars)
- Category: Mobile
- License: MIT
- Last updated: 2026-03-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Dimillian/Skills --skill swiftui-view-refactor -g -a claude-code -y`
Codex: `npx skills add Dimillian/Skills --skill swiftui-view-refactor -g -a codex -y`
Cursor: `npx skills add Dimillian/Skills --skill swiftui-view-refactor -g -a cursor -y`
Gemini CLI: `npx skills add Dimillian/Skills --skill swiftui-view-refactor -g -a gemini-cli -y`

## Description

Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Use when cleaning up a SwiftUI view, splitting long bodies, removing inline actions or side effects, reducing computed `some View` helpers, or standardizing `@Observable` and view model initialization patterns.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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 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.

Prefer:

The rest: https://github.com/Dimillian/Skills/blob/HEAD/swiftui-view-refactor/SKILL.md