This day; the once-dry lakebeds of the Kotlin plai...

# compose-desktop

[darkmoon_uk]

This day; the once-dry lakebeds of the Kotlin plains surge with tears of joy... our joy,
Night after night of frustration, years of hurt... we are finally at the promised land:

kodee loving K K ✨ 💬 📢 commonMain `@Preview`s WORK in IntelliJ ✨K K kodee happy

I can't believe it, I feel high... drunk... elated... all at the same time, it's too much.
Whoever made this happen, you are champions of the universe, you are our messiahs.

Here; here is the forbidden knowledge that must now be committed in stone, so that future tech-archaeologists can piece-together what this moment meant, for those blessed enough to live it:

kotlin = "2.1.21"
compose = "1.9.0-beta01"
viewmodel-compose = "2.9.1" (must be latest to compile vs Compose)

Android, Desktop targets (and an iOS in my case)

compose.dependencies.uiToolingPreview in commonMain
compose.dependencies.uiTooling in both androidMain and jvmMain

IntelliJ IDEA 2025.1.4.1 (Ultimate Edition)

[darkmoon_uk]

image.png

[Chris Sinco [G]]

And they say hot reload is all you need 😅

[Arjan van Wieringen]

I might be wrong, but I got the feeling that you were really waiting for this feature

[zsmb]

I've put this the info about CMP previews into a quick blog post to make it more visible:

https://zsmb.co/compose-multiplatform-preview-setup/

[Guilherme Delgado]

btw: this also works with Android Studio Narwhal Feature Drop | 2025.1.2 RC 1 (and with kotlinxCompose = "1.8.2")

[darkmoon_uk]

...also tested working with Kotlin 2.2.0 👌

[Guilherme Delgado]

@zsmb in your article you say that the first step is to Make sure that you have an Android target in your module. Do you mean import the "com.android.library" gradle plugin? Because I do not have an kotlin { androidTarget() ... and it works 🙌

android {
    namespace = ...
    dependencies { debugImplementation(compose.uiTooling) }
}

[zsmb]

@darkmoon_uk Kotlin 2.2 should not be a requirement, for example if I downgrade a fresh wizard project to 2.0 it continues working with previews in common code.

Although there could always be bugfixes in newer versions that a specific project might depend on somehow.

[zsmb]

@Guilherme Delgado Does it make sense to apply the Android plugin but not have an Android target in the module in any scenario? I don't see what that use case would be.

I'd also expect previews to potentially stop working in that case, but that's kind of secondary.

[Guilherme Delgado]

In this module setup:
• androidApp (depends on shared-ui)
• browserApp (depends on shared-ui)
• desktopApp (depends on shared-ui)
• iosApp (depends on shared-ui)
• shared-ui
Modules browserApp desktopApp and iosApp define a “override screens” within their respective targets — for example, SplashScreenWasm or SplashScreenDesktop , with different animations/layouts (and internal composables). The shared-ui will have these targets.

In contrast, androidApp doesn’t require such a “override screens” and instead directly invokes the public composables from commonMain. Working example here.

[okarm]

Now if only @sample displayed the code sample instead of //unresolved, we would be 90 % towards global utopia!