SwiftUI and Identity: A Practical Guide to Better View Management

This week, we’re diving into the world of SwiftUI to make it less of a mystery. SwiftUI is a declarative framework, which means it figures out how to make things happen for you. But sometimes, what you see isn’t quite what you expected. That’s a perfect chance to dig a little deeper, see what’s going on behind the scenes, and build a better feel for how to get the results you’re aiming for.

Types of Identity in SwiftUI

Explicit Identity

Explicit identity in SwiftUI ensures that views can be uniquely identified. This is crucial in dynamic lists or complex view hierarchies where each view must remain distinct. SwiftUI uses value types instead of pointers, unlike UIKit or AppKit. This difference necessitates other mechanisms to define identity explicitly.

SwiftUI leverages the Identifiable protocol or unique identifiers to create explicit identity.

Example: List with Identifiable IDs

Here’s how you can use explicit identity in a List:

struct ContentView: View {
    struct Item: Identifiable {
        let id = UUID()
        let name: String
    }
    
    let items = [
        Item(name: "Item 1"),
        Item(name: "Item 2"),
        Item(name: "Item 3")
    ]
    
    var body: some View {
        List(items) { item in
            Text(item.name)
        }
    }
}

Each Item has a unique UUID to keep it identifiable. SwiftUI uses these IDs to differentiate views.

Example: List with Primative type

If your data is something simple like strings or int, you can use \.self for identity:

struct DynamicListView: View {
    let items =["Apple", "Banana", "Orange"]
    
    var body: some View {
        List(items, id: \.self) { item in
            Text(item)
        }       
    }
}

This works because SwiftUI knows that types like String or Int are inherently unique and conform to Hashable.

Structural Identity

Structural identity is all about how views are organized hierarchically. SwiftUI uses this to decide if a view needs to be recreated or can be reused.

Conditional Views

In cases where the view type varies based on conditions, SwiftUI uses generic structures like ViewBuilder and ConditionalContent. Structural identity helps SwiftUI understand the relationships between views, even when their content changes dynamically.

var body: some View {
    if items.isEmpty {
        PlaceholderView()
    } else {
        List(items) { item in
            Text(item.name)
        }
    }
}

Behind the scenes, SwiftUI turns this into _ConditionalContent<PlaceholderView, List>().

AnyView and ViewBuilder

Using AnyView wraps different return types into a single type, but it can make your code harder to read. Here’s a classic example:

struct ProductItemView: View {
    let category: String
    let productName: String

    var body: some View {
        categoryView(for: category)
            .padding()
            .frame(maxWidth: .infinity, minHeight: 100)
            .background(Color.gray.opacity(0.1))
            .cornerRadius(10)
    }

    private func categoryView(for category: String) -> AnyView {
        switch category {
        case "Electronics":
            AnyView(
                HStack {
                    Image(systemName: "laptopcomputer")
                        .resizable()
                        .frame(width: 40, height: 40)
                        .foregroundColor(.blue)
                    Text("Electronics: \(productName)")
                        .font(.headline)
                }
            )
        case "Fashion":
            AnyView(
                HStack {
                    Image(systemName: "tshirt")
                        .resizable()
                        .frame(width: 40, height: 40)
                        .foregroundColor(.pink)
                    Text("Fashion: \(productName)")
                        .font(.headline)
                }
            )
        case "Groceries":
            AnyView(
                HStack {
                    Image(systemName: "cart")
                        .resizable()
                        .frame(width: 40, height: 40)
                        .foregroundColor(.green)
                    Text("Groceries: \(productName)")
                        .font(.headline)
                }
            )
        default:
            AnyView(
                HStack {
                    Image(systemName: "questionmark")
                        .resizable()
                        .frame(width: 40, height: 40)
                        .foregroundColor(.gray)
                    Text("Other: \(productName)")
                        .font(.headline)
                }
            )
        }
    }
}

Each condition returns a different view wrapped in an AnyView, since Swift needs a single return type for the whole function. But when working with conditional content in SwiftUI, using AnyView makes it tricky to figure out what’s going on, and it can make the code harder to follow.

SwiftUI actually recommends a better way: ditch the AnyView and just add the @ViewBuilder attribute to the function. Problem solved! The conditional content now looks and works like SwiftUI intended.

In general, Apple advises against using AnyView unless absolutely necessary, it makes the code less readable, reduces compile-time checks, and can hurt performance if overused.

View Lifetime

In SwiftUI, a view’s lifetime is tied to its identity. Understanding this helps you manage state and avoid glitches in your app.

Short-lived Views
SwiftUI views are lightweight and short-lived because they’re structs. The system frequently recreates them based on the latest data values.

Lifetime and Identity
A view’s lifetime persists as long as its identity remains stable. For example, in a List, a row’s identity is derived from the data’s identifier. If the identifier changes, SwiftUI discards the old view and creates a new one.

State Persistence
Because state is tied to a view’s lifetime, losing the view’s identity can reset its state. To avoid this, you must ensure a stable identity for your data.

Here’s what happens when identifiers aren’t stable:

struct Item: Identifiable {
    var name: String    
    var id: UUID { UUID() }
}

struct FavoriteItems: View {
    var items: [Item]
    var body: some View {
        List {
            ForEach(items) {
                Text(item.name)
            }
        }
    }
}

Every update causes the view to refresh entirely, leading to flashing or instability. Instead, use a stable identifier:

struct Item: Identifiable {
    var name: String
    var id = UUID()
}

Sometimes, you might write code with branches like this:

struct RoleText: View {
    var userRole: String    

    var body: some View {
        if userRole == "Admin" {
            Text(userRole)
                .font(.headline)
                .foregroundColor(.red)
        } else {
            Text(userRole)
                .font(.body)
                .foregroundColor(.blue)
        }            
    }
}

While this works, it creates two separate copies of the Text view. This isn’t ideal because SwiftUI has to manage them as distinct views, which can lead to inefficiencies or unintended behavior.

To streamline the logic and improve performance, you can combine the branches and move the condition into the view’s modifiers. Here’s how:

struct RoleText: View {
    var userRole: String    

    var body: some View {
        Text(userRole)
            .font(userRole == "Admin" ? .headline : .body)
            .foregroundColor(userRole == "Admin" ? .red : .blue)
    }
}

By doing this:

• Single View: You’re now working with a single Text view instead of creating two.
• Cleaner Code: The conditional logic is consolidated, making the code easier to read and maintain.
• Better Performance: SwiftUI can efficiently update the view without unnecessary re-creations.

For more on why conditional view modifiers should be avoided, check out this great article from objc.io

Best Practices for Managing Identity in SwiftUI

Explicit Identity

• Avoid random identifiers: Using random IDs (e.g., UUID()) during view creation may lead to instability as identifiers change unexpectedly.
• Use stable identifiers: Ensure each piece of data has a consistent identifier throughout its lifecycle.
• Ensure uniqueness: Each identifier in a collection should be unique to avoid conflicts.

Structural Identity

• Minimize conditional branches: Instead of creating new views based on conditionals, use inert modifiers (e.g., opacity or hidden) to modify existing views.
• Tightly scope dependent code: Keep code dependent on conditions localized to avoid unnecessary re-creation of unrelated views.

Conclusion

With these tips, you’ll better understand how SwiftUI manages views and identity, helping you build smoother, more predictable apps. Happy coding!