Pourquoi Nucleus
Ce que Nucleus ajoute à Compose Multiplatform pour les équipes Kotlin qui shippent de vraies apps desktop.
Kotlin et Compose règnent déjà sur Android. Ils atteignent iOS et le web. Sur le desktop, Compose Multiplatform rend l'interface — mais livrer un vrai produit demande encore chrome natif, intégration OS, packaging, signature, auto-update et pipelines store que le plugin par défaut ne fournit pas.
Nucleus est cette couche de production. Même Compose. Même équipe Kotlin. Le reste du stack desktop, déjà construit.
Le trou que Compose Desktop laisse ouvert
Compose Multiplatform est la bonne fondation UI. Ce n'est pas un stack desktop produit complet.
| Compose Desktop vanilla | Nucleus | |
|---|---|---|
| UI | Compose + Skia | Même Compose + Skia |
| Chrome de fenêtre | Basique / look Material | Décorations natives (Liquid Glass, Fluent, Yaru, Jewel) |
| APIs OS | Légères (Tray, Notification) | 40+ modules Kotlin (tray, dock, hotkeys, média, dark mode, …) |
| Packaging | 6 formats jpackage | 18 formats, y compris les canaux store |
| Auto-update | Aucun | Intégré (updater-runtime) |
| Signature / CI | À construire | Signature, notarisation, GitHub Actions réutilisables |
| Runtimes | JVM | GraalVM Native Image ou JVM + cache AOT |
| Migration | — | Drop-in sur le plugin Compose JetBrains |
Si tu n'as besoin que d'une fenêtre et d'un DMG/MSI/DEB, CMP vanilla suffit. Dès qu'il faut un look natif, de la distribution store, de l'auto-update, ou de la vraie intégration OS sans écrire du JNI par plateforme — c'est Nucleus.
Détail : Nucleus vs Compose Multiplatform vanilla.
Pensé pour les équipes qui écrivent déjà du Kotlin
Nucleus n'est pas un pari sur un nouveau langage. C'est pour les équipes qui shippent déjà Android (ou KMP) et ont besoin d'une surface desktop sans recruter une seconde stack.
- Même bassin d'embauche — les compétences Compose se transfèrent. Pas d'équipe Rust/JS/Electron.
- Même chemin de codebase — domaine, réseau, et une grande partie de l'UI vivent en
commonMain. - Même monde Gradle — un DSL, hot reload, CI familière.
- Migration drop-in — renomme
compose.desktop.application→nucleus.applicationet continue de shipper. Voir Migrer depuis JetBrains Compose Desktop.
Ce que fournit Nucleus
- Fenêtre décorée native — un
DecoratedWindowqui respecte les conventions de barre de titre macOS/Windows/Linux, servi par le backend Tao. - Modules runtime — plus de 40 modules : notifications, system tray, hotkeys globaux, progression barre des tâches, dark mode, couleur d'accentuation, menus dock, jump lists, contrôles média, auto-launch, scheduler, auto-update, infos système et file dialogs. Chacun est optionnel et écrit en Kotlin.
- Deux runtimes — GraalVM Native Image produit un binaire autonome (environ 40 Mo en installateur NSIS avec compression maximale, démarrant en environ 0,2 s) ; JVM avec cache AOT pour les charges longues. Les métadonnées de reachability — y compris pour tes libs tierces — sont résolues automatiquement à la compilation. Une ligne Gradle bascule entre les deux.
- 18 formats d'empaquetage — DMG, PKG, Exe, MSI, NSIS, NSIS Web, Portable, AppX/MSIX, DEB, RPM, AppImage, RawAppImage, Pacman, Snap, Flatpak, ZIP, TAR et 7Z, avec signature et notarisation.
- Prise en charge CI — actions GitHub réutilisables, builds matriciels multi-plateforme, binaires universels macOS et bundles MSIX.
Et ensuite
- Nucleus vs Compose Multiplatform vanilla — le tableau de décision pour les équipes Kotlin.
- Migrer depuis JetBrains Compose Desktop — étapes drop-in.
- Quickstart — construire et lancer une fenêtre Tao.
- Architecture — les couches, de ton app jusqu'à la JVM ou GraalVM.