Why Nucleus
What Nucleus adds on top of Compose Multiplatform for Kotlin teams shipping real desktop apps.
Kotlin and Compose already own Android. They reach iOS and the web. On the desktop, Compose Multiplatform renders the UI — but shipping a real product still means native chrome, OS integration, packaging, signing, auto-update, and store pipelines that the default plugin does not provide.
Nucleus is that production layer. Same Compose. Same Kotlin team. The rest of the desktop stack, already built.
The gap Compose Desktop leaves open
Compose Multiplatform is the right UI foundation. It is not a full desktop product stack.
| Vanilla Compose Desktop | Nucleus | |
|---|---|---|
| UI | Compose + Skia | Same Compose + Skia |
| Window chrome | Basic / Material-looking | Native decorations (Liquid Glass, Fluent, Yaru, Jewel) |
| OS APIs | Thin (Tray, Notification) | 40+ Kotlin modules (tray, dock, hotkeys, media, dark mode, …) |
| Packaging | 6 jpackage formats | 18 formats, including store channels |
| Auto-update | None | Built-in (updater-runtime) |
| Signing / CI | DIY | Signing, notarization, reusable GitHub Actions |
| Runtimes | JVM | GraalVM Native Image or JVM + AOT cache |
| Migration | — | Drop-in on the JetBrains Compose plugin |
If you only need a window and a DMG/MSI/DEB, vanilla CMP is enough. The moment you need native look-and-feel, store distribution, auto-update, or real OS integration without writing JNI per platform — that is Nucleus.
Deep dive: Nucleus vs vanilla Compose Multiplatform.
Built for teams that already write Kotlin
Nucleus is not a new language bet. It is for teams that already ship Android (or KMP) and need a desktop surface without hiring a second stack.
- Same hiring pool — Compose skills transfer. No Rust/JS/Electron team required.
- Same codebase path — domain, networking, and much of the UI live in
commonMain. - Same Gradle world — one DSL, hot reload, familiar CI.
- Drop-in migration — rename
compose.desktop.application→nucleus.applicationand keep shipping. See Migrating from JetBrains Compose Desktop.
What Nucleus provides
- Native decorated window — a
DecoratedWindowthat follows macOS/Windows/Linux title-bar conventions, backed by the Tao backend. - Runtime modules — more than 40 modules covering notifications, system tray, global hotkeys, taskbar progress, dark mode, accent colour, dock menus, jump lists, media controls, auto-launch, scheduler, auto-update, system info, and file dialogs. Each is optional and written in Kotlin.
- Two runtimes — GraalVM Native Image produces a self-contained binary (around 40 MB as an NSIS installer with maximum compression, starting in about 0.2 s); JVM with an AOT cache runs on HotSpot for long-running workloads. Reachability metadata — for your third-party libraries too — is resolved automatically at build time. Switch with one Gradle setting.
- 18 packaging formats — DMG, PKG, Exe, MSI, NSIS, NSIS Web, Portable, AppX/MSIX, DEB, RPM, AppImage, RawAppImage, Pacman, Snap, Flatpak, ZIP, TAR, and 7Z, with signing and notarization.
- CI support — reusable GitHub Actions, multi-platform matrix builds, universal macOS binaries, and MSIX bundles.
What's next
- Nucleus vs vanilla Compose Multiplatform — the decision table for Kotlin teams.
- Migrating from JetBrains Compose Desktop — drop-in steps.
- Quickstart — build and run a Tao window.
- Architecture — layers from your app down to the JVM or GraalVM.