Nucleus

Why Nucleus

Nucleus provides native desktop platform integrations and packaging for Compose Multiplatform apps written in Kotlin.

Kotlin and Compose run on Android, iOS, and the web. On the desktop, Compose Multiplatform renders the UI, but reaching operating-system features has meant working through JNI, the Foreign Function & Memory API, or per-platform native libraries — a different API on each OS. Nucleus provides those platform integrations as Kotlin APIs, together with the packaging and distribution tooling a desktop app needs.

What Nucleus adds to Compose Multiplatform

Compose Multiplatform renders the desktop UI. It does not provide native window decorations, dock menus, system trays, code-signing pipelines, deep links, auto-update, or installers. Nucleus adds these: backend-agnostic Composables on the UI side, and a Gradle plugin plus runtime modules on the platform side.

Each native API keeps its full surface. Windows Toast Notifications, macOS UserNotifications, FreeDesktop StatusNotifierItem, and Win32 ITaskbarList3 each have their own threading model and conventions. Nucleus exposes them through a Kotlin DSL with the same shape on every OS, and the underlying APIs remain accessible when you need them.

What Nucleus provides

  • Native decorated window — a DecoratedWindow that 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, not just Nucleus — is resolved automatically at build time from a curated set, the Oracle repository, and static bytecode analysis, so most native images compile without hand-written reflection config. Switch between them 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.

Compared to Tauri and Electron

Tauri / ElectronNucleus
Language stackJavaScript + Rust + Swift + Kotlin/JavaKotlin
UI runtimeBrowser engine (Chromium / WebView)Compose Multiplatform on Skia GPU
OS callsIPC bridge between languagesDirect, in-process
Native UI integrationWeb view in a windowNative window and widgets via NativeView
Shared with mobileWeb bundleThe same Kotlin module used on Android and iOS

Tauri uses Rust with a JavaScript WebView front end, communicating over an IPC bridge. Electron bundles a browser engine with each app. Nucleus uses Kotlin across the UI, business logic, OS calls, and packaging, running in a single process.

What's next

  • Architecture — the layered model, from your app down to the JDK or GraalVM.
  • Quickstart — build and run a Tao window.
  • Runtimes — choosing between GraalVM Native Image and JVM with an AOT cache.