swiftui · note · architecture · state

@Binding is not shared state

Published March 3, 2026 · 2 min read · beginner

Context

Bindings are often misunderstood as shared state. That confusion usually appears when a child view can edit a value and people assume ownership moved into that child. In SwiftUI, edit access and ownership are separate concepts.

The snippet

struct ChildView: View {
    @Binding var value: Int
}

Why this works

A binding is a connection to state that lives somewhere else. The child can read and write through that connection, but it still does not own lifecycle, initialization, or long-term responsibility for the value.

That distinction matters because architecture decisions depend on ownership. If ownership remains with the parent, resets, validation, and side effects should also remain there. The child should focus on presentation and intent.

Use it when…

  • a child view needs to modify parent-owned state
  • ownership must stay clearly defined
  • you want reusable components that do not decide business rules

Avoid it when…

  • the view should manage its own state
  • ownership is unclear
  • multiple unrelated values are tunneled through bindings just for convenience

Takeaway: Bindings borrow state — they never own it.

The fastest way to stay consistent is to ask one question before adding @Binding: who decides this value when requirements change? If the answer is the parent or screen-level flow, @Binding is usually the right boundary.

Next steps