Refactor SwiftUI screens

Refactor one screen without changing what it does

This use case is for the moment when a SwiftUI file has grown into one giant screen and every small edit feels risky. The goal is not to redesign the feature or invent a new architecture. Ask Codex to preserve behavior and layout, then split the screen into small subviews with explicit data flow so the next change becomes easier to review.

Use the Build iOS Apps plugin for this kind of cleanup. Its SwiftUI view refactor skill is opinionated in a useful way: default to MV over MVVM, keep business logic in services or models, use local view state and environment dependencies first, and only keep a view model when the feature clearly needs one.

What to ask Codex to do

Start by naming one concrete screen file and asking Codex to preserve behavior while improving structure. These are the refactor rules worth putting directly in your prompt:

• Reorder the file so environment dependencies, stored properties, computed non-view state, init, body, view helpers, and helper methods are easy to scan top to bottom.
• Extract meaningful sections into dedicated View types with small explicit inputs, @Bindings, and callbacks.
• Keep computed some View helpers rare and small. Do not rebuild one giant screen as a long list of private computed view fragments.
• Move non-trivial button actions and side effects out of body, and move real business logic into services or models.
• Keep the root view tree stable. Prefer localized conditionals in sections or modifiers over top-level if/else branches that swap whole screens.
• Fix Observation ownership as you go. For root @Observable models on iOS 17+, the owning view should store them in @State; use legacy observable wrappers only when your deployment target requires that.

Ask for a small validation loop

Behavior-preserving refactors should come with proof. Ask Codex to run the smallest build, preview, test, or simulator check that exercises the screen after each meaningful extraction, then summarize what changed structurally and what stayed intentionally the same.

Practical tips

Split first, then debate architecture

If a screen is too large, ask Codex to extract section views before introducing a new abstraction layer. A shorter, more explicit view tree often removes the pressure to add a view model at all.

Pass the smallest possible interface into each subview

Prefer let values, @Bindings, and one-purpose callbacks over handing every child view the entire parent model. That makes each extracted section easier to preview and harder to accidentally couple back to the whole screen.

Ask Codex to call out intentional non-changes

For a safe refactor, it helps when Codex explicitly lists what it did not change: business rules, navigation behavior, persistence, analytics semantics, and user-visible layout. That makes review much faster.