Krzysztof Zabłocki - Leveraging Composable Architecture at Scale | Swift Heroes 2023 Talk

🎟️ 2024 ticket SPECIAL PRICE: swiftheroes.com/2024/
The Composable Architecture (TCA) is a popular framework that unifies your architecture for Swift apps.
In this talk, we’ll look at lessons learned from using it on large codebases, potential gotchas to be aware of, and improvements & dev tools you can add on top of vanilla TCA.
🎤 Krzysztof Zabłocki, Engineering, iOS Consultant
📍Swift Heroes 2023 was hosted in Turin, 4-5 May. Attended by 320 iOS developer participants and broadcast to an additional 320 Swift enthusiasts across the globe. The agenda covered a range of important iOS developer topics including SwiftUI, the composable architecture, accessibility, developer tools, testing and much more.
📌 For more engaging content and expert insights, subscribe to our channel and hit the notification bell. 🛎️
Inform: swiftheroes.com/
✅ Tweet: / swiftheroes_it
✅ Connect: / swift-heroes
✅ Read: telegram.me/swiftheroes

[@ImTheShrey]

We use Reactor Kit in our app with 200K daily active users. It's basically TCA philosophy with Per screen state store. And then on each view only updating if it's required slice within the state is mutated.

[@otniel2663]

This architecture was relevant in the React community a while ago (Redux), but the trend seems to be moving towards simpler architectures like react-query, hooks, etc. I am not sure if the iOS engineering community will follow the same path, as the problem is universal across FE development (state management is complex)

[@SwiftHeroes]

Interesting observation, we asked Krzysztof to reply to you 😉

[@rodriferretty3001]

Really interested about this point!

[@trendz4422]

Please provide links to the sample project and swiftlint config file.

[@danielt63]

At 7:53... Sure but the problem with these sorts of architectures is that any one action could change any piece of state. So not only do you have to assert the correct state changes, but you also have to assert that no other bits of state changed. That's n*m assertions (where n is the number of actions, and m the possible states.) In other words, your assertions grow exponentially with every action or piece of state you add. Not good!

[@ImTheShrey]

We solved it by dividing app state into per screen state. And then you do diff of a state slices (properties) when your views want to use it, so they don't refresh when other non related field in state object changes. Then to top it off, you collect all mutations Done by one action in to a batch and only update state struct in one go.

[@danielt63]

@@ImTheShrey Sure, but every reducer receives every action. Your per screen state receives actions from other screens and it is only by convention that it doesn't act on actions from other screens. Testing to ensure that convention is where the problem lies.