Comments on: The Composable Architecture: How Architectural Design Decisions Influence Performance

By: Karin Prater

Karin Prater — Wed, 26 Mar 2025 09:40:04 +0000

In reply to TCAUser.

I appreciate your comment, but I think you might be misunderstanding how TCA’s architecture actually works under the hood.

Yes, TCA has scoping – but scoping doesn’t change the fundamental dependency flow in the architecture. Let me explain the difference:

What Actually Happens in TCA

1. Dependency Flow: The `Store` is indeed passed down through the entire view hierarchy as a dependency. Look at how views are structured in TCA:

struct RootView: View { let store: Store


    var body: some View {

        HomeView(store: store) // Passing the entire store down

    }

}
struct HomeView: View {

    let store: Store // Gets the ENTIRE store as a dependency
    var body: some View {

        WithViewStore(store, observe: { state in

            // Only observe the specific parts we need

            return state.userProfile

        }) { viewStore in

            Text("Hello, \(viewStore.name)")

            ProfileView(store: store) // Continues passing the entire store down

        }

    }

}
struct ProfileView: View {

    let store: Store // Again, the ENTIRE store

var body: some View { // More UI and potentially more views that receive the store } }

The store containing the entire global state is passed down through initializers at each level. This is not something I made up – it’s directly from TCA’s design and standard usage pattern.

2. ViewStore as an Optimization: The `WithViewStore` wrapper is precisely the workaround TCA introduced to deal with the performance problems of having the entire state available everywhere.

The confusion comes from conflating two different things:
– The actual dependency (the Store with full state that flows through initializers)
– The optimization layer (ViewStore that projects specific parts for SwiftUI updates)

Scoping Doesn’t Change the Dependency Flow

When you use `scope()` to create a child store:

let profileStore = store.scope( state: { $0.profile }, action: { AppAction.profile($0) } )

You’re creating a lens into the parent store. But the parent store (with the full state) still exists, and the child store is still connected to it. Actions sent to the child store flow back to the parent store and go through the entire reducer hierarchy.

The scoping is indeed “tricking” the view updating system. It’s an optimization layer on top of an architecture that fundamentally passes the entire state tree through the system.

Why This Matters

This distinction is important because the performance issues reported by many developers stem from this exact architectural decision. Even with scoping, TCA still:

1. Processes all actions through the entire reducer hierarchy
2. Maintains a single global state struct
3. Requires diffing the entire state to detect changes

Scoping helps with view updates, but it doesn’t change these fundamental aspects of the architecture that create performance bottlenecks at scale.

Not a Criticism, Just Architecture Analysis

This isn’t about criticizing TCA – it’s about understanding the trade-offs in its design. Every architecture makes trade-offs, and TCA prioritizes predictability and testability over raw performance. That’s a valid choice, but one developers should understand when adopting it.

By: Karin Prater

Karin Prater — Wed, 26 Mar 2025 09:28:19 +0000

In reply to NoNeed.

My personal preference is Vanilla Swiftui. Use MVVM with Reposiory pattern to separate out logic and get testing capabilities.
For larger more complex flows, Coordinators are greate because they can take care of the navigation logic. This allows you thinks like programmatic navigation, deep linking.
I prefer a simple approach when starting a project and then adapt and introduce more design patterns as the app grows.
These topics are quite vaste and I will for sure write and make videos about them (including more complex demo projects)

By: Manu

Manu — Tue, 25 Mar 2025 16:01:39 +0000

I’ve used TCA on a mid-to-large project, and I have found a lot of problems:
– Performance Issues
– When the compiler doesn’t understand something, the error is not meaningful
– I hate all the 3rd party dependencies that it introduces
– Developer learning curve is really long
– Additional compile time that adds up over time
– Not really straight forward rules (ie: when to share a reducer vs when to add a child reducer)
– Child reducers introduced a lot of extra complexity
In my experience, I’d never pick TCA again, I’d go with vanilla MVVM and only add complexity as needed

By: Andy W.

Andy W. — Tue, 25 Mar 2025 13:50:40 +0000

Good article, and ties in with my experience. I used TCA in a major project at a former employer, and on top of a significant—and constantly changing—learning curve, very little documentation from third parties, Point Free videos that spent far too long talking about *how* they built rather than how to *use* it, we hit major scaling issues with large state maxing out stack memory. This caused serious out of memory errors that we struggled to fix. What documentation there was, was contradictory, and the constant rewrites and alterations on ‘best practice’ made it hard to know what was the correct way to use it. Going forward, I have vowed never to work for a company using it again, as it felt like it was fighting SwiftUI and Apple standards, rather than working with them. Technically brilliant, but for all its good points we found one or more downsides that sucked up any speed advantage we gained.

By: Wow

Wow — Tue, 25 Mar 2025 13:10:25 +0000

Nice insights wow

By: NoNeed

NoNeed — Tue, 25 Mar 2025 13:09:11 +0000

Can you give us better architecture implementation?

By: Oliver

Oliver — Mon, 24 Mar 2025 17:29:59 +0000

A lot of this article is based on things that have long since been updated in TCA or things that just aren’t true and never have been.

It is never the case that the “entire app state” is passed to every view and every child view.

Not is it true that the state has to hold everything in it. It is quite common (and good practise) for views (reducers/state) to get state from dependencies. Whether that’s an in memory cache, or core data, or the network etc… it doesn’t need to be stored globally for the whole stack to access. TBF that was an initial misunderstanding I had when I first used TCA several years ago before I used TCA in anything more than a tutorial sized app.

By: TCAUser

TCAUser — Mon, 24 Mar 2025 15:06:07 +0000

Every view in your hierarchy, no matter how deeply nested, receives the entire application state struct. This is by design in TCA – it ensures every component has access to the full state.

that is so wrong have you heard of scoping ?

By: Fotis

Fotis — Mon, 24 Mar 2025 12:59:24 +0000

> Recent versions have introduced significant improvements like the new reducer protocol, and they’re actively working on Observation framework integration

The reducer protocol was announced in October 2022: https://www.pointfree.co/blog/posts/81-announcing-the-reducer-protocol and Observation in January 2024: https://www.pointfree.co/blog/posts/130-observation-comes-to-the-composable-architecture
WithViewStore has been deprecated since 1.7: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/withviewstore/