swiftui-app-architecture-workflow

SwiftUI App Architecture Workflow

Purpose

Provide a docs-first workflow for SwiftUI app-structure decisions in Apple apps. This skill owns ownership-boundary guidance, direct concrete feature-service guidance, transport-choice guidance, focused-context guidance, and anti-pattern correction for SwiftUI app composition across scenes, commands, focus, environment, preferences, and reusable view structure.

It is not the Apple-docs router, not the accessibility workflow, and not the Xcode execution workflow.

SwiftUI View File Rule

SwiftUI is declarative component UI, closer to React, F# Fabulous, and Elm than to imperative AppKit or UIKit code. Each independently reusable View must stand on its own: render from its inputs and framework-managed state, own its local presentation state, and expose intent through narrow actions. Do not make an external ViewModel, store, coordinator, manager, service, or observable object part of a reusable view's public API.

Use the project's explicit three-letter prefix for every project-owned view file and declaration. Name a view GEAWhateverView.swift and an extracted custom modifier GEAWhateverViewModifier.swift. Never use + filenames. Prefer the memberwise initializer Swift synthesizes for a view's stored value, binding, and action properties; do not write an explicit initializer unless it adds real behavior that a memberwise initializer cannot express.

A view component that is complex enough to edit or preview independently must have its own file. Simple private computed view properties and small private helper views may remain in the owning file while they keep that component easy to preview, navigate, and edit. Extract them as soon as they clutter that workflow.

Name an extracted child from its complete composition owner: a toggle card inside GEASettingsSheetView.swift becomes GEASettingsSheetToggleCard.swift. This rule also applies outside views, such as GEAWhateverServiceAdapter.swift.

Extract a custom ViewModifier when a view accumulates more than eight chained modifiers, or earlier when a coherent chain is reusable or obscures the view body. Use view-local @Observable state only when plain @State, derived values, bindings, and small local helpers no longer keep the component readable; create and own that state inside the component with @State, never as an external ViewModel dependency. Runtime/domain values use bare names such as GEAWhatever; persistence Model naming belongs to swiftdata-workflow.