Overall I am still left searching for a solution to drive UI tests in CI/CD environment.

Is there a way to add a shadow to a List? I used the .plain style because I don’t want any spaces between the sections

thanks

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 {
// 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.

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)