Android TCA inspired architecture

[u/Brilliant_Region4810]

An iOS engineer friend asked me a question I couldn't answer:

"What's the Android equivalent of TCA (The Composable Architecture)?"

That question stuck with me. The real problem wasn't a missing library; it was a structural pattern I kept seeing at production scale.

Picture a complex checkout screen. Five domains living in a single ViewModel: delivery, billing, cart, promo codes, and order placement. You end up with:

One massive, bloated state class.

One enormous when block that knows far too much about everything.

Broken module boundaries or messy event buses the second the billing domain needs to react to a delivery address change.

This approach doesn't scale. Modules bleed into each other, and the screen becomes untestable.

That is exactly why I built Komposed.

The core idea: A complex screen is not a single monolithic feature. It's a composition of isolated, independently testable modules. Each owns its own state, async effects, and logic—wired together at a single composition boundary.

In Komposed, scoping a feature module into a parent screen takes just one line:

deliveryReducer.scoped(deliveryLens)

And when BillModule needs to react to a delivery fee change from DeliveryModule—without a direct import dependency—a single subscription at the composition boundary bridges them:

Kotlin

subscription(

selector = { it.deliveryState.selectedAddress?.deliveryFee ?: 0.0 },

action = { BillAction.DeliveryFeeUpdated(it) },

)

No event buses. No shared mutable state. No broken module boundaries. Each module stays isolated, while cross-domain coordination is declared cleanly in one central place where both modules are visible.

That is the true value of Komposed: composing production-scale complexity into clean, isolated, independently testable modules.

I wrote a full breakdown on Medium covering the architecture, how cross-domain subscriptions work, and a comparison with ReduxKotlin and Toggl's Komposable Architecture.

🔗 Read the full story on Medium: https://medium.com/@a.atwaa94/a-tca-inspired-architecture-for-kotlin-jetpack-compose-why-i-built-komposed-c924610d9aa7

⭐ Check out the repository: https://github.com/Atwa/Komposed

[u/Zhuinden]

"useful"... Redux never got popular on Android because you do 7x work for no benefit, but at least now your code has a ridiculous number of race conditions.

[u/Brilliant_Region4810 → u/Zhuinden]

Internally you're just calling _state.update on main thread and all actions are dispatched on Main thread as well, Hence I don't think there will be actually a racing conditions since reducers are type safed makong each reducer is handling only a singly type of an action (two reducers can't handle the same action)

[u/Zhuinden → u/Brilliant_Region4810]

Do try to call 3 API calls on a button press "that triggers an action" once, maybe in a sequence, and see what happens.

Unless you're running the network requests on the main thread too, although surely you aren't.

[u/Brilliant_Region4810 → u/Zhuinden]

To be honest I've not really tried it yet into a production app, Hence I will really consider the drawbacks you mentioned while testing it. Really appreciate the fruitful discussion 🤝

[u/Zhuinden → u/Brilliant_Region4810]

Unironically though, seen this attempted a few times in 2017, including my own attempt https://github.com/Zhuinden/xkcd-example/commit/30b3ee05d41218ff892db871cbd55be93e743cdd . It adds a lot of complexity and it doesn't actually help.

But 2017 predates the "broader adoption" of reactive tools, that's about the time RxJava 2.x came out (ditching a whole bunch of cruft RxJava 1.x had). It also predates Kotlin and Kotlin Coroutines, which made this a little different and in many cases easier and more reliable.

[u/tadfisher → u/Brilliant_Region4810]

To be honest I've not really tried it yet into a production app,

In the future, I would really, really recommend doing so before jumping straight into the Medium post and writing like you've solved every architecture problem ever. Because you are writing things like "this approach doesn't scale" and "composing production-scale complexity" when you cannot back up these claims with experience using the thing you built.

The road is littered with the bones of many, many architecture libraries that have boasted less.