Pourquoi Nucleus

Partout ailleurs, Kotlin tient toute la plateforme. Sur Android, Kotlin et Compose sont des citoyens de première classe. Sur iOS, Kotlin/Native atteint chaque API UIKit et Foundation, et Compose rend comme une vraie app native. Sur le web, Kotlin/JS et Wasm dessinent des UIs Compose contre toute la surface du navigateur. Sur desktop, on n'avait que la moitié du tableau — on pouvait peindre une fenêtre, mais atteindre l'OS imposait de jongler avec JNI, FFM, des libs natives par plateforme, et une API différente sur chaque OS. Maintenant le desktop aussi.

L'essentiel

• Un langage, tous les écrans — partage le code Kotlin et Compose avec Android, iOS et le web.
• Pas d'IPC, pas de DOM, pas de runtime navigateur — le UI appelle la logique métier directement, même process, même graphe d'appels.
• Plus de 30 modules OS qui enveloppent les APIs natives derrière des DSLs Kotlin ergonomiques.
• Deux runtimes au choix : GraalVM Native Image (démarrage instantané) ou JVM + cache AOT (débit maximal).
• Compose Multiplatform, la stack UI desktop la plus avancée : Skia GPU, type-safe, réactive, hot reload.

La brique manquante de Compose Multiplatform

Compose Multiplatform dessine très bien les pixels sur desktop. En revanche, il ne donne pas les décorations natives, les menus dock, les system trays, le signing, les deep links, l'auto-update ou les installateurs prêts pour les stores. Ces briques, c'est Nucleus qui les empile par-dessus — des Composables agnostiques du backend côté UI, un plugin Gradle et 30+ modules runtime côté plateforme.

Point important : Nucleus ne masque pas les APIs natives — il les rend plus simples que les originales. Windows Toast Notifications, macOS UserNotifications, StatusNotifierItem FreeDesktop, Win32 ITaskbarList3 — chacune est une API épaisse, spécifique à son OS, avec son threading et ses conventions. Nucleus les expose dans un seul DSL Kotlin de même forme sur tous les OS, et rien n'est planqué : chaque capacité est là, chaque échappatoire est documentée.

Un langage contre quatre

Tauri prend Rust pour la perf, puis la rend via un pont JavaScript jusqu'à sa WebView. Electron évite le pont mais paie un navigateur complet par app. Nucleus prend un seul langage de bout en bout. UI, logique métier, appels OS, packaging — même mindset, même graphe d'appels, même debugger.

Ce qu'on obtient concrètement

• Decorated Window natif — un DecoratedWindow agnostique du backend, conforme aux conventions macOS/Windows/Linux, servi soit par AWT (JBR) soit par le nouveau backend Tao.
• Plus de 30 modules runtime — notifications, system tray, hotkeys globaux, progression dans la barre des tâches, dark mode, couleur d'accentuation, menus dock, jump lists, contrôles média, auto-launch, scheduler, auto-update, system info, file dialogs, etc. Tous optionnels, tous Kotlin.
• Deux runtimes — GraalVM Native Image pour un binaire autonome de 38 Mo qui boote en 50 ms, ou JVM + cache AOT pour le débit max de HotSpot sur les charges longues. Une ligne Gradle pour basculer.
• 16 formats d'installateur — DMG, PKG, NSIS, MSI, AppX/MSIX, Portable, DEB, RPM, AppImage, Snap, Flatpak, ZIP, TAR, 7Z. Signés, notarisés, store-ready.
• CI-first — actions GitHub réutilisables, matrices multi-plateforme, binaires universels macOS, bundles MSIX.

Et ensuite ?

• Architecture — le modèle en couches : le app → Nucleus → Compose Multiplatform → KMP → JDK/GraalVM.
• Quickstart — une fenêtre Tao qui tourne en cinq minutes.
• Runtimes — quand choisir GraalVM Native Image plutôt que JVM + cache AOT.