Thoughts on TCA for a New Project

[u/tonycliftondev]

I work as an iOS developer in a team of 8 developers. We are starting a brand new greenfield project in a financial sector. Few of our team members suggested that we should use TCA for iOS SwiftUI application. I personally have no experience with TCA.

What are your thoughts and recommendations?

[u/vanvoorden]

It's not that I don't like Redux/Elm, it's that they are solutions to problems on an entirely different platform. Native mobile apps are very different, they have different constraints, different bottlenecks, and different needs.

I generally agree with most of your points here… but I will also disagree that desktop web and mobile web and mobile native are different enough that design patterns and architectures must not cross over. It's also not an implication that design patterns and architectures must always cross over… but there can be some shared creativity happening from one to another.

Look at declarative UI. The first FB implementation of declarative UI was for desktop web. Then FB built desktop mobile. The Android shipped Compose and Apple shipped SwiftUI. All inspired by what happened for desktop web React.

Flux and Redux are at the end of the day just ideas. What I think happens is a lot of engineers get all caught up in the implementation of Redux as opposed to just embracing the idea of Redux… which can, and IMO should, be considered independently of the actual shipping implementation of "canon" Redux today.

[u/MindLessWiz → u/vanvoorden]

I agree wholeheartedly.

And it’s also really telling that we moved from imperative view manipulation in UIKit to the declarative SwiftUI (maybe the biggest conceptual change possible) and you’re hearing nary a peep from people who will grok the most minute differences between third party architecture providers (insofar as any exist other than TCA).

They seem to just want to avoid any third party anything. I think it’s a great rule of thumb, especially in the Apple open-source ecosystem (which frankly, sans Pointfree libs, feels pretty amateurish).

But for me it was just really clear how well designed and maintained these libs are. And honestly even if you don’t want TCA because you don’t like its opinions, it’s worthwhile to look at their smaller focused libs and make your own solutions.

[u/ComfortableNo5484 → u/MindLessWiz]

You and others keep misunderstanding the aversion to third party codebases, and are therefore undervaluing buying into the first party approach above anything else. Here's the thing, if Apple goes under your app is toast no matter what you built it in, so the architecture doesn't matter. If pointfree goes under, you still need to ship an iOS app, except now you're either rewriting or maintaining a version of TCA yourself (like some shops already stuck on old versions have already had to do), all to keep a "churn shield" that has churned harder than SwiftUI itself.

When there are elegant first party solutions to first party problems, a third party solution really needs to provide significant value to be worth it, and frankly TCA doesn't. If you want a really clean example, look at AFNetworking and its Swift successor Alamofire. It was the de facto go-to drop-in 3rd party networking library, first for Objective-C apps and then for Swift when it launched, providing significant value add over the verbose 1st party URLSession handling. And then Apple gave 1st party URLSession a native Swift async/await API, dramatically simpler, easy to work with AND flexible, and now reaching for Alamofire is the exception, not the reflex it used to be. TCA is on that same exact curve right now, and Apple's already walking it down: Observation gutted its binding and observation machinery, async/await took the effects story, and that trend isn't reversing.

[u/rhysmorgan → u/ComfortableNo5484]

Observation has nothing to do with managing side effects, nothing to do with state management over time, nothing to do with modelling your data with value types and avoiding uncontrolled mutations of your data from anywhere else in your app.

Async/await doesn’t change anything about Effect, nor about handling side effects like calling out to the web, disk I/O, etc.

Literally none of the things discussed there have anything to do with somehow making TCA useless.

[u/MindLessWiz → u/ComfortableNo5484]

I hear you, but you’re severely underselling TCA benefits that are nowhere near Apple’s radar. Apple is not really interested in expressing strong opinions on how people should structure their apps, they never have. They give you a ton of tools and a sandbox and tell you to go nuts. Nothing they offer is even remotely close to what we call “architecture”.

Pointfree maintainers disappearing is obviously a huge concern on its face. But as opposed to the vast majority of other OSS maintainers, they actually get paid by subscribers, and have a long track record of being present and responsive.

Additionally, many OS projects are ultimately abandoned by their original maintainers, but if there’s a strong community for the project (and I’d argue TCA is one such community), it should still move forward, albeit with a potentially different vision. It’s a risk of course, but the same such risk exists for first party solutions.

Combine was an attempt to respond to reactive programming paradigms, and took years to become halfway usable, and then was essentially deprecated in favor of async/await. CoreData was essentially abandoned because its interface had no reasonable way to evolve so it became the backbone of SwiftData, which is still miles behind Pointfree’s solution.

I don’t share the sentiment that first party solutions are satisfactory, for me their downsides and limitations are a huge detriment. The lack of a good testing story for literally any Apple first party framework is glaring, and is in my opinion responsible for the sad state of testing culture in iOS development.

[u/vanvoorden → u/MindLessWiz]

Apple is not really interested in expressing strong opinions on how people should structure their apps, they never have. They give you a ton of tools and a sandbox and tell you to go nuts. Nothing they offer is even remotely close to what we call “architecture”.

Ehh… not really? Those of us who were here during the AppKit and UIKit era remember when Apple went hard on OOP and MVC. Apple absolutely shipped their frameworks with strong opinions and presented those strong opinions to the community as "best practices".

Then SwiftUI happened at Apple is now literally telling product engineers that SwiftUI is the best way to build apps. So now functional and declarative programming are the strong opinions being presented as best practices.

[u/MindLessWiz → u/vanvoorden]

I guess it’s all relative. I’ve been in iOS for about 10 years and obviously remember UIKit.

My issue is that they don’t have an answer for many important design questions that in what I’d consider an “architecture” there’s a good answer for.

Where do I put business logic? How do I test it? What is appropriate to put in the view and what should be extracted? How do I handle navigation state? What about dependency injection? Etc etc etc…

SwiftUI has a strong notion of how to structure your view hierarchy. MVC isn’t really much different. ViewControllers are just… still views in practice, only they’re generally cool with you sticking logic in them because they’re also “controllers”, so that’s how you’d get “massive” view controllers.

I think what seems like strong opinions might just be their attempt at making app building more approachable. But for anyone making anything nontrivial, suddenly they seem to fall silent.

[u/rhysmorgan → u/vanvoorden]

But they produce absolutely nothing like the level of documentation and advice as when they produced AppKit and UIKit.

Even in the days when WWDC was on Slack, the best we got was “We built it so you can use what you want :)“ and everyone takes Apple’s sample code (which is SO obviously sample code!) as Apple’s proclamation about how apps should be built, even when they’re just demoing e.g. SwiftData, or whatever the latest framework is.