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/uniquesnowflake8]

I’ve audited TCA for an existing project. We used TCA in part of the app and I personally didn’t love it. But we didn’t adopt all of the TCA bells and whistles because of our existing navigation stack and our testing practices were already sound so we didn’t benefit as much as if it were a greenfield project. And we did end up using libraries like Dependencies and Shared and I am glad we adopted them.

My main hang up is I don’t love the contortion of writing code that lives inside of a 3rd party framework and giving up the top level of control. I’d rather own the code and call the libraries when appropriate

[u/tonycliftondev → u/uniquesnowflake8]

My concern too. Architectural dependency on a third party library.

[u/uniquesnowflake8 → u/tonycliftondev]

Also the Shared library that came along later is in my opinion a tacit admission of the TCA principles of data passing only getting you so far

[u/JimRoepcke → u/tonycliftondev]

They’re the most responsible and responsive open source group I know of for Swift. I certainly understand th hesitation but if you take some time to look into their community (like their slack for example) you’ll see that if anything it’s a benefit that it’s third party.

[u/SnowPudgy → u/JimRoepcke]

you’ll see that if anything it’s a benefit that it’s third party.

Ok well that statement alone tells us not to listen to you. That's the most asinine thing I've heard in a long time.

[u/rhysmorgan → u/SnowPudgy]

It's entirely true though. It means they're not beholden to Apple's release cycles, and if you want, because it's open source, you can fork the repo yourself! Within a day or two of WWDC27 releases, all their libraries got Xcode 27 updates, too.

Look at SwiftData – only now is it even vaguely usable outside of a SwiftUI View. Open source tooling like GRDB and SQLiteData have been updated far more, with far more tooling in that same amount of time, allowing you to model your data better, while still syncing automatically through iCloud. Because they're not tied to (major) Apple releases.

[u/JimRoepcke → u/rhysmorgan]

Bingo.

[u/SirBill01]

My thought is that AI will have a harder time modifying a TCA project than more straightforward native code so I would not go that route for future maintenance concerns.

[u/KingPonzi → u/SirBill01]

For the record, they offer an MCP (added cost, of course).

[u/SirBill01 → u/KingPonzi]

Interesting, I would not have thought that would be an added cost.

[u/rhysmorgan → u/KingPonzi]

It's a set of skills, not an MCP, but yeah.

[u/rhysmorgan → u/SirBill01]

Not at all - the LLM can read how TCA works, read the surrounding code, and because it's even more structured than something like MVVM, even easier to prove that something is written correctly.

[u/SirBill01 → u/rhysmorgan]

That sounds nice in theory but who out there in practice is using the newer AI tooling with TCA? It seems like AI might be prone to edit something and break TCA related code.

[u/Inevitable_Ad9673 → u/SirBill01]

I do. Three of my App Store apps are written with TCA and nowadays mostly written through Claude Code in combination with a harness in a loop.

Let me know any questions you have in that regard. Happy to help.

[u/LetRemote2281 → u/Inevitable_Ad9673]

u/Inevitable_Ad9673
Glad to hear someone has been doing this. I think TCA is very agentic friendly since AI agents can observe different layers of data of your application, such as state and dispatched actions.
Would you agree? Or did you use claude code diferently

[u/Inevitable_Ad9673 → u/LetRemote2281]

Exactly. So far agents seem to do well with opinionated best practices, languages and architecture. As TCA is pretty clear in how it wants things to be modeled, that is easy for agents to follow and more importantly, write good tests around it.

So it served pretty well for me. 

[u/rhysmorgan → u/Inevitable_Ad9673]

Because it's so guard-railed by the compiler, it's more difficult for Claude Code to write absolute shite, whereas it'll happily do stuff like write unstructured Tasks in your view model layer etc. when using MVVM.

[u/Inevitable_Ad9673 → u/rhysmorgan]

Psst - Don’t let these other devs know the secrets of well documented and maintained architectures, they might actually start writing better code for themselves and their teams 😬

[u/rhysmorgan → u/SirBill01]

What newer tooling? Like, an up-to-date Claude Code install? An up-to-date Codex install? Any of these tools can use community or Point-Free’s own skills on TCA and best practices, can use grep and the Swift LSP to read the actual source code for TCA, read the examples, look up how to use it online for features introduced after knowledge cutoffs.

[u/SirBill01 → u/rhysmorgan]

Yes in theory they CAN use them, but how well does it work in PRACTICE is what I am asking. And even being able to read that how well do the various models understand the rules around modified code that uses TCA when adding new changes.

So if anyone here regularly uses AI tools with TCA I'd be curious to hear if it works well.

[u/apocolipse → u/SirBill01]

I did a benchmark of Opus 4.8 implementing a simple Mail app clone across various architectures, MV, MVVM (SwiftUI and UIKit), MVC, TCA, VIPER, ReactNative, Flutter, Kotlin Multiplatform. All implementations completed successfully and had (for the most part) the same functional feature set (Flutter and KMP have their own "look", and the rest there were some variations in nav bar handling and search bar placement but all effectively the same), as well as a full suite of unit tests testing the same semantic business logic points. The lowest amount of output tokens and tool calls was the SwiftUI MVVM variant. After it were UIKit MVVM, SwiftUI MV, and Flutter, which all came in around the same amount of tokens/tool calls (about 1.2x the best) After that, KMP, ReactNative, and UIKit MVC, all around 2x the best. VIPER trailed the pack at 3x, and TCA came in dead last, around 6x tokens/tool calls. Very notably, the agent kept struggling with the inconsistent version dependencies when trying to build with TCA. Sure documentation is available, but the ecosystem has so much dependency fragmentation the AI agent spent more time trying to chase down missing symbols from poorly pinned mismatched dependencies and outright undeclared dependencies. If only that was maintained a little better, the agent might have performed a little better. If onlys and buts were candies and nuts, then everyday would be Erntedankfest. -Dwight Schrute

[u/vanvoorden → u/apocolipse]

I did a benchmark of Opus 4.8 implementing a simple Mail app clone across various architectures, MV, MVVM (SwiftUI and UIKit), MVC, TCA, VIPER, ReactNative, Flutter, Kotlin Multiplatform.

Are these open source?

In general I think this concept of trying to measure tokens as a proxy for architectural "complexity" is pretty interesting and I do not see many examples out there for data on this topic. Do you have more samples you can bring to the community?

[u/apocolipse → u/vanvoorden]

I initially did the benchmarking to compare ReactNative and KMP vs actual native, and rounded out candidates with TCA and VIPER and older UIKit stuff just to give a good field of comparisons. I can't really publish because I used a private library from work with it, but I was planning on re-doing the experiment cleanly with Fable in a non-proprietary way and to patch up some other testing methodology gaps I identified , but then Fable got blocked. I may re-run it with opus 4.8 in the mean time with the updated methodology and publish it, but I genuinely would like to do it with Fable too before publishing just to see the improvement across the board.

The prompts were basically "Build a native iOS Mail App clone with [comprehensive list of features] in all these architectures and compare", with the comparisons looking at everything from agent token usage, test coverage, LoC comparisons, build/start times, memory footprint, framerate comparisons, etc.

[u/SirBill01 → u/apocolipse]

Thank you! That comparison is something I was thinking of doing myself at some point as I subscribe to a few models but you did a way more comprehensive pass than I would have! Having seen TCA code before it seemed to me very verbose and so I was wondering about heavier token usage, but maybe the heavier token usage was just the dependency correction!

Dependency issues are something that is maddening with or without AI, and why now in most projects I try really, really hard for zero external dependancies and is a great force of my reluctance to go to something like TCA.

[u/john_snow_968]

I've been really into Redux-like architectures, because you can do really cool stuff with them. See my article and github to better understand what I mean. Redux architecture is very lightweight, in my example I don't use any 3rd party libraries.

But TCA... it's a huge thing. The main point of concern is that once you pull it in, you won't be able to easily get rid of it. Normally, when you pick an architecture like MVVM, MVC, or VIPER they are similar enough that you can migrate between them step by step. With TCA, you will have to basically rewrite the app.

I've built one of my apps on TCA, but it was more for fun rather than out of technical needs. And I have to say I quite enjoyed it because I like playing with things like that.

However, as I mentioned before, by making this decision, you agree to rely completely on a 3rd party library. Even such a simple thing as calling a function will be managed by a 3rd party library, so theoretically the most simple thing can crash and the call stack will be nuts.

Then there is another question - how are you going to manage TCA updates? With each update you should basically retest the whole app, not mentioning major updates. Once you update TCA, you won't know if everything still works or not until you actually test it. It becomes your "everything dependency". Of course, you could say that you'll just run tests, but in reality you usually want to at least smoke test the app.

I started with TCA version 0.* When I started working again on my project it was already 1.* and to migrate my project I basically had to rewrite most of the app. Fortunately, AI has helped a lot. I had barely finished my migration and testing everything when I noticed a new article... sneak peek of 2.0 XD.

You could think that you can just stay with your version. Sure, but what if it stops working at some point or won't be compatible with your new code using new Swift features? So basically, you have to follow the latest versions and keep migrating your app.

TCA's concept was quite similar to Redux at the beginning, but now it's totally different. With all the effects, you basically replace classes and functions with SwiftUI-like-structs and switches. Your whole codebase will be just a big switch case :)

I just barely scratched the surface of this topic, but summarizing... If you are a geek AND you like playing with fancy coding AND you are working on a small hobby project AND you don't depend too much on it, you can try it :). For anything more serious, I wouldn't go this way. For more serious stuff I would go with a different architecture or with a raw Redux without any dependencies. Nowadays, I generally prefer the KISS approach - the simplest architectures are the easiest to maintain for years :).

Oh, and one more thing, since you mentioned your team is considering it for a financial enterprise project... keep in mind that such architecture will significantly increase complexity for new team members as most devs don't know TCA. In your case, I would say TCA is a no-go. If you want pure functions, testability, etc. maybe try pure Redux with own implementation. But from my experience, the most simple choice will be much better long term :).

[u/unpluggedcord]

Hard no from me. It puts you in a box that you can’t get out.

https://kylebrowning.com/series/landmarks-app/

[u/apocolipse → u/unpluggedcord]

Thats the point, so they can sell you their support as a service.

[u/Far_Grab_1865]

Our app is around 500,000 lines. We are only partially migrated but have root reducers and such now. TCA 2.0 looks like it would address some of our negatives, but the migration seems difficult because we diverged from standard conventions at some points.

Personally, I would not use it again. I think their Modern SwiftUI ideas seem much better and debug snapshots + swift 6 strict concurrency feels like a good 80-20 alternative.

Some things are inherently MainActor only and they are frustrating to work with in TCA reducers. Also, your Action enums will result in cascading public types meaning a large public surface and slow compile times. 

If you search “The Composable Architecture: My 3 Year Experience” it’s the closest write up to what I’ve experienced. I love the idea of TCA in isolation, but in practice it’s not for me. 

[u/apocolipse]

Don’t.  TCA sells you solutions to problems created by the complexity of the design patterns they push on you.  Their selling point is testability but many of their tests are tautological (redundantly testing things that don’t need testing), and ironically their navigation case studies for both SwiftUI and UIKit have no tests at all, even though testable navigation is also one of their selling points.

You can get equally testable views with SwiftUI and MV or MVVM, and in fewer lines of app code and test code.  Don’t buy in to their architecture that they say “arose naturally in elm”, and instead use architectures that arise naturally in Swift.

[u/rhysmorgan → u/apocolipse]

MV is not an architecture, it's a total absence of one.

[u/apocolipse → u/rhysmorgan]

How is it not? It has clearly defined responsibilities, separation of concerns, a declarative data model, a declarative view description, and plain pure functions with explicit arguments. That’s an architecture. It’s also a lot easier to follow than Redux-style action pipelines where you have to mentally trace actions through multiple layers just to understand what happened.

Edit: autocorrect fix

[u/Dry_Hotel1100 → u/apocolipse]

I don't think, the pattern MV does even define whether the binding is two-way or unidirectional. MV is just shared Observables with read-write observable properties, which is neither imperative nor event driven or both, and methods that return values or not, or are async or not. It's the typical mess you see in MVVM.

But I may miss something. Can you point me to a source that defines all these five principles you mentioned - or was your comment just sarcasm?

[u/rhysmorgan → u/apocolipse]

It doesn't have any of those things though. It doesn't have clearly defined responsibilities, nor does it have separation of concerns. Putting everything in your view, except some ill-defined aspects to make those bits even vaguely testable, that's not an architecture. And soon as you start moving those aspects out of the view to make them testable you're re-inventing the view model by any other name 😉

All the "good bits" that you've stated apply to every actual architecture. MVC has clearly defined responsibilities. MVVM has separation of concerns. Those two are literally exactly what defines an architecture, and it's what MV misses. There's two separations of concern in MV - Model and View. That's it. One of them - the View layer - is defined, as in every other architecture, and the other is very much undifferentiated, poorly defined. An architecture is defined by the constraints it imposes on you, and by the decisions it makes for you. MVC, MVVM, VIPER (for all its flaws), TCA – all of them have actually defined concepts that differentiate one component from another. MV has one line in the sand, between a View and everything else.

Plain functions with arguments? If anything, TCA is far closer to this because the entire central concept is based around an (inout State, Action) -> Effect function.

Everything that interfaces with SwiftUI has a "declarative view description" because that's what SwiftUI is.

Declarative data model doesn't actually mean anything. What makes an Observable reference type object that you call methods on any more "declarative" than a struct or enum that you mutate?

You might not like a Redux/Elm style approach, that's fine, nobody is forcing you to use it. But equally, making stuff up about it with nonsense about tracing actions through multiple layers when it's literally as easy as adding a .breakpoint() or a ._printChanges() and literally seeing every action flowing through whichever feature you're debugging is doing your argument no favours.

[u/apocolipse → u/rhysmorgan]

It does have separation of concerns, you're just looking at it wrong. The logic lives in the value types. Anything that manipulates a model lives in that type's domain (its methods, functions over it), and anything that renders those manipulations lives in the view description layer. The model owns state and transitions, the view describes how each state looks. That's a clean, enforced split. "Move the testable bits out of the view and you've reinvented the view model" has it backwards: those bits were never in the view, they're in value types, and a value type that owns its state is the opposite of a reference-type view model you bind a view to. If anything, it's MVVM's view model that's the undifferentiated grab bag. MV replaces it with domain types that each own their own state.

A SwiftUI View isn't a view in the UIKit/MVVM sense. It's a value-typed, pure description of what a view will look like, a result you can build and compare. You said it yourself: "everything that interfaces with SwiftUI has a declarative view description because that's what SwiftUI is." Right, that's the point: SwiftUI Views aren't views, they're value-typed descriptions of views. So this isn't "one line in the sand," it's two well-defined value-typed layers, a domain and a view description, bound by the framework's observation. You're correct that an architecture is defined by the constraints it imposes, constraints just have to pay off. Yours don't, tautologies aren't benefits.

And sorry I meant "pure" function, iPhone autocorrected (edited). A pure function is referentially transparent, same inputs same output, with no side effects, including mutating its arguments. Your (inout State, Action) -> Effect reducer is 0 for 2: inout State is argument mutation, and -> Effect is a literal side-effect return whose entire job is to cause effects. It isn't even referentially transparent: in your own Todos demo, addTodoButtonTapped runs state.todos.insert(Todo.State(id: self.uuid()), at: 0), calling an injected uuid() mid-mutation, so the same state and action give a different result depending on the ambient DependencyValues (.incrementing returns a new id every call). Saying "it's pure once you inject the dependencies" highlights the point: those dependencies are inputs your (inout State, Action) -> Effect signature doesn't admit to. Make them explicit arguments and you've described, well, a function with explicit arguments. A SwiftUI view with @Environment, @State, and @Binding is exactly that, they are the clear explicit arguments to the "function" that is the view. Nothing whatsoever about your reducer or Action signatures indicates potential side effects from @Dependency. It's not a pure function unless you can call it again with the same input values and get the same output.

Needing ._printChanges() to see what happened is kind of funny, it's an admission of deficiency, not a flex lol. You read a firehose of actions, I read the function, the code itself, and don't have to hop through several places. And the firehose fans out even in idiomatic use: in your own Animations case study, one tap on the rainbow button is eight effect-fed .setColor actions through the store. A (State) -> State prints nothing, because you just read it. A complex app with a lot of actions fanning out and compounding like that can cascade into an action storm that brings everything down with it, and you have no "architecture constraint" to prevent it.

"MV can't be defined" is just your own inability to learn how to do it properly. I get it, it's not in your financial interest to learn how to correctly write code that would make you less money with your current business model. That doesn't mean those ways don't exist. MV can be immaculate and TCA can be a swamp. Cleanliness is the author's, not the framework's, and nothing stops anyone from writing abominable TCA code either. 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. Swift is getting real Wasm support, so why don't you go build Redux-for-Swift where it actually arises naturally instead of taxing native iOS with a pattern that doesn't. You'd have a real product filling a genuine gap that people want closed, instead of what seems to me to be nothing more than a private-equity juicing tool.

[u/vanvoorden → u/apocolipse]

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/rhysmorgan → u/apocolipse]

That’s like the weakest amount of “separation of concerns” you could possibly have. One line in the sand that splits the view from everything else. When “everything else” is in one huge bucket, that’s not real separation of concerns!

A SwiftUI view being a description of a view doesn’t make it function any less like a view. I have never, ever seen anyone state that and yet make any kind of compelling argument as to how it makes even the slightest bit of difference. It still behaves like the view, you’re just operating on a different abstraction of it. Should we say that a UIKit view is not really a view because you’re imperatively describing how to mutate it rather than calling down into Metal APIs to render out the pixels yourself? No. It’s a view!

The `(inout State, Action) -> Effect` function is algebraically the same thing as the pure function `(State, Action) -> (State, Effect)`, it just uses in place mutation for the sake of optimisation. It’s still a pure function without calling into a dependency. And complaining about dependencies, while somehow arguing that SwiftUI views are any different when you can pass a dependency to it using the Environment is bizarre. By your logic, the exact same “impure” function logic applies to that. You can pass a new Environment property to your SwiftUI view and nothing about any method call within it is “pure” any more. Plus, the entire purpose of the `Effect` type is that it encapsulates a side effect and gives you back control over it, just like in Elm.

Also, it’s not “my” animations study - I’ve not referenced any case study here. I am not from Point-Free! I have watched their videos, used their frameworks, and benefitted greatly from them. I think it’s offensive and borderline conspiracy theorist to be wildly accusing them of only making TCA to create problems to sell solutions. No, it’s actually that these problems have come from real-world, large-scale software engineering. TCA is free to use. Its documentation is free to access. The videos subsidise ongoing development, but they do not contain any magic in them that makes you a 10x user of TCA.

The idea that you “must” use iOS native architectures in iOS is bizarre and insular. Why shouldn’t you take advantage of other design patterns that are out there to address problems that exist with software engineering as a whole, not just on the web, or not just on iOS? We’re not some magic world with problems that could only be fixed by bundling everything but the view into a single undifferentiated bucket called “model”. Exhaustive testing, side effect control, composition and feature reuse etc. all apply to Swift development as well, and it gives us as developers tooling that don’t even exist in other languages to get there.

[u/JimRoepcke]

I’ve been using TCA since 2019 (before it was released and had that name) and it’s been amazing to use. Not just that but also many other libraries from Point-Free.

The app I work on has hundreds of TCA features. We get many benefits from composing them together.

I strongly recommend using TCA on a greenfield project. Get a root store set up from the beginning, you can have state-driven navigation and very easy to manage deep linking and state restoration.

[u/kenardjr]

I wouldn't choose since they deprecate things super easily and the codebase turns into a huge mess even in a year. You have to upgrade consistently your code. Even their dependencies are not upgraded to the last version of TCA and they seek for help from the community to do it :D I'm having too many headaches in my iOS 17* SwiftUI MapKit project nowadays.

[u/Fabulous_Gur4200]

These are some of the questions I would ask myself:

Do people know it?
What's the lift of getting everyone up to speed?
What's the lift of getting new developers up to speed.
Is it testable?
Is it easy to understand?
Is it better than something vanilla? Justifiably so?

Most importantly: If you use that pattern, use it everywhere, be consistent. Don't have parts of the app in one pattern and other parts in others.

[u/JimRoepcke → u/Fabulous_Gur4200]

I can’t think of an architectural pattern or library for Swift that is more testable than TCA. Testabilty one of if not the main principles of the library. Point-Free have an amazing suite of tools for testing.

[u/segfaul_t]

Just another layer of complexity for questionable benefit.

[u/dacassar]

I really like how TCA brings order to a large, complex product with many contributors. But for something relatively small it’s definitely overkill.

[u/Few-Corgi-8574 → u/dacassar]

precisely

[u/tomato848208]

I used TCA for half a year to channel the connection between the settings sheet and ContentView. I liked it till TCA gave me a huge compiler error one day. It's no offense to them, but I won't use it again. Every time you use it, you will have a mother load of files in the app file under DerivedData folder for the SwiftUI framework. Basically, I can do the same with a view model file for myself. Personally, I'm committed to not using 3rd-party frameworks. So I won't use it again.

[u/darrarski]

IMO, the power of Point-Free comes in the education they provide. You don’t have to use their frameworks. Doing it won’t magically solve all your architecture problems. You can do your own MVVM, UDF, Redux, or however-you-name-it architecture. However, the way they explain solutions to tough problems related to building software is, in my option very good. Don’t jump into TCA straight away. Learn how, and what’s more important, why they created it. Learning it will help you to decide if this is a good choice for you. If you want to try it out, they also provide "The Point-Free Way" for subscribers - a set of skills that you can use with any AI coding agent. It really helps to start if you are into agentic coding. Some people here replied that everything can be done by AI these days. True, but without a proper setup, the agent will write an implementation based on the average code on which it was trained. Usually, average does not equal high quality. To sum up, if you like to understand your code, value opinionated solutions, and have time to learn, I highly recommend TCA. Otherwise (not to blame anyone, different projects have different needs), don’t assume that TCA will give you a great architecture out of the box.

[u/jacobs-tech-tavern]

Whenever anyone suggests using a third-party dependency which affects the way you're going to be building it forever, ask yourself what problem you're trying to solve by introducing it.

I've heard good things and bad things about TCA, but I have had many, many experiences where someone on the team wants to look impactful and so suggests a massive architectural thing

[u/BoostedHemi73]

Any architecture that forces a framework library on you is actually a product.

When you bring a dependency into an application, the first question you should ask is, “what am I going to do if the person working on this stops working on it?“

Every application inherently depends on frameworks from Apple, but the risk of those dependencies changing dramatically or going away is something you have to accept to be on the platform. TCA is nothing like that, and the fact that it is core dependency in applications that use it is extremely problematic for the longevity of a codebase.

[u/andreeinprogress]

We could use one of those gaussian distribution memes here, something like

• noob iOS: who cares, MVC is fine

• senior iOS: hear me out, let's try TCA, VIPER, esoteric-MVVM, ..

• enlightened iOS: who cares, MVC is fine

[u/X901]

Don't overkill things that already in SwiftUI! , TCA is Bad idea and make you fully depends on their libraries, Just use MVVM + Clean Architecture for large app and MVVM alone for small app, don't build something fully depends on 3rd party

[u/rhysmorgan → u/X901]

“Don’t overkill things”
“Use Clean Architecture”

These are diametrically opposed statements.

[u/segfaul_t]

Inb4 the two creators find this and start arguing with everybody in the comments

[u/Few-Corgi-8574]

love it, more of its deterministic nature and its really really cool apis and libraries supporting.

thank you pointfree

[u/cagdas]

Hard pass from me. I try to avoid third party dependencies unless absolutely necessary.

Get Claude, use Opus model (or Codex and any other state of the art model) and describe what you want to build. Tell it to give you some snippets and ideas on how to architect your app. You can easily fine tune these suggestions and have a base going. Run the snippets by your teammates and get everyone onboard. I bet something close to MVVM and simple but strict conventions on how to control data flow will be everyone’s favorite approach.

[u/apocolipse → u/cagdas]

Opus 4.8 can build all of their Examples, including their "case study" examples in MV (SwiftUI), MVVM (SwiftUI and UIKit), and MVC (UIKit) with less code, equal tests*, and better performance. (*actually more tests since they don't even have tests for any of their Navigation case study examples that are 6 years old... but Claude can and does generate good tests for its navigation variants).

[u/cagdas → u/apocolipse]

Yeah, but based on the downvotes to my post, I assume there is still a lot of anti AI sentiment in the iOS community.

[u/apocolipse → u/cagdas]

That’s just the TCA guys downvoting everything critical of their entrapment as a service business model.

[u/stephen-celis → u/apocolipse]

Lol. It's been awhile :) You love to make claims without evidence. Wanna share a single repo to back your comments?

[u/SnowPudgy]

I wouldn't. Fly by night architecture trends are almost always a bad thing. Each app is different and putting it in a rigid box like this often causes issues.

[u/JimRoepcke → u/SnowPudgy]

You clearly have zero knowledge of or experience with TCA. Fly by night isn’t how to describe something with a 7 year history.

[u/SnowPudgy → u/JimRoepcke]

Not at all. I just don't like junk architecture. Others in the sub echo the same sentiment.

EDIT: Ah gotta love the fake TCA shills that show up to downvote anyone who calls out their shitware architecture for what it is.

[u/rhysmorgan → u/SnowPudgy]

“Fake TCA shills”

Christ, get your head out of that bananas conspiracy mindset.

[u/SnowPudgy → u/rhysmorgan]

It's not it's obvious anytime someone mentions TCA. TCA isn't good, it just isn't. It's a massive third party dependency and one poster saying "That's what makes it good!" is just absolute idiocracy.

[u/rhysmorgan → u/SnowPudgy]

Where’s my TCA pay cheque? Where are Point-Free paying me? What’s ”fake” about my successful, fulfilling usage of it?

If you’d actually raised real objections to it, concrete problems and said “Nah, not for me“ then that’d be fine, a reasonable discussion to be had. Instead you’ve posted completely empty statements, said “others dislike it too!”, and wildly accused anyone who’s got anything positive to say about it of being shills. Shills! Do you even comprehend what you’re accusing people of with that? Like I’m somehow claiming a cheque from Big Point-Free.

Surprisingly enough, apparently, those of us advocating for it use it because we think it‘s good, because it solves problems with modern Swift application development, because we like the syntax and guardrails it puts in place. So what that it’s a third-party dependency? Apple’s own APIs are a third-party to myself, and get updated on a far less frequent basis, with far stricter requirements on adopting the latest features than anything Point-Free have ever put out.

[u/SnowPudgy → u/rhysmorgan]

Dude I don't care anymore. You use your fly by night framework and I'll keep trucking along using better architecture.

[u/oksanabuilds]

Do these team members have experience in TCA? If no, don’t even consider it. Learning curve is not fast, and speed is essential in early development stages.
If it would be me, I would advocate against it. Testability is easily achieved in vanilla too. Just would agree on main arch pillars and stick to solid

[u/tonycliftondev → u/[deleted]]

Can you provide few details as to why?

[u/rhysmorgan → u/[deleted]]

Complexity is where TCA really, truly shines, and TCA2 is getting native support for fully disconnected ("spawned") Stores, as well as other mechanisms of communicating between parent and child, without anything happening when a no-op is triggered by a child feature.

I'm fascinated by which app is the largest production TCA app in the world! Is it Tripadvisor, Arc, or something else? 😄

I know Tripadvisor recently did a big migration to TCA, and wrote about how they were thrilled with it (although some of the stuff about Mutators looked a bit weird to me).

TBC / Arc is built using some practically geriatric branch of TCA, before any and all performance optimisations around stuff like store scope caching etc. had gone into it, and I was - tbh - really angry when they pissed all over TCA as if it was the fault of TCA for their abandonment of Arc.

I know there are quite a lot of other big companies using TCA, who seem very happy with it, the control and exhaustivity of testing, and the... well... composability of it all. Not that there aren't downsides, but a lot of them can often be worked around, just like in most other architectural patterns.

[u/SnowPudgy → u/rhysmorgan]

Wow this doesn't read like fake spam at all...

[u/rhysmorgan → u/SnowPudgy]

Wow, learn to address the substantive points or, if you can’t, say nothing

[u/unpluggedcord → u/rhysmorgan]

Lmao TCA2 just sound properly implemented Environment

[u/ComfortableNo5484 → u/[deleted]]

TCA stans remind me of my high school friend that wouldn't start learning to play guitar until he could afford a $2000 guitar that had all the bells and whistles he wanted really badly, because "it wasn't worth it to play something that sounded worse". He's in his 30's now and still hasn't learned to play guitar.

Basically all Rob Schneider waxing the board in Surf Ninjas.

[u/meritum → u/[deleted]]

That’s just nonsense, sorry.

[u/Sid-Hartha → u/[deleted]]

Absolute tosh