A modern programming language that makes developers happier.

kotlinlang

I'm looking to introduce compose for desktop into a new project I'm working on. I have all of the code migrated and it works already. I know the age old question "Is this ready for production" is highly subjective, but my team is more curious about what types of errors this may introduce. For example, the team is a little bit afraid about using a slightly modified version of compose, but I told them it's the same compose with a few things built on top of it. I tried finding some documentation to prove that "compose for desktop IS compose, just with a few additions" but no luck on the project page or repo.

1. Am I right in my explanation? i.e. "compose for desktop IS compose, just with a few additions"
2. If so, is that written anywhere?
3. What sorts of problems can my team expect my adopting compose KMM instead of just android compose?
All of these questions are with the premise that our android team has 0 intention in shipping a desktop app, we just want faster feedback loops and want to use CfD for that purpose.

Generally, we build our regular builds from  <https://github.com/JetBrains/androidx/tree/jb-main|https://github.com/JetBrains/androidx/tree/jb-main> and one could easily track what changes are made on top of Google’s repo. All other components, such as Gradle and IDE plugins are fully open source as well. We upstream to androidx repo as much of our changes, as possible.

&gt; easily track what changes are made on top of Google’s repo
And currently there is no changes in `androidMain` sourceSets (and we don't plan to make such changes), and significant changes in `commonMain` (there are just small fixes for JS; if we introduce a bug into the code, we will just fix it)

`androidx.compose` is built from the same `commonMain` / `androidMain` sources (proof
<https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/src/main/kotlin/androidx/build/AndroidXComposePlugin.kt;l=130;drc=084b3d2ff21ce0ae49994dfcc824bfdbd89f28a3|https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc[…]ePlugin.kt;l=130;drc=084b3d2ff21ce0ae49994dfcc824bfdbd89f28a3>)

&gt; What sorts of problems can my team expect my adopting compose KMM instead of just android compose?
Because we build Compose for Desktop from the different `androidx-main` commit, there can be some instability in compare, for example, `Jetpack Compose 1.0`

That should change when `Compose for Desktop` will reach 1.0. Most certainly for stable releases of `Compose for Desktop` we will use the same commit as for stable releases for `Jetpack Compose`

&gt; What sorts of problems can my team expect my adopting compose KMM instead of just android compose?
Also, there can be some problems in tooling.

We don't guarantee that MPP version fully works with all Compose features in Android Studio (Preview, Layout Inspection, icons in Gutter, etc)

however, if such problems with tooling will be reported - we'll do our best to fix them

Thanks everyone. This was super helpful.

This might be a dumb question, but is there any way to see a diff of what's different between jetbrains and jetpack compose?

&gt; what's different between jetbrains and jetpack compose
<https://github.com/JetBrains/androidx/compare/androidx-main...jb-main>

<@U015TKX93PD> :pray: Thank you. Exactly what I was looking for.

THERES NOT THAT MUCH DIFFERENT! That's great news (in my opinion). I guess it's pretty much compose but compiled with a kmm flag.