A typical KMM app is limited to pure-Kotlin code, so itâs usually not feasible to try and bring in platform-specific classes into the shared layer. Traditional XML views on Android (and pretty much all imperative UI toolkits) hold onto a lot of state, which is data that becomes hidden from the shared KMM code, which makes it difficult to properly apply the shared data to the UI.
In contrast, Compose is a declarative UI toolkit, and it is fully stateless. This means you can push any data into Compose, and it will always perfectly create the UI you expect. Thereâs no additional âsyncingâ or data-juggling you need to do to update the Compose UI from a shared KMM layer that knows nothing of UI. And SwiftUI is similar in this regard, being a declarative UI with a similar philosophy, so using such declarative UIs makes it much easier to manage all the interaction and business logic in shared code, and need only a relatively small amount of fairly trivial code to actually apply it to the UI.