SwiftUI Fundamentals
Manage feature state with the Observation framework, shared models, environment injection, and clear ownership boundaries.
Before you begin
Learning stage
The Observation framework lets SwiftUI track which observable properties a view reads. When one of those properties changes, SwiftUI invalidates views that formed a dependency on it. The @Observable macro synthesizes observation behavior while your model remains an ordinary Swift type with explicit properties and methods.
A view can own an observable reference by storing it in State. Child views that only read the model accept it as a normal property. A child that needs bindings to observable properties uses Bindable. This keeps ownership, reading, and editing as separate decisions.
The environment can distribute a model or service through a subtree when many descendants need it. Environment access is not a replacement for architecture: create the dependency at a clear composition root, inject it deliberately, and keep feature APIs explicit where practical.
Learning stage
The root owns one library model; descendants read it normally and the editor uses Bindable to create a text-field binding.
import Observation
import SwiftUI
@Observable
final class LibraryModel {
var searchText = ""
var lessonTitles = ["State", "Navigation", "Animation"]
var filteredTitles: [String] {
guard !searchText.isEmpty else { return lessonTitles }
return lessonTitles.filter { $0.localizedCaseInsensitiveContains(searchText) }
}
}
struct LibraryScreen: View {
@State private var model = LibraryModel()
var body: some View {
LibraryContent(model: model)
}
}
struct LibraryContent: View {
@Bindable var model: LibraryModel
var body: some View {
List(model.filteredTitles, id: .self) { Text($0) }
.searchable(text: $model.searchText)
}
}Learning stage
Connect the SwiftUI concept to complete, maintainable application features.
Learning stage
Identify patterns that weaken ownership, identity, adaptation, accessibility, or user experience.
Learning stage
Build the behavior in a small Xcode project and review it in multiple states.
Activity 1
Build a @Observable model with lessons, selected IDs, a derived selected count, and toggleSelection(id:). Own it in a root view and display it in two children.
Hint: Let children call a meaningful model method instead of editing the Set directly.
Activity 2
Create a small observable settings model at the app root, place it in the environment, and read it in a descendant. Add a preview that supplies the dependency.
Hint: A preview must reproduce every environment dependency required by the view.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
By reading an observable property in its body
SwiftUI tracks observable properties accessed during view evaluation and invalidates affected views when those values change.
QUESTION 2
When a view receives an observable model and needs bindings to one or more of its editable properties.
The model remains owned elsewhere while the child can pass projected bindings to controls.
Learning stage
Explain the design in terms of data flow, identity, lifecycle, platform behavior, and trade-offs.
Short answer: State expresses view ownership; Observation tracks changes inside a separate model that can be shared across views.
A State value is tied to a view identity. An @Observable model groups feature state and behavior, and SwiftUI tracks the properties each view reads. A root can own the model with State, children can receive it normally, and Bindable supplies editable projections without duplicating ownership.
Possible follow-ups
Learning stage
Observation supports shared, fine-grained feature state while preserving normal Swift types. Create models at explicit ownership boundaries, pass them deliberately, and use environment injection only where subtree-wide access is meaningful.