Why I chose The Composable Architecture for SwiftUI and never looked back

Tired of swift bloat and seeing the systemic failures of a newborn SwiftUI, after more than 10 years of working as iOS Dev, I was ready to leave iOS App development.

I’ve been an iOS developer since version 3. Good ol’ days of Objective-C, Preprocessor macros, manual reference counting and heavy Core Foundation usage. Interface Builder and Xcode were two different applications. Dependencies were handled by dragging and dropping Xcode Projects to one another. But things began to change.

My thesis on Massive View Controller is that we iOS developers took Apple code samples too seriously…

I’ve always been a Design Patterns heavy user. I own a hard cover copy of the GoF book signed by one of its authors even wrote a few patterns of my own. My thesis on Massive View Controller is that we iOS developers took Apple code samples too seriously and I appear not to be the only one.

I started to code a SwiftUI app when the framework was just a public beta in 2019. And I experience the pains in my own flesh. Yes, TheFrutaApp is a lie. SwiftUI initially had serious application state problems, now the problems are not that serious as in 2019 but it’s 2023 and we still have to deal with huge problems like random re-rendering, performance problems, and pretty inexistent deterministic and reliable testability.

You are not alone The Composable Architecture was born to the light of those problems. TCA restored my “faith” in iOS development since I felt someone else saw how broken it was.

Not only that! They were up to fixing it by applying software engineering concepts that were proven without selling smoke / snake oil or building the next silver bullet.

I was working as iOS Lead at Electric Coin Co. at the time. We needed to start a new open source wallet project and we would continue to use SwiftUI, aiming for the technologies that would be “the norm” in the future.

After really thorough architectural analysis we did it: October 13th 2021 was the day we pivoted to TCA and “never looked back” with great results

Zashi was code-named secant at the time, it went through many restyling and changes. TCA was able to accommodate all of them. Secant has been forked and refactored into other apps like NightHawk App and TCA handled it like a champ.

These are my takeaways and decision making process when I evaluated many architectures for a SwiftUI App and decided for The Composable Architecture.

Even if targeting the latest iOS 17 release, I can tell you that Vanilla SwiftUI doesn’t work well for not even for basic demo apps like “the Fruta App” or “Standup Meeting” application. You need more tools.

Don’t DYI

There’s a big chance that writing your own architecture goes wrong and you end up (luckily) re-inventing the wheel. If you have good fortune your re-invented wheel will turn without squiggling much.

TCA is not a silver bullet but a very flexible tool that provides a framework that a team can use to build an application that uses unidirectional data driven flow to drive SwiftUI’s DSL.

My main concern when evaluating TCA for building codename “secant”, was the learning curve. If your project is a fully open as this one is, where everyone can contribute freely, TCA could be either: 1) a very attractive honey pot to get developers the TCA crave they were seeking, or 2) a contributor barrier. Only time will tell. It was a coin-toss at the time in 2021. Apparently luck was on my (our) side. Or at least I hope so!

If your project is closed-source and 9-to-5 coding. Your team will be very happy of learning new stuff. Every new hire of the future will benefit of having a clear onboarding route already created for you by the PointFree folks.

What I can say about my experience so far:

The CONs:

• TCA has a learning curve proper of using a new paradigm with familiar tools. Takeaway: you will have this learning curve whatever your choice is if you are not familiar with it.
• You will have to create wrappers for dependencies you once used innocently “out-of-the-box”. Takeaway: this was probably an illusion. You are paying the cost up front and before you were deferring it until it blew up on your face.
• Not the Drag and Drop solution you dreamed of.

The PROs:

• It is very well documented. But, you have to make the time for reading it and sink it in. Unless you already know the functional paradigm, there are things than won’t be easy so figure out just by cmd+click and reading the code.
• It provides a very opinionated way of handling state and data flow on your app. This reduces SwiftUI’s bugs significantly. SwiftUI makes it easy to couple screens to one another. Combine observers can drag down your app’s performance due to unexpected re-renders and hierarchy recreations that will make your app flicker, reset at best if not crash.
• It makes you have testable code by default. Having to wrap your dependencies in witnesses or wrappers lets you mock them you will have .live and .demo implementations of every dependency you once used to struggle with. Your app is far closer to 100% test coverage than ever before.
• It makes you a better developer. There’s no way you go though the docs without learning something new.
• Using Store and Reducer make your business logic fully unit-testable.

Other comments:
You will compensate the learning curve with time saved by not having to deal with bugs caused by mishandled bindings, random re-renders, etc. But it won’t me immediate and impacient managers and stakeholders might not appreciate it easily.

How I approached it as Tech Lead:

The way I found to approaching TCA is actually subscribing to pointfree.co content and study it.

Try to rely on people that has experience on it to help your team gain traction and experience. If not, create study groups and dedicate time of your day into absorbing the content generated by the authors.

You won’t be able to absorbe more than 45 minutes of content a day. Since there are many concepts that are covered throughout the episodes and in the end the only way to learn them fully is to apply them.

If you have an urge, try to find contractors that are very familiar with it and let them help you ease the curve.

TCA can be adopted gradually. Split your functionality and start one screen at a time. Your app will benefit from it.

Note: this is a mashup of this twitter thread and this GitHub discussion

Thank You Point Free Co for making iOS Development Fun again ❤️