Beyond the when Block: where to draw the line in a server-driven UI engine

Server-driven UI lets the backend describe an app screen — components, layout, dependencies — without an app release. Large Android apps have variants of this, but the choices that separate a maintainable BDUI engine from one that decays into spaghetti are rarely written down.

At Snoonu we built such an engine in Kotlin Multiplatform, shared between Android and iOS. The hardest part wasn't the engine. It was deciding what belongs in the engine and what at the feature layer. Push too much in and it leaks domain knowledge. Push too little and every screen re-implements dependency resolution.

This talk walks through one moment we made that call. Our merchant listing needed filter selections in its request body, but those lived under OTHER components' context keys. The engine had no idea they were related. Except it did. The depends_on declaration in the layout already encoded the relationship; we used it only to trigger refetches, not to aggregate context. The fix split cleanly: engine aggregates context across declared dependencies (generic), handler translates keys into typed fields like delivery_type (domain).

That split — engine does relationships, handler does meaning — became the load-bearing decision for the architecture. We'll trace how we got there and what we got wrong, including a Koin type-erasure bug that broke half our static components while every test passed. You'll leave with a framework for that decision in your own extensible Android systems.