johnrogers SwiftUI Patterns (iOS 17+)
SwiftUI 17+ removes ObservableObject boilerplate with @Observable, simplifies environment injection with @Environment, and introduces task-based async patterns. The core principle: use Apple's modern APIs instead of reactive libraries.
Overview
Quick Reference
| Need | Use (iOS 17+) | NOT |
|---|---|---|
| Observable model | @Observable |
ObservableObject |
| Published property | Regular property | @Published |
| Own state | @State |
@StateObject |
| Passed model (binding) | @Bindable |
@ObservedObject |
| Environment injection | environment(_:) |
environmentObject(_:) |
| Environment access | @Environment(Type.self) |
@EnvironmentObject |
| Async on appear | .task { } |
.onAppear { Task {} } |
| Value change | onChange(of:initial:_:) |
onChange(of:perform:) |
Core Workflow
- Use
@Observablefor model classes (no @Published needed) - Use
@Statefor view-owned models,@Bindablefor passed models - Use
.task { }for async work (auto-cancels on disappear) - Use
NavigationStackwithNavigationPathfor programmatic navigation - Apply
.accessibilityLabel()and.accessibilityHint()to interactive elements
Reference Loading Guide
ALWAYS load reference files if there is even a small chance the content may be required. It's better to have the context than to miss a pattern or make a mistake.
| Reference | Load When |
|---|---|
| Observable | Creating new @Observable model classes |
| State Management | Deciding between @State, @Bindable, @Environment |
| Environment | Injecting dependencies into view hierarchy |
| View Modifiers | Using onChange, task, or iOS 17+ modifiers |
| Migration Guide | Updating iOS 16 code to iOS 17+ |
| MVVM Observable | Setting up view model architecture |
| Navigation | Programmatic or deep-link navigation |
| Performance | Lists with 100+ items or excessive re-renders |
| UIKit Interop | Wrapping UIKit components (WKWebView, PHPicker) |
| Accessibility | VoiceOver, Dynamic Type, accessibility actions |
| Async Patterns | Loading states, refresh, background tasks |
| Composition | Reusable view modifiers or complex conditional UI |
Common Mistakes
Over-using
@Bindablefor passed models — Creating@Bindablefor every property causes unnecessary view reloads. Use@Bindableonly for mutable model properties that need two-way binding. Read-only computed properties should use regular properties.State placement errors — Putting model state in the view instead of a dedicated
@Observablemodel causes view logic to become tangled. Always separate model and view concerns.NavigationPath state corruption — Mutating
NavigationPathincorrectly can leave it in inconsistent state. UsenavigationDestination(for:destination:)with proper state management to avoid path corruption.Missing
.taskcancellation —.taskhandles cancellation on disappear automatically, but nested Tasks don't. Complex async flows need explicit cancellation tracking to avoid zombie tasks.Ignoring environment invalidation — Changing environment values at parent doesn't invalidate child views automatically. Use
@Environmentconsistently and understand when re-renders happen based on observation.UIKit interop memory leaks —
UIViewRepresentableandUIViewControllerRepresentablecan leak if delegate cycles aren't broken. Weak references and explicit cleanup are required.