SwiftUI View Refactor

Overview

A SwiftUI view grows by accretion: one more section in body, one more flag, one more closure with a network call in it. The result still works, but nobody can change it safely, previews stop being useful, and every state change recomputes the whole screen. Refactoring it means changing the structure while the pixels and the behaviour stay the same. In SwiftUI that takes care, because structure is behaviour: a view's position in the tree is its identity, and moving a view, a @State property or a .task can reset state or change when work runs. This skill gives a fixed order of small moves, the checks that keep behaviour intact, and the form of the final report.

Instructions

1. Agree the boundary and set a safety net

• State the rule to the user: structure changes only. Bugs and design problems you notice are listed in the report, not fixed, unless they ask.
• Build the target first. A refactor that starts from a red build cannot be verified.
• Find the deployment target (it decides whether @Observable is available) and whether the project already has conventions for file layout, naming and state. Match them.
• Make sure the view has a #Preview for each state it can show (loaded, empty, error, busy). If there are none, add them before changing anything: they are the only quick way to see that nothing moved. Keep accessibility identifiers as they are, because UI tests depend on them.

2. Map the view before touching it

Write a short inventory. It decides where the cuts go.