I've been sketching out a small Task Tracker app today, and I hit that familiar wall where my SwiftUI views are starting to feel... bloated. You know the feeling. I have @State variables for the task list, a @State for the text field, and then a bunch of functions inside the View that handle the business logic of adding a task or toggling a completion checkbox.

It works, sure. But the moment I want to add a feature—like syncing these tasks to a server—I realize my logic is trapped inside the View. If I want to test the "add task" logic, I have to instantiate a whole View. That's a red flag. I want a way to describe what happens in my app without tying it to how it's rendered.

The "Everything in the View" Struggle

Here is where I started. Just a basic view doing everything:

struct TaskListView: View {
    @State var tasks: [Task] = []
    @State var newTaskName: String = ""

    var body: some View {
        VStack {
            TextField("Task name", text: $newTaskName)
            Button("Add") {
                let task = Task(name: newTaskName)
                tasks.append(task)
                newTaskName = ""
            }
            List(tasks) { task in
                Text(task.name)
            }
        }
    }
}

It's clean for five minutes. But what happens when adding a task needs to trigger an API call? Or when I need to validate that the name isn't empty? My Button closure is going to turn into a 20-line monster. I need a way to separate the State (the data), the Actions (the things that can happen), and the Reducer (the logic that connects them).

Defining the Blueprint

This is where The Composable Architecture (TCA) comes in. Instead of letting the View mutate state directly, TCA forces us to be explicit. I'm going to stop writing View code and start by defining a "Feature."

First, I'll define my State and my Action. I'm thinking of these as the "Noun" and the "Verb" of my feature.

import ComposableArchitecture

@Reducer
struct TaskFeature {
    struct State: Equatable {
        var tasks: [Task] = []
        var newTaskName: String = ""
    }

    enum Action {
        case nameChanged(String)
        case addTask
        case toggleTask(id: UUID)
    }

    var body: some ReducerOf {
        Reduce { state, action in
            switch action {
            case let .nameChanged(name):
                state.newTaskName = name
                return .none
            case .addTask:
                guard !state.newTaskName.isEmpty else { return .none }
                state.tasks.append(Task(name: state.newTaskName))
                state.newTaskName = ""
                return .none
            case let .toggleTask(id):
                if let index = state.tasks.firstIndex(where: { $0.id == id }) {
                    state.tasks[index].isCompleted.toggle()
                }
                return .none
            }
        }
    }
}

I noticed something immediately: the Reduce block is just a big switch statement. It's boring, and that's actually the point. There's no magic here. If I want to know why a task was added, I just look for the .addTask case. It's completely decoupled from the UI.

Connecting the Store to the UI

Now, I can't just drop this into a View; I need a Store. The Store is the runtime that actually holds the state and runs the reducer. In my View, I'll use Store`s observer to keep the UI in sync.

I tried using @StateObject at first, but TCA provides a Store that integrates directly with SwiftUI via WithViewStore (or the newer @Bindable` / `ObservedObject` patterns depending on your TCA version). Let's look at the modern approach:

struct TaskListView: View {
    let store: StoreOf

    var body: some View {
        VStack {
            TextField("Task name", text: Binding(
                get: { store.newTaskName },
                set: { store.send(.nameChanged($0)) }
            ))
            
            Button("Add") {
                store.send(.addTask)
            }
            
            List(store.tasks) { task in
                Text(task.name)
            }
        }
    }
}

Wait, that Binding looks clunky. TCA actually gives us a way to "bind" state directly if we define it in the reducer. But for this overview, the key takeaway is store.send(.action). The View doesn't say "append this to the array"; it says "the user intended to add a task." The Reducer decides if that's actually allowed.

Handling the "Real World" (Effects)

But what about that API call I mentioned? In a standard SwiftUI app, I'd just throw an async call in the button. In TCA, we use Effect. If I want to save the task to a database, I don't do it in the reducer—because reducers must be "pure" (predictable and side-effect free).

I'll adjust my reducer to return an effect:

case .addTask:
    let task = Task(name: state.newTaskName)
    state.tasks.append(task)
    state.newTaskName = ""
    return .run { send in
        try await API.save(task)
        // I could send another action here if the save fails!
    }

Now I have a clear pipeline: View $\rightarrow$ Action $\rightarrow$ Reducer $\rightarrow$ Effect $\rightarrow$ Action. It feels like a loop. It's a bit more boilerplate up front, but I can now write a unit test for the TaskFeature without ever launching a simulator. I can just send actions to the store and assert that the state changed as expected.

📋 Practical Task

Implement a Task Deletion Action in TCA

You have been handed a Task Tracker project using The Composable Architecture. The app currently allows users to add and toggle tasks, but it is missing the ability to delete them. Your goal is to implement the deletion flow following the TCA pattern.

Requirements:

• The Action: Add a new case to the Action enum in the TaskFeature reducer called deleteTask(id: UUID).
• The Logic: Update the Reduce block to handle .deleteTask. It should find the task with the matching ID in the state.tasks array and remove it.
• The View: Update the List in the View to include a Button (or use .onDelete) that calls store.send(.deleteTask(id: task.id)).

Ensure that the state is mutated correctly within the reducer and that the View remains a "dumb" layer that only sends actions.