SwiftUI provides a powerful and declarative way to build UIs, allowing views to react to state changes automatically. However, managing communication between views, especially when passing data or events from one view to another, can be challenging if not handled properly. In this article, we’ll explore several communication patterns in SwiftUI that enable seamless data flow between views, ensuring that updates occur efficiently and in a way that aligns with SwiftUI’s architecture.
We will dive into a practical scenario: starting from a list screen, where a user can tap a button to open a sheet to add a new item. The focus of the article will be on different approaches that allow the newly added item to communicate back to the list screen and update it accordingly. By exploring these patterns—such as closures, bindings, and @Environment objects—you’ll learn best practices for ensuring your SwiftUI views interact harmoniously, without workarounds like boolean flags to force view refreshes.
Become a highly valued iOS developer with AzamSharp School — your ultimate destination for mastering app development through one of the largest collections of iOS video tutorials and workshops. Level up your skills and create exceptional apps!
One of the simplest approaches to communication between views is using closures as callbacks. In this case, UserListScreen can pass a closure to AddUserScreen, which AddUserScreen will call after collecting and validating the necessary information. This allows the new data to be passed back to UserListScreen through the closure.
Here’s how the implementation of AddUserScreen looks:
struct AddUserScreen: View {
@Environment(\.dismiss) private var dismiss
@State private var name: String = ""
let onUserAdd: (User) -> Void
var body: some View {
Form {
TextField("Name", text: $name)
Button("Save") {
let user = User(name: name)
onUserAdd(user)
dismiss()
}
}
}
}
The AddUserScreen requires a mandatory onUserAdd closure, which gets triggered when the save button is tapped. This closure allows the newly created user to be passed back to UserListScreen.
Below is the implementation of the calling screen, UserListScreen:
struct UserListScreen: View {
@Environment(\.httpClient) private var httpClient
@State private var users: [User] = []
@State private var isPresented: Bool = false
private func handleUserAdd(user: User) {
users.append(user)
}
var body: some View {
List(users) { user in
Text(user.name)
}
.sheet(isPresented: $isPresented, content: {
AddUserScreen(onUserAdd: handleUserAdd)
})
.task {
// fetch the users
}
.toolbar(content: {
ToolbarItem(placement: .topBarTrailing) {
Button("Add New User") {
isPresented = true
}
}
})
.navigationTitle("Users")
}
}
There are a couple of interesting points to highlight in UserListScreen. First, we access the HTTPClient directly within the view using custom @Environment values. Additionally, UserListScreen maintains a private state for the users array, which allows it to manage user data locally.
Choosing to maintain private state for model objects within a view depends on the specific use case. Local state is ideal when the data is only relevant to that view and does not need to be shared across other parts of the application.
The handleUserAdd method, defined inside UserListScreen, is responsible for updating the users array by appending the new user to the list.
Another technique is to pass @Binding from UserListScreen to AddUserScreen. This way AddUserScreen directly modify the users array, without needing a callback function.
The implementation is shown below:
struct AddUserScreen: View {
@Environment(\.dismiss) private var dismiss
@State private var name: String = ""
@Binding var users: [User]
var body: some View {
Form {
TextField("Name", text: $name)
Button("Save") {
let user = User(name: name)
users.append(user)
dismiss()
}
}
}
}
The SwiftUI @Binding property wrapper allows a child view to communicate changes back to its parent view. Although a model might not technically be considered a child view, @Binding still enables it to modify data passed from the parent, in this case, the UserListScreen. This creates a two-way data flow, where changes made in the child view can directly update the state in the parent view.
Next, inside the UserListScreen we can pass the binding as shown below:
var body: some View {
List(users) { user in
Text(user.name)
}
.sheet(isPresented: $isPresented, content: {
AddUserScreen(users: $users)
})
While this approach works, it feels inefficient to pass the entire array to another view just to add a single item. A more elegant solution is to use @Environment, which allows us to manage shared state more cleanly across multiple views. We’ll explore this alternative approach next.
The @Environment object provides a way to share state across different views in your application. It allows you to inject global state into any view that needs it, without making it a singleton. The key distinction is that @Environment objects are dependent on where they are injected, meaning their scope is determined by the view hierarchy. Additionally, you can have multiple @Environment objects throughout your app, each managing different aspects of your application’s state.
To address our needs, we can create an @Environment object called UserStore that manages user-related state and functionality. This UserStore will handle tasks such as adding, updating, and deleting users, as well as fetching, sorting, and searching through user data. This centralized state management simplifies interactions with user data across the app.
The implementation is shown below:
@Observable
class UserStore {
// make HTTPClient protocol if needed
let httpClient: HTTPClient
private(set) var users: [User] = []
init(httpClient: HTTPClient) {
self.httpClient = httpClient
self.users = users
}
func addUser(_ user: User) {
users.append(user)
}
func loadUsers() async throws {
do {
users = try await httpClient.fetchUsers()
} catch {
print(error)
}
}
}
The UserStore is marked as an ObservableObject and depends on an HTTPClient to handle network operations. It maintains an array of users, managing all the user-related state and functionality.
The UserListScreen can access UserStore via the environment. To enable this, the UserStore needs to be injected into the environment, as shown below:
#Preview {
NavigationStack {
UserListScreen()
}
.environment(UserStore(httpClient: HTTPClient()))
}
Next, UserListScreen can be updated to use UserStore as shown below:
struct UserListScreen: View {
@Environment(UserStore.self) private var userStore
@State private var isPresented: Bool = false
var body: some View {
List(userStore.users) { user in
Text(user.name)
}
.sheet(isPresented: $isPresented, content: {
AddUserScreen()
})
.task {
do {
try await userStore.loadUsers()
} catch {
print(error)
}
}
.navigationTitle("Users")
}
}
We have removed the local state from the view and replaced it with @Environment, allowing UserStore to manage the state. Now that UserStore is accessible through @Environment, AddUserScreen can directly interact with it to make changes. Here’s how that works:
struct AddUserScreen: View {
@Environment(\.dismiss) private var dismiss
@State private var name: String = ""
@Environment(UserStore.self) private var userStore
var body: some View {
Form {
TextField("Name", text: $name)
Button("Save") {
let user = User(name: name)
userStore.addUser(user)
dismiss()
}
}
}
}
Using this technique we did not have to pass any closure or binding. AddUserScreen access the store through the environment and adds a new user.
One of the main benefits of this approach is that all the views that are interested in users array will automatically get updated. This means you don’t have to fight SwiftUI to manually cause a refresh.
If you’re relying on custom boolean flags to trigger view refreshes in SwiftUI, it likely indicates you’re not leveraging SwiftUI’s declarative nature correctly.
In this article, we explored various communication patterns in SwiftUI that enable seamless interaction between views. From using closures as callbacks, to leveraging @Binding for direct data manipulation, and finally utilizing the power of @Environment objects for shared state management, each method has its own strengths and use cases.
Closures offer simplicity and control, while @Binding enables a two-way data flow. However, @Environment objects provide a more scalable and clean solution for managing state globally, especially when multiple views need access to the same data. By using the right approach for the given scenario, you can avoid common pitfalls like relying on manual refresh mechanisms and instead let SwiftUI’s declarative design do the heavy lifting.
Choosing the correct communication pattern will lead to more maintainable, efficient, and readable SwiftUI applications.