swiftui-architecture

Keep local UI state in @State within the view that uses it, lift shared values to the nearest common ancestor and pass them down as arguments or @Binding, and move domain state into @Observable services injected via @Environment only when it must outlive the view or is read by unrelated features.

Use the .task modifier for work tied to the view's lifetime and .task(id:) for work that restarts when an input changes. Check Task.isCancelled before writing results to state, treat cancellation as a non-error, and hold user-triggered work in a Task stored in @State.

No. @StateObject is only for ObservableObject types. For classes marked with the @Observable macro, retain them once with @State and inject them into child views through the environment with .environment().

Use @Binding only when the child view genuinely needs to mutate the parent's state. When the child just reports events, pass callbacks like onAdd or onDelete so the parent controls how state changes, keeping intent explicit.

The guidance does not restructure UIKit internals. Instead, wrap existing view controllers in UIViewControllerRepresentable, wrap standalone views in UIViewRepresentable, or embed SwiftUI in UIKit with UIHostingController, passing values in and events out through callbacks.

Combine publishers with @Published properties and cancellables add unnecessary machinery for one-shot async operations. Swift concurrency with async/await inside .task gives automatic cancellation when the view disappears and keeps error handling in one structured path.