DEV Community: Karthik Pala

Understanding `@State` in SwiftUI: How It Works Under the Hood

Karthik Pala — Sat, 30 Aug 2025 12:50:51 +0000

One of the most magical things about SwiftUI is how little code you need to keep your UI in sync with your data. Declare a property with @State, mutate it, and your view just updates. Simple, right?

But if you’ve ever wondered what’s really happening when you use @State, this article takes a peek under the hood.

Why Do We Even Need `@State`?

Lets take below example

struct CounterView: View {
    private var count = 0

    var body: some View {
        Button("Tap \(count)") {
            count += 1
        }
    }
}

The above code looks good right? Create a button that says “Tap Count” plus the number of times the button has been tapped, then add 1 to tapCount whenever the button is tapped

But this doesn't compile because CounterView is a struct and you can't change properties freely. Okay lets keep this aside for a minute, What other problems do we have with above code?

SwiftUI views get created and destroyed all the time as SwiftUI updates the UI tree.

If count were just a plain Int property on a struct, it would reset to 0 every time the view was recreated. We’d lose our state instantly.

This is where @State comes in. It tells SwiftUI:

“Hey, this piece of data should survive across view reloads.”

For example:

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        Button("Tap \(count)") {
            count += 1
        }
    }
}

What `@State` Really Is

@State is a property wrapper provided by SwiftUI. When you write:

@State private var count = 0

Under the hood, the State type looks like this (simplified assumption):

@propertyWrapper
struct State<Value>: DynamicProperty {
    init(initialValue: Value)
    var wrappedValue: Value { get nonmutating set }
    var projectedValue: Binding<Value> { get }
}

So, count is just wrappedValue inside a property wrapper. But the important part is where that value is stored.

Notice the nonmutating set on wrappedValue — this is what allows us to change a @State variable inside a struct View even though structs are normally immutable in SwiftUI’s body.

Note: See the section on DynamicProperty below to understand how it helps the State property wrapper

Where Does the Value Live?

When you set @State var count = 0, the value 0 is not stored inside your view struct

Instead, SwiftUI maintains a hidden state storage that lives outside the view. Each piece of state is associated with the identity of the view in the UI hierarchy.

Think of it like this:

Every time SwiftUI re-creates CounterView, it reattaches _count to the same storage box. That’s why the state survives view updates.

How Updates Trigger UI Refresh

When you mutate a @State variable:

count += 1

The setter does two things:

Updates the underlying stored value in SwiftUI’s state system.
Marks the view as dirty and schedules a re-render.

That’s why the UI automatically refreshes with the new value — SwiftUI invalidates the current body and recomputes it.

`@State` and `Binding`

When you use the $ prefix, you don’t get the raw value — you get a Binding:

$count  // Binding<Int>

A Binding is essentially a lightweight reference to the same state storage. This allows child views to read and write the parent’s state without owning it.

Example:

TextField("Name", text: $name)

Here, TextField can directly mutate the name state in the parent view.

Lifecycle of a `@State` Property

At runtime, the flow looks like this:

SwiftUI builds the view struct (CounterView).
It sees a @State property and checks if there’s existing storage.
If storage exists, it reuses it; otherwise, it creates a new storage box.
The view’s body runs, reading count via wrappedValue.
If you change count, SwiftUI updates storage and schedules the body to recompute.

A Toy Implementation of `@State`

SwiftUI is a closed-source Apple framework, but because property wrappers in Swift are a public language feature, we can only imagine and re-implement how @State could work.

Of course, the real @State is tightly integrated with SwiftUI’s runtime. But we can mimic the idea with an example property wrapper:

@propertyWrapper
public struct State<Value>: DynamicProperty {
    private var storage: StateStorage<Value>

    public init(wrappedValue: Value) {
        self.storage = .init(initialValue: wrappedValue)
    }

    public var wrappedValue: Value {
        get { storage.value }
        nonmutating set { storage.value = newValue }
    }

    public var projectedValue: Binding<Value> {
        Binding(
            get: { self.wrappedValue },
            set: { self.wrappedValue = $0 }
        )
    }
}

This obviously doesn’t persist across view recreations, but it shows the principle:

wrappedValue gives you the value.
Mutating it triggers a refresh.
$property gives you a Binding.

The above example is inspired from the State property wrapper implementation in OpenSwiftUI project here

What’s DynamicProperty Doing Here?

In SwiftUI, some property wrappers (like @State, @ObservedObject, @EnvironmentObject, @AppStorage, etc.) conform to the DynamicProperty protocol.

public protocol DynamicProperty {
    mutating func update()
}

This protocol lets SwiftUI know:

This property participates in the SwiftUI data flow.
- SwiftUI calls update() before recomputing the view’s body.
- That’s how the property wrapper gets a chance to reconnect to the right storage or refresh its bindings.
Why it matters for @State:
- Every time SwiftUI re-renders a view, a new struct instance of your view is created.
- Without DynamicProperty, the State wrapper would just get re-initialized, losing its data.
- With DynamicProperty, SwiftUI ensures the wrapper reattaches to its persistent state storage instead of resetting.

Understanding how @State works demystifies a lot of SwiftUI. It’s not magic — it’s just clever indirection and lifecycle management. By keeping state outside the view struct, SwiftUI ensures your UI is always a pure function of its data, while your data itself remains persistent.

So the next time you write @State var count = 0, remember: you’re really just getting a little persistent box managed by SwiftUI, with automatic UI updates wired in.

References

1) Opensource implementation of SwiftUI - https://github.com/OpenSwiftUIProject/OpenSwiftUI
2) https://forums.swift.org/t/how-does-swiftui-find-state-properties-in-views/79984/3
3) https://fatbobman.com/en/posts/swiftui-state/

iOS Engineering Excellence Series: Part 1 - Mastering State Management

Karthik Pala — Mon, 04 Aug 2025 19:16:46 +0000

As mobile applications have evolved from simple utilities to complex, business-critical platforms serving millions of users, the challenges of iOS development have grown exponentially. Having worked on large-scale mobile applications, I've witnessed firsthand how complexity multiplies when you're building for millions of users with distributed teams of dozens of engineers.

Unlike backend systems where you can roll back deployments instantly, mobile apps present a fundamentally different paradigm. Once users download a version with a bug, they're stuck with it until they update—and some never will.

Over the next few posts in this series, I'll share lessons I've learned about mobile engineering excellence. We're starting with state management because, frankly, it's where everything either falls apart or comes together. Get this right, and the rest of your app architecture has a fighting chance. Get it wrong, and you'll spend more time debugging than building.

Understanding the State Management Challenge

The iOS app lifecycle creates unique state management challenges that don't exist in other development environments. An iOS app transitions through five distinct states: not running, inactive, active, background, and suspended. Each transition can occur unpredictably due to system memory pressure, user actions, or OS-initiated termination.

The complexity arises because:

Events drive state changes asynchronously - network responses, user input, and system events can combine in unexpected ways
Memory warnings can occur at any time, forcing apps to release resources while maintaining state consistency
Background/foreground transitions require careful state preservation and restoration
The OS can terminate apps without warning, making state corruption a real threat

What Goes Wrong: The Pitfalls of Traditional Approaches

Before diving into solutions, let's examine what happens when iOS apps grow without proper state management patterns. These examples show real problems many have encountered in production apps.

Problem 1: The Scattered State

// Anti-pattern: State scattered across multiple objects
class UserProfileViewController: UIViewController {
    @IBOutlet weak var nameLabel: UILabel!
    @IBOutlet weak var avatarImageView: UIImageView!
    @IBOutlet weak var loadingIndicator: UIActivityIndicatorView!

    var user: User?
    var isLoading = false
    var lastError: Error?

    override func viewDidLoad() {
        super.viewDidLoad()
        loadUserProfile()
    }

    func loadUserProfile() {
        isLoading = true
        loadingIndicator.startAnimating()

        UserService.shared.fetchProfile { [weak self] result in
            DispatchQueue.main.async {
                self?.isLoading = false
                self?.loadingIndicator.stopAnimating()

                switch result {
                case .success(let user):
                    self?.user = user
                    self?.updateUI()
                case .failure(let error):
                    self?.lastError = error
                    self?.showError()
                }
            }
        }
    }

    func updateUI() {
        nameLabel.text = user?.name
        // Load avatar image...
        UserService.shared.loadAvatar(for: user?.id) { [weak self] image in
            DispatchQueue.main.async {
                self?.avatarImageView.image = image
            }
        }
    }
}

// Meanwhile, in another part of the app...
class SettingsViewController: UIViewController {
    var user: User? // Different instance!

    @IBAction func updateNameTapped() {
        // User updates their name, but ProfileViewController doesn't know
        UserService.shared.updateName(newName) { [weak self] updatedUser in
            self?.user = updatedUser
            // ProfileViewController still shows old name! 😱
        }
    }
}

What goes wrong here?

Duplicate state: Multiple view controllers have their own user property
Synchronization hell: Changes in one place don't update others
Memory leaks: Weak references everywhere, easy to forget
Testing nightmare: Can't test business logic without UI

Problem 2: The Callback Pyramid of Doom

As features grow, you end up with deeply nested callbacks:

// Anti-pattern: Nested callbacks and complex state management
class DashboardViewController: UIViewController {
    var user: User?
    var notifications: [Notification] = []
    var recentActivity: [Activity] = []
    var isLoadingUser = false
    var isLoadingNotifications = false
    var isLoadingActivity = false

    func loadDashboardData() {
        isLoadingUser = true
        updateLoadingState()

        UserService.shared.fetchProfile { [weak self] userResult in
            DispatchQueue.main.async {
                self?.isLoadingUser = false

                switch userResult {
                case .success(let user):
                    self?.user = user
                    self?.updateUserUI()

                    // Now load notifications
                    self?.isLoadingNotifications = true
                    self?.updateLoadingState()

                    NotificationService.shared.fetch(for: user.id) { notificationResult in
                        DispatchQueue.main.async {
                            self?.isLoadingNotifications = false

                            switch notificationResult {
                            case .success(let notifications):
                                self?.notifications = notifications
                                self?.updateNotificationsUI()

                                // Now load activity
                                self?.isLoadingActivity = true
                                self?.updateLoadingState()

                                ActivityService.shared.fetchRecent(for: user.id) { activityResult in
                                    DispatchQueue.main.async {
                                        self?.isLoadingActivity = false
                                        self?.updateLoadingState()

                                        switch activityResult {
                                        case .success(let activities):
                                            self?.recentActivity = activities
                                            self?.updateActivityUI()
                                        case .failure:
                                            self?.showActivityError()
                                        }
                                    }
                                }
                            case .failure:
                                self?.showNotificationError()
                            }
                        }
                    }
                case .failure:
                    self?.showUserError()
                }

                self?.updateLoadingState()
            }
        }
    }

    func updateLoadingState() {
        let isLoading = isLoadingUser || isLoadingNotifications || isLoadingActivity
        // Update UI based on loading state... but which part is loading?
        // How do we show partial states?
    }
}

What goes wrong here?

Callback hell: Deeply nested, hard to read and debug
Error handling chaos: Different error states scattered throughout
Loading state confusion: Hard to track what's actually loading
Race conditions: What if the user triggers another load while this is running?

Problem 3: The Background/Foreground State Loss

iOS apps must handle backgrounding gracefully, but traditional approaches often fail:

// Anti-pattern: No lifecycle state management
class ShoppingCartViewController: UIViewController {
    var cartItems: [CartItem] = []
    var selectedShippingAddress: Address?
    var paymentMethod: PaymentMethod?

    // User spends 10 minutes adding items to cart
    // Phone call comes in -> app goes to background
    // iOS kills app due to memory pressure
    // User returns -> everything is gone!

    func addToCart(_ item: CartItem) {
        cartItems.append(item)
        updateCartUI()
        // No persistence - data lives only in memory
    }
}

What goes wrong here?

State volatility: Critical user data exists only in memory
Poor user experience: Users lose their work when app is killed
No state restoration: App restarts in initial state every time
Business impact: Lost sales due to empty carts

Problem 4: The Testing Impossibility

With scattered state, testing becomes nearly impossible:

// How do you unit test this?
class OrderViewController: UIViewController {
    @IBOutlet weak var totalLabel: UILabel!

    var cart: ShoppingCart?
    var shippingCost: Double = 0
    var taxRate: Double = 0.08

    func calculateTotal() {
        guard let cart = cart else { return }

        let subtotal = cart.items.reduce(0) { $0 + $1.price }
        let tax = subtotal * taxRate
        let total = subtotal + tax + shippingCost

        totalLabel.text = "$\(total)" // UI tightly coupled to logic!

        // How do you test this calculation without UILabel?
        // How do you test different tax rates?
        // How do you test error cases?
    }
}

What goes wrong here?

UI coupling: Business logic mixed with UI code
Hard to test: Need full UI setup to test simple calculations
Brittle tests: Tests break when UI changes
Poor coverage: Complex scenarios impossible to test

The Real-World Impact

These patterns seem harmless in small apps, but they compound exponentially

The Reactive Programming Solution

Why Reactive Patterns Work for iOS

Reactive programming addresses iOS state management complexity by enforcing unidirectional data flow and immutable state updates. This approach makes state changes predictable and easier to debug.

The key principles are:

Single source of truth - State lives in one place
State is read-only - Views can't directly mutate state
Changes happen through actions - All mutations are explicit and traceable
Updates are pure functions - Same input always produces same output

Implementation Approaches

1. SwiftUI with Combine Framework

Best for: Complex data streams, real-time updates, and reactive UI patterns

Reference: Combine Framework Documentation

2. The Composable Architecture (TCA)

Best for: Large-scale apps requiring predictable state management and comprehensive testing

Referense:

3. Async/Await with Observable (iOS 17+)

Best for: New projects targeting iOS 17+ with simpler state management needs

Solving the Real Problems: Before & After

Let's see how reactive programming solves each of the problems we identified:

Solution 1: Single Source of Truth for User Data

Problem: User data scattered across multiple view controllers, leading to synchronization issues.

Reactive Solution:

// Single source of truth using Combine
import Combine

class UserStore: ObservableObject {
    @Published private(set) var user: User?
    @Published private(set) var isLoading = false
    @Published private(set) var error: String?

    private var cancellables = Set<AnyCancellable>()
    private let userService: UserService

    init(userService: UserService = UserService.shared) {
        self.userService = userService
    }

    func loadProfile() {
        isLoading = true
        error = nil

        userService.fetchProfile()
            .receive(on: DispatchQueue.main)
            .sink(
                receiveCompletion: { [weak self] completion in
                    self?.isLoading = false
                    if case .failure(let error) = completion {
                        self?.error = error.localizedDescription
                    }
                },
                receiveValue: { [weak self] user in
                    self?.user = user
                }
            )
            .store(in: &cancellables)
    }

    func updateName(_ newName: String) {
        guard var currentUser = user else { return }

        userService.updateName(newName)
            .receive(on: DispatchQueue.main)
            .sink(
                receiveCompletion: { [weak self] completion in
                    if case .failure(let error) = completion {
                        self?.error = error.localizedDescription
                    }
                },
                receiveValue: { [weak self] updatedUser in
                    self?.user = updatedUser
                    // ALL views automatically update! ✨
                }
            )
            .store(in: &cancellables)
    }
}

// Views automatically stay in sync
struct ProfileView: View {
    @StateObject private var userStore = UserStore()

    var body: some View {
        VStack {
            if let user = userStore.user {
                Text(user.name) // Always up-to-date
                AsyncImage(url: user.avatarURL)
            }
        }
        .onAppear {
            userStore.loadProfile()
        }
    }
}

struct SettingsView: View {
    @StateObject private var userStore = UserStore() // Same data!
    @State private var newName = ""

    var body: some View {
        VStack {
            TextField("Name", text: $newName)
            Button("Update") {
                userStore.updateName(newName)
                // ProfileView updates automatically! ✨
            }
        }
    }
}

What's fixed:

Single source of truth: User data lives in one store
Automatic synchronization: All views update when data changes
No memory leaks: Combine handles subscription cleanup
Testable: Business logic separated from UI

Solution 2: Eliminating Callback Hell with Async Streams

Problem: Deeply nested callbacks making code unreadable and error-prone.

Reactive Solution:

// Clean async/await with reactive state
class DashboardStore: ObservableObject {
    @Published private(set) var user: User?
    @Published private(set) var notifications: [Notification] = []
    @Published private(set) var recentActivity: [Activity] = []
    @Published private(set) var loadingState = LoadingState.idle

    enum LoadingState {
        case idle
        case loadingUser
        case loadingNotifications  
        case loadingActivity
        case loadingComplete
    }

    @MainActor
    func loadDashboardData() async {
        do {
            // Sequential loading with clear state updates
            loadingState = .loadingUser
            let user = try await UserService.shared.fetchProfile()
            self.user = user

            loadingState = .loadingNotifications
            let notifications = try await NotificationService.shared.fetch(for: user.id)
            self.notifications = notifications

            loadingState = .loadingActivity
            let activities = try await ActivityService.shared.fetchRecent(for: user.id)
            self.recentActivity = activities

            loadingState = .loadingComplete

        } catch {
            // Centralized error handling
            handleError(error)
        }
    }

    // Or parallel loading for better performance
    @MainActor
    func loadDashboardDataInParallel() async {
        loadingState = .loadingUser

        do {
            let user = try await UserService.shared.fetchProfile()
            self.user = user

            // Load other data in parallel
            async let notificationsTask = NotificationService.shared.fetch(for: user.id)
            async let activitiesTask = ActivityService.shared.fetchRecent(for: user.id)

            loadingState = .loadingNotifications
            self.notifications = try await notificationsTask

            loadingState = .loadingActivity  
            self.recentActivity = try await activitiesTask

            loadingState = .loadingComplete

        } catch {
            handleError(error)
        }
    }

    private func handleError(_ error: Error) {
        loadingState = .idle
        // Handle error state...
    }
}

struct DashboardView: View {
    @StateObject private var store = DashboardStore()

    var body: some View {
        VStack {
            switch store.loadingState {
            case .idle:
                Button("Load Dashboard") {
                    Task { await store.loadDashboardData() }
                }
            case .loadingUser:
                ProgressView("Loading profile...")
            case .loadingNotifications:  
                ProgressView("Loading notifications...")
            case .loadingActivity:
                ProgressView("Loading activity...")
            case .loadingComplete:
                DashboardContentView(
                    user: store.user,
                    notifications: store.notifications,
                    activities: store.recentActivity
                )
            }
        }
        .task {
            await store.loadDashboardDataInParallel()
        }
    }
}

What's fixed:

No callback hell: Linear async/await code
Clear loading states: Users know exactly what's happening
Centralized error handling: One place to handle all errors
Race condition safety: State updates are sequential and predictable

Solution 3: Bulletproof State Persistence

Problem: State loss during background/foreground transitions.

Reactive Solution:

// Automatic state persistence with lifecycle awareness
class ShoppingCartStore: ObservableObject {
    @Published private(set) var cartItems: [CartItem] = []
    @Published private(set) var selectedShippingAddress: Address?
    @Published private(set) var paymentMethod: PaymentMethod?

    private let persistenceManager = StatePersistenceManager()

    init() {
        loadPersistedState()
        setupLifecycleObservers()
    }

    private func setupLifeCycleObservers() {
        NotificationCenter.default.addObserver(
            forName: UIApplication.willResignActiveNotification,
            object: nil,
            queue: .main
        ) { [weak self] _ in
            self?.persistState()
        }
    }

    private func loadPersistedState() {
        if let savedCart: ShoppingCartState = persistenceManager.load("shopping_cart") {
            cartItems = savedCart.items
            selectedShippingAddress = savedCart.shippingAddress
            paymentMethod = savedCart.paymentMethod
        }
    }

    private func persistState() {
        let cartState = ShoppingCartState(
            items: cartItems,
            shippingAddress: selectedShippingAddress,
            paymentMethod: paymentMethod
        )
        persistenceManager.save(cartState, key: "shopping_cart")
    }

    func addToCart(_ item: CartItem) {
        cartItems.append(item)
        // Auto-persist on every change
        persistState()
    }

    func removeFromCart(_ item: CartItem) {
        cartItems.removeAll { $0.id == item.id }
        persistState()
    }

    func updateShippingAddress(_ address: Address) {
        selectedShippingAddress = address
        persistState()
    }
}

// Modern SwiftUI approach with scene phase
struct ShoppingCartView: View {
    @StateObject private var cartStore = ShoppingCartStore()
    @Environment(\.scenePhase) private var scenePhase

    var body: some View {
        // Cart UI...
        .onChange(of: scenePhase) { oldPhase, newPhase in
            if newPhase == .background {
                // State is automatically saved
            }
        }
    }
}

What's fixed:

Automatic persistence: State saves on every important change
Seamless restoration: App resumes exactly where user left off
No data loss: User work is always preserved
Lifecycle awareness: Hooks into iOS app lifecycle properly

Solution 5: Testable Business Logic

Problem: Business logic tightly coupled to UI, making testing impossible.

Reactive Solution:

// Pure, testable business logic
struct OrderCalculator {
    static func calculateTotal(
        items: [CartItem],
        shippingCost: Double,
        taxRate: Double
    ) -> OrderTotal {
        let subtotal = items.reduce(0) { $0 + ($1.price * Double($1.quantity)) }
        let tax = subtotal * taxRate
        let total = subtotal + tax + shippingCost

        return OrderTotal(
            subtotal: subtotal,
            tax: tax,
            shipping: shippingCost,
            total: total
        )
    }
}

class OrderStore: ObservableObject {
    @Published private(set) var cart: ShoppingCart = ShoppingCart()
    @Published private(set) var orderTotal: OrderTotal?
    @Published private(set) var taxRate: Double = 0.08
    @Published private(set) var shippingCost: Double = 0

    func calculateTotal() {
        orderTotal = OrderCalculator.calculateTotal(
            items: cart.items,
            shippingCost: shippingCost,
            taxRate: taxRate
        )
    }

    func updateTaxRate(_ rate: Double) {
        taxRate = rate
        calculateTotal()
    }
}

// Easy to test!
class OrderCalculatorTests: XCTestCase {
    func testTotalCalculation() {
        // Given
        let items = [
            CartItem(price: 10.0, quantity: 2),
            CartItem(price: 5.0, quantity: 1)
        ]
        let shippingCost = 3.99
        let taxRate = 0.08

        // When
        let total = OrderCalculator.calculateTotal(
            items: items,
            shippingCost: shippingCost,
            taxRate: taxRate
        )

        // Then
        XCTAssertEqual(total.subtotal, 25.0)
        XCTAssertEqual(total.tax, 2.0)
        XCTAssertEqual(total.shipping, 3.99)
        XCTAssertEqual(total.total, 30.99)
    }

    func testEmptyCart() {
        let total = OrderCalculator.calculateTotal(
            items: [],
            shippingCost: 5.0,
            taxRate: 0.08
        )

        XCTAssertEqual(total.total, 5.0) // Only shipping
    }
}

What's fixed:

Pure functions: Easy to test, no side effects
UI decoupling: Business logic separate from views
Comprehensive testing: Can test all scenarios easily
Reliable refactoring: Tests catch regressions

Performance Best Practices

Memory Management

Minimize state size: Store only essential data, compute derived values
Use lazy loading: Load data when needed, not upfront
Clear caches: Respond to memory warnings by freeing non-critical data

Update Optimization

// Avoid: Creating new state objects frequently
func updateUser(_ user: User) {
    state = AppState(
        users: state.users.map { $0.id == user.id ? user : $0 },
        // ... copying all other properties
    )
}

// Better: Use copy-on-write semantics
struct AppState {
    private var _users: [User] = []

    var users: [User] {
        get { _users }
        set { _users = newValue }
    }

    mutating func updateUser(_ user: User) {
        if let index = _users.firstIndex(where: { $0.id == user.id }) {
            _users[index] = user
        }
    }
}

Batch Updates

// Batch related state changes to prevent excessive re-renders
func loadUserData() async {
    // Single state update instead of multiple
    let (profile, preferences, notifications) = await loadUserDataBundle()

    updateState { state in
        var newState = state
        newState.profile = profile
        newState.preferences = preferences  
        newState.notifications = notifications
        return newState
    }
}

Key Takeaways

State management is the foundation of maintainable iOS apps. Whether you choose Combine, TCA, or @observable, the principles remain the same:

Unidirectional data flow prevents state chaos and makes debugging predictable
Immutable updates ensure state changes are traceable and testable
Lifecycle awareness prevents data loss during app transitions
Comprehensive testing catches state-related bugs before users encounter them
Performance optimization keeps your app responsive as state complexity grows

Remember: The best architecture is the one your team can understand, maintain, and evolve. Start with the simplest approach that meets your needs, then evolve as complexity grows.

The measure of good architecture isn't how clever it is, but how easy it makes the common tasks and how gracefully it handles the edge cases.

Note: The code samples here are generated with help of AI and may not be production ready, They are added to showcase how we can help solve the state management problems

Tags: #ios #swift #architecture #statemanagement #swiftui #combine #mobileengineering

Simplified and No-code UI Automation with Xcode 26

Karthik Pala — Tue, 01 Jul 2025 13:28:42 +0000

Automating the Automation??

If you've ever written UI tests with XCUI, you've probably struggled with locating elements using accessibility identifiers, labels, or even element paths. It's tedious, repetitive, and easy to break.

Well, good news: with Xcode 26, Apple is making this process significantly easier.

UI tests are now so tightly integrated into Xcode that you can practically use it as a no-code test builder. Just hit Record, interact with your app, and Xcode automatically writes the test code for you.
Of course, you still have full control to modify the test as needed - because at the end of the day, it's still updating your XCTestCase file.

First Things First - Accessibility Is Key

⚠️ Before we go any further, let this sink in: ⚠️

Accessibility isn't just for users - it's essential for automation.
If you're serious about automation, investing in proper accessibility setup is not optional!!

Xcode relies on accessibility APIs to identify and interact with UI elements during tests. And according to Apple (not just me 😄), this is the most reliable way to interact with elements in your UI tests.

A key tool here is the accessibilityIdentifier, which acts as a unique key for automation.

For example, in SwiftUI you can simply add:
.accessibilityIdentifier("usernameTextField")

💡 Tip: Use the Accessibility Inspector in Xcode to audit and debug your UI elements.

So What's new? - We are recording test flows now!

The demo from WWDC25 showcasing the recording tool was super slick.

You start by creating a new UI Test target, then hit Record, and perform your actions in the app - just like a user would. Xcode then auto-generates the corresponding XCTest code in real-time: tapping buttons, entering text, navigating screens etc.,

When you open your UI test case file, you'll see a Record button in the sidebar. Click it, start interacting with your app, and watch the test code get written automatically as you go.

The output is standard XCTest code, so you can always refine it manually. The example from the session showed editing a trip plan title and navigating to another screen. It captured everything - tap gestures, keyboard input, navigation.

This approach is much faster than writing tests from scratch and ensures the automation reflects real user behavior.

Reviewing Failures Visually

One of the best parts of this update is the test result viewer. If a UI test fails, you can:

Watch a video recording of the test run, with touch interactions shown.

Jump to the exact step where it failed using the timeline.
See element overlays, showing what Xcode was trying to tap or assert.
Compare actual vs expected metadata.

This kind of context-rich feedback makes debugging UI tests a lot more approachable. No more guesswork - you can see what went wrong.

Takeaways & Tips

Having tried this in Xcode 26, my first impressions are really positive:

It works great - if you've defined clear accessibility identifiers for all interactive elements - Add unique accessibilityIdentifiers and make elements reliably testable
Experience it yourself - Use the Recorder - Jumpstart test creation, especially for complex flows
Always review the generated code - it's not always perfect
Some limitations remain - for example, I tested selecting time in a picker, and the generated code didn't work out of the box

If you've been avoiding UI automation because it felt too fragile or time-consuming, now's a great time to revisit it. The improvements in Xcode 26 - especially around recording and reviewing tests - make it far more approachable.

I'm definitely planning to use this more in my own apps, especially to validate critical flows across locales and devices. If you haven't seen the session yet, I highly recommend watching it here.

Thanks for reading - and happy automating!

References

https://developer.apple.com/videos/play/wwdc2025/344/

Understanding Swift's Collection Protocols: A Deep Dive into Sequence, Collection, and Beyond

Karthik Pala — Sun, 15 Jun 2025 19:33:30 +0000

Introduction

The Swift programming language is known for its rich set of protocols that help define what behaviors are expected from a particular type. These protocols are not only powerful tools in building reusable and modular code, but they also provide certain guarantees about a type's characteristics and performance.Among the many protocols in Swift's standard library, a few stand out when it comes to collections.

In this post, we're going to break down four collection-related protocols in Swift, starting from the basics and building up to more advanced concepts. Whether you're new to Swift or just looking to refresh your understanding, let's explore how these protocols shape the behavior of collections.

1. Sequence

At the very base of the hierarchy lies the Sequence protocol.

A Sequence type in Swift provides sequential access to its elements. But there's an important catch: using sequential access may destructively consume the elements i.e. once you traverse a sequence, you may not be able to revisit those elements without regenerating them

This is often seen in lazy sequences or streams, where the data isn't stored all at once but generated or consumed on the fly.
When a type conforms to Sequence, it must implement:

func makeIterator() -> Iterator

A Real world example:
Suppose you're generating fibonacci numbers - you don't have all the elements up front, and you don't want to store them in memory. You just want to yield one number item at a time.
The below code defines a lazy, infinite Fibonacci number generator using the Sequence protocol.

struct Fibonacci: Sequence {
    func makeIterator() -> some IteratorProtocol {
        var a = 0, b = 1
        // AnyIterator lets us define quick inline iterators
        return AnyIterator {
            defer { (a, b) = (b, a + b) }
            return a
        }
    }
}

let fibonacciSequence = Fibonacci().prefix(10)
// prefix 10 prevents the infinite loop while consuming the sequence
for num in fibonacciSequence {
    print(num)
}
// Prints - 0 1 1 2 3 5 8 13 21 34

Key takeaway:

Sequence provides simple, one-way, sequential access to elements, but accessing them is potentially destructive
It may not be rewindable (can only be used once)
It's optimized for streaming/one-pass access
It's minimal - you only implement iteration logic

2. Collection: Repeated, Non-Destructive Access

Moving up a tier, we have the Collection protocol.

A Collection is a finite sequence of elements, and one of the key differences between a collection and a basic sequence is that a collection allows for repeated, non-destructive access. This means you can revisit the elements multiple times without losing access to them

If you think of a Sequence as a movie that you can only watch once, a Collection is more like a DVD or streaming service where you can watch the movie over and over again. It's guaranteed to be finite, meaning the collection will have a defined, known number of elements, and it supports safe, repeated access without any side effects. Collection inherits from Sequence, so you also get for-in, map, filter, etc.

A type that conforms to the Collection protocol must:

Be multi-pass (can be iterated more than once)
Provide startIndex and endIndex
Provide subscript access by index
Advance through the collection using index(after:)

A Real world example:
A simple example which stores words from a sentence which conforms to Collection

// To keep the example simple, we are using a simple array as 
// storage under the hood.
struct ReadOnlyWords: Collection {
    private let words: [String]

    init(text: String) {
        self.words = text.split(separator: " ").map(String.init)
    }

    // MARK: - Collection protocol confirmance

    var startIndex: Int { words.startIndex }
    var endIndex: Int { words.endIndex }

    subscript(index: Int) -> String {
        words[index]
    }

    func index(after i: Int) -> Int {
        words.index(after: i)
    }

    // makeIterator() is synthesized automatically based on above properties
}

let words = ReadOnlyWords(text: "hello from swift collections")

for word in words {
    print(word)
}
// Prints
// hello
// from 
// swift
// collections

Key takeaway:

Collection is a more powerful type than Sequence, offering multiple non-destructive accesses to its elements and guaranteeing that the collection is finite.
Provides only forward iteration

3. BidirectionalCollection: Going Both Ways

Next up is the BidirectionalCollection protocol.

BidirectionalCollection protocol enables the ability to traverse a Collection both forwards and backwards.

A BidirectionalCollection guarantees that you can start at the front of the collection, move towards the end, and then reverse direction to traverse back from the end to the start.

It extends Collection, and adds:

func index(before: Index) -> Index

A Real world example:
Imagine you're implementing a browser-like history stack where the user can - Go forward (next page), Go backward (previous page) and Iterate over visited pages
So we would expect:

Ordered, navigable collection of history
Ability to traverse forward/backward
Don't need random access (e.g., history[3] instantly)

struct HistoryEntry {
    let url: String
    let timestamp: Date
}

// To keep the example simple, we are using a simple array as 
// storage under the hood.
struct History: BidirectionalCollection {
    private let entries: [HistoryEntry]

    init(_ entries: [HistoryEntry]) {
        self.entries = entries
    }

    // MARK: - Collection
    typealias Index = Int
    typealias Element = HistoryEntry

    var startIndex: Int { entries.startIndex }
    var endIndex: Int { entries.endIndex }

    subscript(position: Int) -> HistoryEntry {
        entries[position]
    }

    func index(after i: Int) -> Int {
        entries.index(after: i)
    }

    // MARK: - Bidirectional
    func index(before i: Int) -> Int {
        entries.index(before: i)
    }
}

let logs = [
    HistoryEntry(url: "apple.com", timestamp: .now),
    HistoryEntry(url: "swift.org", timestamp: .now),
    HistoryEntry(url: "google.com", timestamp: .now)
]

let history = History(logs)

for page in history.reversed() {
    print("Visited: \(page.url)")
}

Key takeaway:

A BidirectionalCollection allows traversal in both directions, but not all collection types support this
For example, a singly linked list is a common data structure that cannot qualify as a BidirectionalCollection, since it only allows traversal from the head (beginning) to the tail (end), but not in reverse order

4.RandomAccessCollection: Constant Time Access

The final protocol we'll cover is RandomAccessCollection.

RandomAccessCollection protocol builds on top of the BidirectionalCollection, but adds an important guarantee: elements can be accessed in constant time, regardless of their position in the collection.

For a RandomAccessCollection, accessing an element at any index should take the same amount of time. This is crucial for certain performance-sensitive tasks, such as when working with arrays, where accessing the 5th element is just as fast as accessing the 1,000th element.
Conforming to RandomAccessCollection means you're promising:

subscript(index: Index) O(1)
distance(from:to:) O(1)
index(_:offsetBy:) O(1)

A Real world example:

struct Article {
    let title: String
    let content: String
}

struct ArticleFeed: RandomAccessCollection {
    // Internally stored as an array of preloaded articles
    private var pages: [[Article]]

    // Flattened view
    private var flattened: [Article] {
        pages.flatMap { $0 }
    }

    // MARK: - Collection Conformance
    typealias Index = Int
    typealias Element = Article

    var startIndex: Int { flattened.startIndex }
    var endIndex: Int { flattened.endIndex }

    subscript(position: Int) -> Article {
        flattened[position] // O(1) because we are using array here
    }

    func index(after i: Int) -> Int { i + 1 }
    func index(before i: Int) -> Int { i - 1 }

    // We don't need to implement index(_:offsetBy:) or distance(from:to:)
    // because Int already conforms to Strideable with O(1)
}

let page1 = [Article(title: "Blog notes", content: "..."),
             Article(title: "Collection notes", content: "...")]

let page2 = [Article(title: "Vacation Notes", content: "...")]

let feed = ArticleFeed(pages: [page1, page2])

print(feed[0].title) // Blog notes - Guaranteed O(1)
print(feed[2].title) // Vacation Notes - Guaranteed O(1)

Key takeaway:

RandomAccessCollection provides constant-time access to elements at any index, making it optimal for use cases where performance is critical.
The RandomAccessCollection protocol adds further constraints on the associated Indices and SubSequence types, but otherwise imposes no additional requirements over the BidirectionalCollection protocol.
To meet the complexity guarantees of a random-access collection, either the index for your custom type must conform to the Strideable protocol or you must implement the index(_:offsetBy:) and distance(from:to:) methods with O(1) efficiency

Conclusion:

Here's a time complexity comparison table for the protocols we've discussed

Note: subscript(index) in Collection and BidirectionalCollection must be documented as O(1). If it's not O(1), the implementor must explicitly warn about it.

DEV Community: Karthik Pala

Understanding `@State` in SwiftUI: How It Works Under the Hood

Why Do We Even Need @State?

What @State Really Is

Where Does the Value Live?

How Updates Trigger UI Refresh

@State and Binding

Lifecycle of a @State Property

A Toy Implementation of @State

What’s DynamicProperty Doing Here?

References

iOS Engineering Excellence Series: Part 1 - Mastering State Management

Understanding the State Management Challenge

What Goes Wrong: The Pitfalls of Traditional Approaches

Problem 1: The Scattered State

Problem 2: The Callback Pyramid of Doom

Problem 3: The Background/Foreground State Loss

Problem 4: The Testing Impossibility

The Real-World Impact

The Reactive Programming Solution

Why Reactive Patterns Work for iOS

Implementation Approaches

1. SwiftUI with Combine Framework

2. The Composable Architecture (TCA)

3. Async/Await with Observable (iOS 17+)

Solving the Real Problems: Before & After

Solution 1: Single Source of Truth for User Data

Solution 2: Eliminating Callback Hell with Async Streams

Solution 3: Bulletproof State Persistence

Solution 5: Testable Business Logic

Performance Best Practices

Memory Management

Update Optimization

Batch Updates

Key Takeaways

Simplified and No-code UI Automation with Xcode 26

Automating the Automation??

First Things First - Accessibility Is Key

So What's new? - We are recording test flows now!

Reviewing Failures Visually

Takeaways & Tips

References

Understanding Swift's Collection Protocols: A Deep Dive into Sequence, Collection, and Beyond

Introduction

1. Sequence

2. Collection: Repeated, Non-Destructive Access

3. BidirectionalCollection: Going Both Ways

4.RandomAccessCollection: Constant Time Access

Conclusion:

Why Do We Even Need `@State`?

What `@State` Really Is

`@State` and `Binding`

Lifecycle of a `@State` Property

A Toy Implementation of `@State`