compose-samples VS Decompose

check this out : https://github.com/android/compose-samples/tree/main/Crane

Basic understanding of Jetpack Compose.

The compose-samples repo has a comprehensive list of samples ranging from low to complex projects which might be worth a look.

And what was learned from Flutter has produced something I consider even more interesting: Compose UI (https://developer.android.com/jetpack/compose) and JetBrains' Compose Multiplatform (https://www.jetbrains.com/lp/compose-mpp/)

Now, same story, in the current documentation the list is replaced by a single UserMessage without any explanation of the previous example. It just says "For a more advanced use case, displaying a list of user messages on screen, check out the Jetsnack Compose example." .

As for the strange infix syntax, you're correct - it's not important (for Dart anyway). Kotlin supports writing code that have DSL like syntax making things like typesafe HTML or Jetpack Compose possible.

Sample apps

This is what Jetpack Compose according to the Android Developers team;

I use Decompose, although I also have a kmp project which that supports. I find the compose extensions providing a very easy API when integrating with compose.

For one of our apps we used https://arkivanov.github.io/Decompose/ for navigation. It is mentioned in the Compose Multiplatform repo, but we found it pretty obscure to use and it has some confusing concepts built in.

I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.

I personally like decompose for its testability, clear separation of concerns, and apis for compose animations. Plus it's multiplatform so you can use it for other kmp targets.

Full discretion, all my new apps are built using mvi with MVIKotlin and decompose for the compose extensions for navigation animations. A sample project I have built with that architecture can be found here.

Check out Decompose, it's multiplatform - https://github.com/arkivanov/Decompose

Decompose

I personally don’t like the idea of mixing compose state in the view model layer, as that implies it can only work with compose. But I also have been writing a kotlin multi platform app which exposes the state to SwiftUI using a custom data type with decompose

The custom wrapper is called Value which is just a platform agnostic state holder. Then there is an extension function you can use in compose to observe that state in compose.