Why most(99%) KMM examples use Jetpack Compose? XML is really dead?

# multiplatform

[Hasan Nagizade]

Why most(99%) KMM examples use Jetpack Compose? XML is really dead?

[Louis Gautier]

I don’t think XML is dead at all. It’s juste that KMM is so new that it ‘must’ be used with other new stuff

[Hasan Nagizade]

Entry level to KMM is hard in itself and this compose attachment makes it even harder because you have to learn compose first in order to understand those tutorials. They are pretty much useless for people who don't know compose

[Casey Brooks]

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.

[wbertan]

We use KMM and Fragments + XML on Android 😬 (iOS uses SwiftUI)
All depends in how you architect your codebase, and how much you are sharing between platforms.

[Casey Brooks]

As an example, checkout this gist which shows how one might translate the same KMM-type ViewModel into both Compose and XML views.

It’s perfectly fine to use XML for KMM, collecting a StateFlow and updating the entire UI when it changes, the UI-specific code is going to be pretty similar for both cases. But if you give Compose a shot, I think you’ll find it easier to pick up than you think, and will make it much easier to apply common KMM data to your UI

[agrosner]

Also compose may support ios someday soon

[agrosner]

So by using it, you may be able to write Same or similar ui code

[Michael Friend]

I think the trend is mostly based on the assumption that if youre using the still-in-beta KMM, you’ve probably moved to now stable Compose. plus the fact that samples in compose are generally simpler to read than Views AND your iOS ui code and android UI code will look similar. But with any properly architected sample you should be able to pretty easily swap out the view layer for XML/Fragments since thats not really the important part of what a KMM tutorial/sample is showing off

[Grégory Lureau]

"may support ios" -> https://github.com/JetBrains/compose-jb/tree/master/experimental/examples/falling-balls-mpp very experimental I suppose, but I presume they are going to support it.

Also for Android side, Compose is the replacement after 10 years of the old UI kit (XML) so it make more sense to support Compose over XML if you want to maintain your sample in the next years. And since, for sample apps, you've an (almost) free export to desktop and web and only Android for XML, it also makes the github project more multiplatform than XML.

[darkmoon_uk]

Having used both extensively (in the case of Compose; to deliver 2.5 large projects already) I hope Compose does come to be seen as the default choice sooner rather than later. In my experience it's more productive, and it will only get more-so as the tooling improves. It's an example of really great engineering from Google - feels more solid than SwiftUI, it's iOS counterpart.