TCA in 2025

[hatfinch]

I subscribed to PointFree in 2023, and at the time watched enough of the back catalogue to get an idea of what TCA was all about; but I have never actually used it "in anger".

I am now considering it for a new app. But is it still quite so relevant, in light of modern Observation from Apple?

It feels to me like if I use swift-dependencies, swift-sharing, swift-snapshot-testing etc., to help me keep business logic out of my Views and maintain good testability, I might get 90% of the way to what TCA promises, without the learning and performance overheads.

Perhaps I get that impression because there haven't been any videos focusing on it lately. For those who are using it -- is it providing just as much benefit over modern Observation as it did over the legacy stuff?

[mbrandonw]

Hi @hatfinch, a few responses to your questions below:

I am now considering it for a new app. But is it still quite so relevant, in light of modern Observation from Apple?

I don't think Swift's observation tools have much bearing on the relevance of TCA. Observation provides some really nice ergonomics around accessing state in views (for both vanilla SwiftUI and TCA), but that was never a stated goal for TCA. So, while we are very happy that the Observation framework exists, and we did a lot of work to integrate it into TCA, its existence wouldn't be the deciding factor of whether or not one uses TCA.

It feels to me like if I use swift-dependencies, swift-sharing, swift-snapshot-testing etc., to help me keep business logic out of my Views and maintain good testability, I might get 90% of the way to what TCA promises, without the learning and performance overheads.

We've never claimed that TCA is the only way to build apps, and it's why we spend a significant amount of time building out an entire constellation of libraries that solve various problems. It is worth mentioning that every single one of those libraries (dependencies, sharing, case paths, navigation, identified collections, custom dump, etc...) were first incubated in TCA and then later split from it.

But, whether or not those tools get you ~90% of the way is hard to say. It really depends on what kind of guarantees you want from your codebase as it evolves over time. Perhaps the biggest selling point of TCA is its testing tools. Because state is modeled in value types you get a very simple set of APIs to assert on how state changes over time. If you don't assert on everything that changed in the state you will get a failure, and there are even ways to tweak how exhaustive your tests must be. Further, your tests must also assert on how effects are run and how they feed data back into the system. It is a failure to have an effect continuing to run by the time the test ends, and it is a failure to have an effect emit data into the system without asserting on it.

On the flip side, testing an @Observable model is often very difficult, and sometimes just actually impossible. Due to how Swift concurrency works today, it is simply not possible to assert on the state of your feature between each suspension point. You can use copious amounts of Task.sleeps to wiggle yourself in between many of them, but some will just be unreachable.

And while testing was a major focus of the library, there are many non-testing benefits that come from the choices we made to enhance testing. For example, the separation of synchronous logic in a feature (the mutations in a reducer) from the asynchronous behavior in a feature (everything in Effect.run { … }) allows one to avoid a whole slew of interleaving and reentrance problems that one encounters in Swift concurrency today. And on top of that, you get to deeply test the intricacies of how synchronous and asynchronous work is executed.

Another example of this is debugging tools of TCA. With one application of _printChanges() to the reducer at the root of your app you get instant visibility into every event in your application as well as how that event mutates the state of your application. You get this tool for free without doing any extra work.

Perhaps I get that impression because there haven't been any videos focusing on it lately.

We are actively working on TCA on many fronts. For one, all of the Sharing and SharingGRDB tools were built to work in vanilla SwiftUI, but were born out of the need for these tools in TCA. We consider our continuing work on those libraries an extension of TCA as we make sure that each evolution of the tools still plays nicely with the core tenets of TCA. And further, we are working towards a TCA 2.0 that will solve a lot of problems that we struggle with right now.

[hatfinch]

Thank you for your comprehensive reply, Brandon. I clearly need to go back and re-watch more series about TCA. For instance, I had forgotten about the exhaustivity guarantees for state changes. I look forward to hearing about TCA 2.0 in due course!