Passing Data Between Views
SwiftUI view hierarchies are trees, and data generally flows down that tree explicitly rather than being fetched by children on demand. Choosing the right mechanism for passing data — plain initializer parameters, @Binding for two-way mutation, environment objects for widely shared state, or navigation values for pushing data to a new screen — has a big effect on how testable and maintainable your views end up being. The guiding principle is to pass the least powerful tool that solves the problem: prefer a plain constant over a binding, and prefer a binding over reaching for shared environment state.
Cricket analogy: Team instructions flow down from captain to bowler to fielder in a set hierarchy rather than the fielder radioing the dressing room to ask what to do, mirroring how SwiftUI data flows explicitly down the view tree rather than children fetching on demand.
Simple Downward Data: Initializer Parameters
The most common and simplest way to pass data is through a view's initializer, exactly like passing arguments to any Swift struct. If a child view only needs to read a value and never mutate it, a plain let property is correct — there's no need for @Binding or @State just to display data. This keeps the child view a pure function of its inputs, easy to preview and unit test in isolation.
Cricket analogy: Handing a scorer a fixed final total to display on the board is like passing a plain let value—the scorer only reads and shows it, never needing write access to recalculate the match themselves.
struct ProfileHeaderView: View {
let username: String
let followerCount: Int
var body: some View {
VStack(alignment: .leading) {
Text(username).font(.title2.bold())
Text("\(followerCount) followers")
.foregroundStyle(.secondary)
}
}
}Two-Way Data: @Binding
When a child view needs to both read and write a value owned by a parent (for example, a text field editing a parent's @State), pass a @Binding instead of a plain value. The parent creates the binding with the $ prefix on its own @State property; the child declares a @Binding property of the same type. Edits made inside the child immediately update the parent's source of truth, because a binding is a reference to the storage location, not a copy of the value.
Cricket analogy: A shared scorebook where both the scorer and the umpire can write updates, and any correction either makes instantly reflects for both, mirrors a @Binding—a reference to one shared source of truth, not separate copies.
struct SearchBar: View {
@Binding var query: String
var body: some View {
TextField("Search", text: $query)
.textFieldStyle(.roundedBorder)
}
}
struct SearchScreen: View {
@State private var searchText = ""
var body: some View {
SearchBar(query: $searchText)
}
}Shared and Deep Data: Environment
Passing a value through every intermediate initializer works for a two- or three-level hierarchy but becomes tedious ('prop drilling') for deeply nested trees where only a leaf view actually needs the data. For that case, environmentObject (or the newer @Environment with an @Observable type) injects a shared object into the environment once, and any descendant view can read it without every intermediate view needing to know about it. This is best reserved for genuinely cross-cutting state — a logged-in user, a theme, a shared cart — not as a general substitute for normal parameter passing.
Cricket analogy: Rather than a message about a rain delay passing manually through every fielder to reach the twelfth man, the whole ground's PA system broadcasts it once and anyone who needs it hears it directly, mirroring environmentObject injecting shared state once for any descendant to read.
Overusing environment objects for data that is only needed by one or two views makes dependencies implicit and harder to trace, and can make previews and unit tests harder to set up because you must remember to inject every environment object a view (or its descendants) expects, or the app will crash at runtime with an unsatisfied environment requirement.
A useful mental model: initializer parameters are like handing someone a photocopy (they can look, and if it's a binding, write back through a specific channel), while environment objects are like a bulletin board anyone in the building can read from — convenient for building-wide announcements, overkill for a private note to one person.
- Use plain initializer parameters (let) for read-only data passed to a child view.
- Use @Binding when a child needs to read AND mutate a value owned by an ancestor.
- A binding refers to the same underlying storage as the source @State — mutations propagate immediately.
- Use environment objects for genuinely cross-cutting, widely shared state, not as a shortcut around normal parameter passing.
- Prop drilling through several initializers is often preferable to premature environment usage, because it keeps dependencies explicit.
- Choosing the least powerful mechanism that solves the problem keeps views easier to preview, test, and reason about.
Practice what you learned
1. When should a SwiftUI view property be declared as @Binding instead of a plain `let`?
2. What does the $ prefix on a @State property (e.g. $searchText) produce?
3. What is the main risk of overusing environment objects for data only needed by one or two views?
4. Which data-passing approach best fits a small reusable SearchBar view that must update a parent's search text as the user types?
5. What is the general principle for choosing among initializer parameters, @Binding, and environment objects?
Was this page helpful?
You May Also Like
@State and @Binding
Understand how @State owns local view state and how @Binding lets child views read and write that state without owning it themselves.
@EnvironmentObject Basics
Learn how @EnvironmentObject injects a shared model into the SwiftUI view hierarchy so deeply nested views can access it without manual parameter passing.
The @Observable Macro
See how the iOS 17 @Observable macro replaces ObservableObject with automatic, fine-grained property tracking that simplifies SwiftUI model code.
NavigationStack Basics
Understand how NavigationStack replaced NavigationView, how navigationDestination drives push navigation, and how to structure hierarchical screens in SwiftUI.