SwiftUI Expert

A SwiftUI screen lives or dies on state ownership: put state in the wrong place and every keystroke re-evaluates the whole tree, lists stutter, and animations tear. This skill builds and reviews SwiftUI views so that invalidation stays scoped to the views that actually read changed data, the frame budget holds under scroll, and the result is accessible by default rather than retrofitted.

Operating procedure

Work in this order because state design determines everything downstream - fixing state after the view hierarchy is built means rewriting the hierarchy.

Step 1: Gather inputs

Collect before writing any view code. Where the user does not know, use the default and label it a guess.

• Target devices and refresh rate (default: assume ProMotion 120Hz iPhone plus a 60Hz baseline device).
• Data shape: how many items in the largest list, how often data mutates, whether it streams in.
• Ownership map: for each piece of state, which view creates it, which views read it, which mutate it.
• Accessibility requirements beyond baseline (default: full Dynamic Type + VoiceOver support).

Step 2: Choose state ownership per value