Hey everyone, i hope this is the right channel: T...
# compose
m
Hey everyone, i hope this is the right channel: Topic: Compose Multiplatform vs Jetpack Compose Let‘s say i have a KMP module/library where i use in commonMain Compose Multiplatform and specify a CustomButton composable there. Then i have an Android app which adds this module as dependency and uses the CustomButton (now fully in Android context). Will this Android app now have a transient dependency on Compose Multiplatform, or will the compiler translate all CMP to Jetpack compose and the Android app actually only depends on Jetpack Compose In other words: will Compose Multiplatform „leak“ into consuming Android apps or be resolved totally to Jetpack Compose? maybe @Andrei Salavei you know?
j
The Android variants of the JetBrains Compose UI dependencies all point to the AndroidX Compose UI artifacts.
☝️ 2
👍 1
They're not different things. JetBrains Compose UI artifacts are a superset of the AndroidX Compose UI artifacts, not a replacement or alternative.
You can observe this in the Gradle module metadata that is published for each artifact. For example, the base-most Compose UI artifact's module metadata is here: https://repo1.maven.org/maven2/org/jetbrains/compose/ui/ui/1.9.1/ui-1.9.1.module
Its Android variants point to the regular AndroidX artifacts.
Other variants such as UIKit (iOS) and Wasm JS point to JetBrains' own artifacts.
There's also a transition occurring right now where Google is starting to build more variants themselves. For example, the Compose runtime dependency is no longer built at all by JetBrains. Google now builds all variants themselves.
All of that to say, what you describe is not a problem. You are free to depend on JetBrains' artifacts without affecting Android consumers downstream.
thank you color 3
👍 1
true 1
m
Thanks @jw for the explanation and help! That is very good to hear and what we hoped for Currently, when we run ./gradlew androidAppdependencies (androidApp depends on the SDK that uses CMP) we still see some
org.jetbrains.compose
dependencies leaking into the Android target - however - this must be then a configuration issue on our side. Will check that out. Thx again!
i
we still see some
org.jetbrains.compose
dependencies leaking into the Android target - however - this must be then a configuration issue on our side. Will check that out.
It's expected and doesn't conflict with explanation above (thanks Jake!). What you see is most likely "empty" artifacts with dependency to
androidx.*
.
will the compiler translate all
There is no such magic there. I confirm that CMP does NOT re-build and re-publish android artifacts from google. What we do is providing multiplatform "root" metadata with "redirect" to Google's artifacts on Android (see screenshots above). It means that CMP adds no code in addition to
androidx.*
at runtime, but in build time CMP artifacts is in the dependency tree. If it's a real concern for you, I guess
exclude
together with ensuring that all required libraries from
androidx.*
are included with the right version might work. But I'm not sure if this really worth it Please note that it's valid only for forked components. Multiplatform resources for example provides regular library for android without such redirection.