State management is one of the most important concepts in SwiftUI.
You can create beautiful screens with Text, Button, VStack, List, and NavigationStack, but your application does not become truly interactive until the interface can react to changing data.
For example:
- A counter increases
- A user logs in
- A text field changes
- A task is completed
- A loading indicator appears
- An API response arrives
- A selected tab changes
- A form becomes valid
- A profile is updated
All of these situations involve state.
SwiftUI is built around the idea that:
The user interface should be a reflection of the current application state.
In this guide, you will learn how state management works in SwiftUI, including @State, @Binding, @Observable, @Bindable, @Environment, @StateObject, @ObservedObject, and practical patterns for real applications.
What Is State in SwiftUI?
State is any piece of data that can change while your application is running and affect what the user sees.
For example:
var isLoggedIn = false
Later:
isLoggedIn = true
The application’s interface may need to change from:
Login Screen
to:
Home Screen
That changing value is state.
Another example:
var count = 0
When the user taps a button:
count += 1
the screen should display the new value.
SwiftUI provides special tools that connect changing data with the UI.
Why State Management Is Important
Without proper state management, your application can become difficult to maintain.
You may experience problems such as:
- UI not updating
- Duplicate data
- Views owning data they should not own
- State being reset unexpectedly
- Difficult navigation logic
- Large view files
- Hard-to-test business logic
- Unclear data flow
Good state management helps keep the application predictable.
A useful mental model is:
State Changes
↓
SwiftUI Re-evaluates View
↓
Updated UI Appears
This is the foundation of SwiftUI.
SwiftUI Uses Declarative UI
SwiftUI is declarative.
Instead of manually telling the interface:
Change this label
Hide this button
Update this color
Show this screen
you describe the UI based on the current state.
For example:
if isLoggedIn {
HomeView()
} else {
LoginView()
}
When:
isLoggedIn = true
SwiftUI can update the interface automatically.
You describe:
What should the UI look like right now?
SwiftUI handles much of the update process.
Basic State Example
Consider a simple counter:
import SwiftUI
struct CounterView: View {
@State private var count = 0
var body: some View {
VStack(spacing: 20) {
Text("Count: \(count)")
.font(.largeTitle)
Button("Increase") {
count += 1
}
}
}
}
The key line is:
@State private var count = 0
When count changes, SwiftUI updates the relevant interface.
What Is @State?
@State is used for simple mutable data owned by a SwiftUI view.
Example:
@State private var username = ""
Other examples:
@State private var isLoading = false
@State private var selectedTab = 0
@State private var showSheet = false
@State private var count = 0
A useful rule is:
Use
@Statewhen the view itself owns the value.
Why Is @State Usually Private?
You will often see:
@State private var count = 0
instead of:
@State var count = 0
This is because local state should generally belong only to that view.
If another view needs access, you normally pass the value or a binding rather than exposing the internal state directly.
This keeps ownership clear.
A Simple Toggle Example
struct SettingsView: View {
@State private var notificationsEnabled = false
var body: some View {
Toggle(
"Notifications",
isOn: $notificationsEnabled
)
.padding()
}
}
The toggle both reads and changes the value.
This introduces another important concept:
$notificationsEnabled
This is a binding.
What Is @Binding?
@Binding allows one view to read and modify state owned by another view.
Suppose a parent view owns:
@State private var isEnabled = false
The child should not create another copy of that state.
Instead, the parent can pass a binding.
Parent View Example
struct ParentView: View {
@State private var isEnabled = false
var body: some View {
SettingsToggle(
isEnabled: $isEnabled
)
}
}
Child View with @Binding
struct SettingsToggle: View {
@Binding var isEnabled: Bool
var body: some View {
Toggle(
"Enable Feature",
isOn: $isEnabled
)
}
}
Conceptually:
Parent Owns State
↓
@State
↓
Binding Passed Down
↓
Child Uses @Binding
This avoids duplicate state.
@State vs @Binding
| Feature | @State | @Binding |
|---|---|---|
| Owns data | Yes | No |
| Can modify value | Yes | Yes |
| Used in child view | Sometimes | Commonly |
| Source of truth | Yes | No |
| Best for | Local state | Shared editable state |
A simple rule:
Own the value?
→ @State
Need to edit a parent's value?
→ @Binding
TextField with State
Text fields commonly use bindings.
Example:
struct LoginView: View {
@State private var email = ""
@State private var password = ""
var body: some View {
VStack {
TextField(
"Email",
text: $email
)
SecureField(
"Password",
text: $password
)
Button("Login") {
print(email)
}
}
.padding()
}
}
The text fields update the state as the user types.
Derived State
Sometimes you do not need another stored state property.
You can calculate a value from existing state.
Example:
@State private var firstName = ""
@State private var lastName = ""
Instead of creating another state variable for the full name:
private var fullName: String {
"\(firstName) \(lastName)"
}
This is called derived state.
The general principle is:
Do not store something as state if it can be calculated from other state.
Example: Form Validation
struct RegisterView: View {
@State private var email = ""
@State private var password = ""
private var isFormValid: Bool {
!email.isEmpty &&
password.count >= 6
}
var body: some View {
VStack {
TextField(
"Email",
text: $email
)
SecureField(
"Password",
text: $password
)
Button("Create Account") {
}
.disabled(!isFormValid)
}
.padding()
}
}
Here:
isFormValid
does not need @State.
It depends on email and password.
State and Conditional UI
SwiftUI can render different views depending on state.
Example:
struct ContentView: View {
@State private var isLoggedIn = false
var body: some View {
if isLoggedIn {
HomeView()
} else {
LoginView()
}
}
}
When state changes, SwiftUI evaluates the correct branch.
Showing a Loading Indicator
struct DataView: View {
@State private var isLoading = false
var body: some View {
VStack {
if isLoading {
ProgressView()
} else {
Text("Content Loaded")
}
Button("Load") {
isLoading = true
}
}
}
}
This is another example of state controlling the interface.
State and Sheets
SwiftUI sheets are also controlled by state.
struct ProfileView: View {
@State private var showEditProfile = false
var body: some View {
Button("Edit Profile") {
showEditProfile = true
}
.sheet(
isPresented: $showEditProfile
) {
EditProfileView()
}
}
}
The sheet appears when:
showEditProfile == true
State and Alerts
struct DeleteView: View {
@State private var showDeleteAlert = false
var body: some View {
Button("Delete") {
showDeleteAlert = true
}
.alert(
"Delete Item?",
isPresented: $showDeleteAlert
) {
Button(
"Delete",
role: .destructive
) {
// Delete item
}
Button(
"Cancel",
role: .cancel
) {
}
}
}
}
Again, a Boolean state controls presentation.
State and Navigation
State can also affect navigation.
Modern SwiftUI uses tools such as:
NavigationStack
Example:
struct ContentView: View {
@State private var path: [String] = []
var body: some View {
NavigationStack(
path: $path
) {
List {
Button("Profile") {
path.append("profile")
}
}
.navigationDestination(
for: String.self
) { route in
if route == "profile" {
ProfileView()
}
}
}
}
}
Navigation itself can be modeled as state.
When @State Is Not Enough
@State is excellent for simple values.
But applications eventually need more complex state.
For example:
User Profile
Authentication
Cart
API Data
App Settings
Task List
Checkout State
Search Results
Putting all of this directly inside a view can make it too large.
That is where observable model objects become useful.
The Modern Observation System
Modern Swift supports the Observation framework.
A model can use:
@Observable
Example:
import Observation
@Observable
final class CounterModel {
var count = 0
func increment() {
count += 1
}
}
The class contains both:
- State
- Logic
This helps move behavior away from the view.
Using @Observable in SwiftUI
Example:
import SwiftUI
import Observation
@Observable
final class CounterModel {
var count = 0
func increment() {
count += 1
}
}
struct CounterView: View {
@State private var model =
CounterModel()
var body: some View {
VStack {
Text(
"Count: \(model.count)"
)
Button("Increase") {
model.increment()
}
}
}
}
SwiftUI tracks accessed observable properties and updates relevant UI when they change.
Why Put an Observable Model in @State?
This can look confusing:
@State private var model = CounterModel()
Even though the model is a class.
With the modern Observation system, @State can be used to give the view ownership of an observable model instance.
The key idea remains:
View Owns Model
↓
@State
What Is @Bindable?
@Bindable is useful when you need bindings to properties of an observable object.
Suppose:
@Observable
final class ProfileModel {
var name = ""
}
A child view may receive the model and need to bind directly to its properties.
Example:
struct ProfileForm: View {
@Bindable var model: ProfileModel
var body: some View {
TextField(
"Name",
text: $model.name
)
}
}
This provides a binding to:
model.name
@State and @Bindable Together
A parent may own the model:
struct ProfileView: View {
@State private var model =
ProfileModel()
var body: some View {
ProfileForm(
model: model
)
}
}
The child:
struct ProfileForm: View {
@Bindable var model: ProfileModel
var body: some View {
TextField(
"Name",
text: $model.name
)
}
}
Conceptually:
Parent
↓
Owns observable model
↓
@State
Child
↓
Needs property bindings
↓
@Bindable
Older ObservableObject Pattern
Many existing SwiftUI projects use:
ObservableObject
with:
@Published
Example:
final class CounterViewModel:
ObservableObject {
@Published var count = 0
func increment() {
count += 1
}
}
Then the view may use:
@StateObject
private var viewModel =
CounterViewModel()
This pattern is still important because you will encounter it in existing codebases.
What Is @StateObject?
@StateObject is used with ObservableObject when the view owns the object.
Example:
struct CounterView: View {
@StateObject
private var viewModel =
CounterViewModel()
var body: some View {
Text(
"\(viewModel.count)"
)
}
}
The object survives SwiftUI view updates and is managed as the view’s state object.
What Is @ObservedObject?
@ObservedObject is used when a view receives an observable object from somewhere else.
Example:
struct CounterChildView: View {
@ObservedObject
var viewModel: CounterViewModel
var body: some View {
Text(
"\(viewModel.count)"
)
}
}
The child observes changes but does not own the object.
@StateObject vs @ObservedObject
| Property Wrapper | Owns Object | Typical Use |
|---|---|---|
@StateObject | Yes | View creates object |
@ObservedObject | No | Object passed into view |
Simple rule:
Create it here?
→ @StateObject
Receive it here?
→ @ObservedObject
This is specifically for the older ObservableObject model.
Modern Observation vs ObservableObject
For newer SwiftUI development, you may see:
@Observable
instead of:
ObservableObject
@Published
Older approach:
final class UserViewModel:
ObservableObject {
@Published
var name = ""
}
Modern Observation approach:
@Observable
final class UserModel {
var name = ""
}
The modern approach can reduce boilerplate.
However, understanding both is important because production apps may use either.
What Is @Environment?
@Environment allows views to access values provided by the surrounding SwiftUI environment.
Example:
@Environment(\.colorScheme)
private var colorScheme
You can then check:
if colorScheme == .dark {
// Dark mode
}
Other environment values can provide things such as:
- Dismiss actions
- Locale
- Calendar
- Accessibility settings
- Layout direction
- Custom shared dependencies
Dismissing a Sheet with @Environment
Example:
struct EditView: View {
@Environment(\.dismiss)
private var dismiss
var body: some View {
Button("Close") {
dismiss()
}
}
}
This is a common SwiftUI pattern.
Custom Environment Values
Applications can also inject custom shared values into the environment.
This can be useful for:
- Authentication
- App settings
- Theme systems
- Services
- Shared models
With modern SwiftUI, observable models can often be placed into the environment.
Conceptually:
App
↓
Shared Model
↓
Environment
↓
Many Child Views
This can reduce manual parameter passing.
Avoid Excessive Environment Usage
Environment is useful, but it should not become a place to hide every dependency.
If everything comes from the environment, it may become difficult to understand where data originates.
Use it when the value is genuinely shared across a broad part of the view hierarchy.
Single Source of Truth
One of the most important state management rules is:
There should usually be one clear owner for each piece of mutable state.
Suppose a parent has:
@State private var username = ""
A child should not create:
@State private var username = ""
for the same logical value.
That creates two sources of truth.
Instead, pass:
$username
and use:
@Binding
in the child.
Bad State Design
Parent username
+
Child username
+
ViewModel username
+
Settings username
If all are independent copies, they can become inconsistent.
Better State Design
Single Source of Truth
↓
Pass Value or Binding
↓
Views Display State
This makes data flow easier to reason about.
State Should Live as High as Necessary
Suppose two sibling views need the same value.
Instead of storing the state separately in both siblings:
Parent
├── Child A → own state
└── Child B → own state
move state to their shared parent:
Parent → owns state
├── Child A → reads/binds
└── Child B → reads/binds
This is often called lifting state up.
Practical Example: Shared Counter
struct ParentView: View {
@State private var count = 0
var body: some View {
VStack {
CounterDisplay(
count: count
)
CounterControls(
count: $count
)
}
}
}
Display-only child:
struct CounterDisplay: View {
let count: Int
var body: some View {
Text("Count: \(count)")
}
}
Editable child:
struct CounterControls: View {
@Binding var count: Int
var body: some View {
Button("Increase") {
count += 1
}
}
}
This is clean unidirectional data flow.
Unidirectional Data Flow
A healthy SwiftUI architecture often looks like:
State
↓
View
↓
User Action
↓
Logic
↓
State Changes
↓
View Updates
This predictability makes applications easier to debug.
State Management in a Task App
Suppose we have:
struct TaskItem: Identifiable {
let id = UUID()
let title: String
var isCompleted = false
}
A simple task screen may own:
@State
private var tasks: [TaskItem] = []
Then:
List(tasks) { task in
Text(task.title)
}
When we add:
tasks.append(
TaskItem(
title: "Learn SwiftUI"
)
)
the interface updates.
Moving Task Logic into a Model
As the app grows, move logic away from the view.
import Observation
@Observable
final class TaskStore {
var tasks: [TaskItem] = []
func addTask(
title: String
) {
let task =
TaskItem(
title: title
)
tasks.append(task)
}
func deleteTask(
id: UUID
) {
tasks.removeAll {
$0.id == id
}
}
}
The view:
struct TaskView: View {
@State private var store =
TaskStore()
var body: some View {
List(store.tasks) { task in
Text(task.title)
}
}
}
This keeps the screen simpler.
State vs Business Logic
State is not exactly the same as business logic.
State:
isLoading
tasks
currentUser
selectedCategory
Logic:
Validate email
Calculate total
Submit order
Fetch products
Apply discount
Delete task
Keeping logic separate from pure view code usually improves maintainability.
API Loading State
A real application often needs multiple UI states.
For example:
Idle
Loading
Success
Failure
A model might use:
enum ViewState {
case idle
case loading
case loaded
case failed(String)
}
Then:
@Observable
final class UserStore {
var state: ViewState = .idle
}
The UI can switch based on the state.
Rendering API States
switch store.state {
case .idle:
Text("Ready")
case .loading:
ProgressView()
case .loaded:
UserListView()
case .failed(let message):
Text(message)
}
This is often better than using several unrelated Boolean properties.
Avoid Too Many Booleans
A weak design may look like:
var isLoading = false
var hasError = false
var isSuccess = false
var isEmpty = false
These values can become contradictory.
For example:
isLoading = true
isSuccess = true
What does that mean?
A state enum can be clearer.
Better State with Enum
enum ScreenState {
case loading
case content
case empty
case error(String)
}
Only one state can be active at a time.
This improves predictability.
Authentication State
Authentication is a common global state.
Example:
@Observable
final class AuthStore {
var currentUser: User?
var isAuthenticated: Bool {
currentUser != nil
}
func logout() {
currentUser = nil
}
}
At the application level:
if authStore.isAuthenticated {
MainTabView()
} else {
LoginView()
}
This makes authentication state drive the root UI.
Local State vs Global State
Not every state needs to be global.
Local State
Examples:
Text field text
Sheet visibility
Selected segment
Toggle value
Expansion state
Use local state when only one small part of the UI needs it.
Shared State
Examples:
Authenticated user
Shopping cart
Subscription status
App settings
Global theme
Shared state may belong higher in the hierarchy or in an environment model.
The goal is not:
Make everything global.
The goal is:
Put state at the smallest scope that still allows all required consumers to access it.
Temporary UI State
Some state is purely visual.
Examples:
@State private var showPassword = false
@State private var selectedTab = 0
@State private var showFilterSheet = false
This type of state usually belongs directly in the view.
Persistent State
Some values should survive app restarts.
Examples:
Theme preference
Onboarding completed
Tasks
User settings
Favorites
@State alone does not provide persistence.
You may use:
@AppStorage- SwiftData
- Core Data
- Files
- Keychain
- Remote backend
depending on the type of data.
What Is @AppStorage?
@AppStorage provides convenient access to values stored in UserDefaults.
Example:
@AppStorage("isDarkMode")
private var isDarkMode = false
This can persist a simple preference.
Another example:
@AppStorage("username")
private var username = ""
Use it for small settings, not large application databases.
@State vs @AppStorage
@State
→ Temporary view-owned state
@AppStorage
→ Small persisted preference
For example:
@State private var searchText = ""
does not need persistence.
But:
@AppStorage("selectedTheme")
private var selectedTheme = "system"
may be appropriate.
State Management with SwiftData
For persistent application models, SwiftData can be used in modern Apple development.
Instead of keeping everything in:
@State
you can store models persistently.
This is useful for applications such as:
- Task managers
- Notes apps
- Expense trackers
- Inventory
- Saved content
State management and persistence work together but are separate concepts.
SwiftUI state tells the UI what to display.
Persistence determines whether data survives application restarts.
State and Async/Await
Real applications often update state after asynchronous work.
Example:
@Observable
final class ProductStore {
var products: [Product] = []
var isLoading = false
func loadProducts() async {
isLoading = true
defer {
isLoading = false
}
// Fetch products
}
}
The view:
if store.isLoading {
ProgressView()
} else {
ProductList(
products: store.products
)
}
State changes as asynchronous work progresses.
Avoid Updating UI State from the Wrong Context
UI-related state often needs to remain synchronized with the main actor.
For models that coordinate UI state, you may use:
@MainActor
Example:
@MainActor
@Observable
final class ProfileStore {
var name = ""
func loadProfile() async {
// Update UI state safely
}
}
Understanding Swift concurrency becomes increasingly important as your application grows.
State Management and MVVM
Many SwiftUI applications use an MVVM-style structure.
View
↓
ViewModel
↓
Service
↓
API / Database
The view displays state.
The ViewModel manages:
- State
- User actions
- Validation
- Data transformations
- Service calls
Example:
@Observable
final class LoginViewModel {
var email = ""
var password = ""
var isLoading = false
var errorMessage: String?
func login() async {
// Login logic
}
}
Then the view focuses on presentation.
Example Login View
struct LoginView: View {
@State private var viewModel =
LoginViewModel()
var body: some View {
@Bindable var viewModel =
viewModel
VStack {
TextField(
"Email",
text: $viewModel.email
)
SecureField(
"Password",
text: $viewModel.password
)
if viewModel.isLoading {
ProgressView()
}
Button("Login") {
Task {
await viewModel.login()
}
}
}
.padding()
}
}
This is much closer to real-world SwiftUI architecture.
State Management and Dependency Injection
A ViewModel should not necessarily create every dependency itself.
Instead of:
let service = APIService()
inside every model, inject it.
Example:
@Observable
final class UserViewModel {
private let service:
UserService
init(
service: UserService
) {
self.service = service
}
}
This improves:
- Testing
- Reusability
- Architecture
- Mocking
State Management and Testing
Good state management makes testing easier.
Suppose:
@Observable
final class CounterModel {
var count = 0
func increment() {
count += 1
}
}
You can test logic without rendering the UI.
Conceptually:
Create Model
↓
Call increment()
↓
Check count
Separating logic from views makes unit testing much simpler.
Common Mistake: Making Everything @State
Not every property needs @State.
Bad:
@State private var title = "Profile"
if title never changes.
Better:
private let title = "Profile"
Use state only when the value is expected to change and affect the interface.
Common Mistake: Duplicating State
Bad:
struct ParentView: View {
@State
private var name = ""
}
and child:
struct ChildView: View {
@State
private var name = ""
}
for the same logical value.
Now both can disagree.
Use:
@Binding
instead.
Common Mistake: Using Global State for Everything
A global state object may seem convenient, but it can create tight coupling.
If a search field is used only on one screen, it probably does not belong in a global app store.
Keep state local whenever possible.
Common Mistake: Putting Networking Directly in Views
A view containing:
UI
Networking
Validation
Database
Authentication
Analytics
will quickly become difficult to manage.
Prefer moving business operations into models/services.
Common Mistake: Too Many State Objects
You do not need a separate ViewModel for every tiny component.
A simple view such as:
struct LikeButton: View {
@State
private var isLiked = false
}
does not necessarily need a separate observable class.
Architecture should solve actual complexity, not create more of it.
Common Mistake: Ignoring Ownership
Whenever you use state, ask:
Who should own this value?
Possible answers:
This View
Parent View
Feature Model
Application
Persistence Layer
Backend
Once ownership is clear, choosing the correct SwiftUI tool becomes easier.
Which State Tool Should You Use?
A simple guide:
| Situation | Recommended Tool |
|---|---|
| Local mutable value | @State |
| Edit parent’s state | @Binding |
| View owns modern observable model | @State + @Observable |
| Need bindings to observable properties | @Bindable |
| Shared environment value | @Environment |
| Small persistent setting | @AppStorage |
| Own older ObservableObject | @StateObject |
| Observe external ObservableObject | @ObservedObject |
State Management Decision Flow
Use this mental flow:
Does the value change?
↓
Yes
↓
Who owns it?
↓
View itself
→ @State
↓
Parent owns it
→ @Binding
↓
Complex feature model
→ @Observable
↓
Need field bindings
→ @Bindable
↓
Shared across hierarchy
→ Environment
↓
Persistent small preference
→ @AppStorage
Example: Complete Profile Form
import SwiftUI
import Observation
@Observable
final class ProfileModel {
var name = ""
var email = ""
var receiveUpdates = true
var isSaving = false
var canSave: Bool {
!name.isEmpty &&
!email.isEmpty
}
func save() async {
guard canSave else {
return
}
isSaving = true
defer {
isSaving = false
}
// Save profile
}
}
View:
struct ProfileView: View {
@State
private var model =
ProfileModel()
var body: some View {
@Bindable var model =
model
Form {
Section("Profile") {
TextField(
"Name",
text: $model.name
)
TextField(
"Email",
text: $model.email
)
}
Section {
Toggle(
"Receive Updates",
isOn:
$model.receiveUpdates
)
}
Button("Save") {
Task {
await model.save()
}
}
.disabled(
!model.canSave ||
model.isSaving
)
if model.isSaving {
ProgressView()
}
}
.navigationTitle(
"Profile"
)
}
}
This example combines several state management principles:
- View owns the model
- Model owns feature state
- Bindings connect form controls
- Derived state controls the button
- Async action updates loading state
- UI reacts automatically
Example: Shopping Cart State
A cart often needs to be shared across multiple screens.
@Observable
final class CartStore {
var items: [CartItem] = []
var totalItems: Int {
items.reduce(0) {
$0 + $1.quantity
}
}
func add(
_ product: Product
) {
// Add product
}
func remove(
_ item: CartItem
) {
// Remove item
}
}
The store can be provided near the application root.
Conceptually:
App
↓
CartStore
↓
TabView
├── Products
├── Product Detail
└── Cart
All relevant screens can work with the same cart state.
Example: Search State
Search state is often local to a feature.
@State
private var searchText = ""
Derived results:
private var filteredUsers:
[User] {
guard !searchText.isEmpty
else {
return users
}
return users.filter {
$0.name
.localizedCaseInsensitiveContains(
searchText
)
}
}
Then:
List(filteredUsers) { user in
Text(user.name)
}
.searchable(
text: $searchText
)
There is no reason to create another state variable for filteredUsers.
Example: Tab State
struct MainView: View {
@State
private var selectedTab = 0
var body: some View {
TabView(
selection: $selectedTab
) {
HomeView()
.tag(0)
SearchView()
.tag(1)
ProfileView()
.tag(2)
}
}
}
The selected tab is simple UI state.
@State is appropriate.
Example: Favorite Button
struct FavoriteButton: View {
@Binding
var isFavorite: Bool
var body: some View {
Button {
isFavorite.toggle()
} label: {
Image(
systemName:
isFavorite
? "heart.fill"
: "heart"
)
}
}
}
A parent owns the actual favorite value and the button modifies it through a binding.
State Lifecycle Matters
SwiftUI views are value types and can be recreated frequently.
This is one reason you should not treat normal stored properties inside views as persistent mutable storage.
For example:
struct CounterView: View {
var count = 0
}
is not equivalent to:
@State
private var count = 0
SwiftUI manages the storage for @State separately from the transient View value.
Why Normal Variables Do Not Work Like @State
Bad example:
struct CounterView: View {
var count = 0
var body: some View {
Button(
"Count \(count)"
) {
// Cannot correctly mutate
// view state this way
}
}
}
SwiftUI views are structs, and their lifecycle is different from traditional mutable UI objects.
Property wrappers provide the correct storage semantics.
State Management and Performance
Poor state design can cause unnecessary view updates or make the application difficult to optimize.
Good practices include:
- Keep state scoped appropriately
- Avoid giant global objects
- Split large views
- Store only necessary state
- Use derived values
- Avoid duplicate state
- Keep expensive work outside
body - Use stable identifiers for collections
Performance is usually improved by better architecture rather than random micro-optimizations.
Avoid Heavy Work in body
Do not do expensive networking, file access, or complex calculations directly inside:
var body: some View
body can be evaluated many times.
Instead:
- Move heavy logic into a model
- Cache where appropriate
- Perform async work with task-based APIs
- Derive lightweight presentation values only
State and Lists
Dynamic collections require stable identity.
Example:
struct User: Identifiable {
let id: UUID
let name: String
}
Then:
List(users) { user in
Text(user.name)
}
Stable identity helps SwiftUI understand which rows changed.
Do not unnecessarily generate new IDs every time a view is rendered.
State Management Best Practices
A strong SwiftUI state management strategy usually follows these principles:
- Keep state as local as possible.
- Have one clear source of truth.
- Use
@Bindinginstead of duplicating editable state. - Separate complex feature logic from UI.
- Use observable models when state becomes complex.
- Prefer derived values over duplicated stored state.
- Model mutually exclusive states using enums.
- Use environment values only when genuinely shared.
- Persist only data that actually needs persistence.
- Keep user actions flowing back toward the state owner.
SwiftUI State Management Cheat Sheet
// Local state
@State
private var count = 0
// Parent-owned editable state
@Binding
var isEnabled: Bool
// Modern observable model
@Observable
final class UserModel {
var name = ""
}
// View owns modern model
@State
private var model =
UserModel()
// Need bindings to model fields
@Bindable
var model: UserModel
// Environment value
@Environment(\.dismiss)
private var dismiss
// Small persisted preference
@AppStorage("darkMode")
private var darkMode = false
// Legacy ObservableObject owner
@StateObject
private var viewModel =
UserViewModel()
// Legacy external ObservableObject
@ObservedObject
var viewModel: UserViewModel
Practice Exercises
Try these exercises to improve your understanding.
Exercise 1: Counter
Create:
Increase
Decrease
Reset
using @State.
Exercise 2: Toggle
Create a dark mode preference toggle using @State.
Exercise 3: Parent and Child
Pass a Boolean from parent to child using @Binding.
Exercise 4: Login Form
Store:
Email
Password
Loading State
Error Message
in an observable model.
Exercise 5: Task List
Create an observable task store supporting:
Add
Complete
Delete
Exercise 6: App Setting
Persist an onboarding completion flag using @AppStorage.
Frequently Asked Questions
What is state management in SwiftUI?
State management is the process of storing, sharing, updating, and observing data that affects the SwiftUI interface.
What is @State used for?
@State is used for mutable state owned locally by a SwiftUI view.
Examples include text fields, toggles, selected tabs, counters, and sheet visibility.
What is the difference between @State and @Binding?
@State owns the value.
@Binding provides editable access to a value owned somewhere else.
Should every variable use @State?
No.
Use @State only for values that change and need SwiftUI to react to those changes.
Constants and derived values do not necessarily need state.
What is @Observable?
@Observable is part of Swift’s modern Observation system and allows an object to expose changing properties that SwiftUI can observe.
What is @Bindable?
@Bindable makes it convenient to create bindings to properties inside an observable object.
It is especially useful with controls such as TextField, Toggle, and Picker.
Is ObservableObject still used?
Yes.
Many existing SwiftUI applications use ObservableObject, @Published, @StateObject, and @ObservedObject.
Understanding them remains useful when maintaining older or existing projects.
Should I use @StateObject or @ObservedObject?
With an ObservableObject:
Use @StateObject when the view owns and creates the object.
Use @ObservedObject when the object is provided from elsewhere.
What is @Environment used for?
@Environment accesses values provided through SwiftUI’s environment, such as dismiss actions, color scheme, locale, and shared custom dependencies.
What is a single source of truth?
It means one place owns the authoritative version of a piece of state.
Other views should read or bind to that state rather than creating competing copies.
Should ViewModels be used for every SwiftUI view?
No.
Small local components often need only @State or @Binding.
Use separate models or ViewModels when a feature contains enough business logic, async work, shared state, or complexity to justify them.
Where should API data be stored?
For small features, it can live in an observable feature model.
In larger apps, state may be coordinated through ViewModels, repositories, and services depending on your architecture.
Can @State save data permanently?
No.
@State manages runtime UI state.
For persistent data, use tools such as SwiftData, Core Data, @AppStorage, files, Keychain, or a backend depending on your requirements.
Final Thoughts
State management is at the center of SwiftUI development.
The most important idea is not memorizing every property wrapper.
It is understanding ownership and data flow.
Start by asking:
What data can change?
↓
Who should own it?
↓
Who needs to read it?
↓
Who needs to modify it?
↓
Should it survive app restart?
From there, the correct tool becomes much easier to choose.
For simple view-owned state:
@State
For editing parent-owned state:
@Binding
For feature-level observable models:
@Observable
For bindings into those models:
@Bindable
For broadly shared values:
@Environment
And for older ObservableObject codebases:
@StateObject
@ObservedObject
@Published
A well-designed SwiftUI app usually follows this flow:
State
↓
UI
↓
User Action
↓
Business Logic
↓
Updated State
↓
Updated UI
Once you understand this pattern, SwiftUI becomes much easier to reason about.
State management is not simply about storing values.
It is about creating a clear, predictable connection between your data, your application logic, and the user interface.
