Comment Nucleus se compare à Compose Multiplatform vanilla — et, secondairement, aux autres stacks desktop.

Nucleus étend Compose Multiplatform pour les équipes qui écrivent déjà du Kotlin et doivent shipper une app desktop — pas seulement dessiner une fenêtre. La comparaison principale est face à Compose Desktop vanilla. Les outils de packaging et les stacks web viennent plus bas pour le contexte.

Nucleus vs Compose Multiplatform vanilla

Compose Multiplatform est la fondation. Nucleus est la couche de production par-dessus : chrome natif, modules OS, packaging élargi, auto-update et pipelines store. La migration est un drop-in.

	Nucleus	CMP vanilla
Langage	Kotlin	Kotlin
UI	Compose + Skia GPU	Compose + Skia GPU
Décorations de fenêtre	Natives (Liquid Glass, Fluent, Yaru, Jewel)	Limitées
APIs OS	40+ modules Kotlin	Légères (`Tray`, `Notification`)
Formats de packaging	18	6 (jpackage)
Auto-update	Intégré (`updater-runtime`)	Aucun
Pipelines store	PKG, MSIX, Snap, Flatpak (+ sandbox)	Pas de chemin dédié
Cold start	~0,2 s (GraalVM) · ~1,0 s (JVM+AOT)	1–2 s
Taille binaire	~40 MB (GraalVM) · ~60 MB (JVM)*	80–120 MB
Forme Gradle	`nucleus.application { … }` (miroir CMP)	`compose.desktop.application { … }`

Guide de décision complet : Nucleus vs Compose Multiplatform vanilla.

Quand rester sur CMP vanilla

Tu n'as besoin que de DMG / MSI / DEB via jpackage.
Tu n'as pas besoin d'auto-update, de canaux store, de packaging GraalVM ni de décorations natives.
Tu possèdes déjà des scripts de signature et d'upload que tu ne veux pas déplacer.

Quand basculer sur Nucleus

Tu veux un packaging prêt pour les stores (Mac App Store, Microsoft Store, Snapcraft, Flathub).
Tu veux l'auto-update, GraalVM Native Image, ou le câblage du cache AOT JDK.
Tu veux des décorations natives et 40+ modules OS sans écrire du JNI par plateforme.
Tu as déjà un projet Compose Desktop et veux une migration drop-in.

Outils de packaging (écosystème JVM)

Comment le packaging Nucleus se compare à jpackage, Conveyor, install4j et les autres — formats, auto-update, signature, CI, stores :

→ Packaging — Nucleus vs le reste

Autres stacks desktop (Electron, Tauri)

Electron et Tauri répondent à une autre question : comment construire du desktop quand mon équipe est JavaScript ? Nucleus répond : comment mon équipe Kotlin shippe le desktop au-dessus de Compose ?

	Nucleus	Electron	Tauri
Langage(s)	Kotlin	JS + Node (+ C++ pour le natif)	JS + Rust
UI	Compose + Skia GPU	Chromium (Blink + V8)	WebView OS
APIs OS	40+ modules Kotlin, mono-process	Modules natifs Node / IPC	Commandes Rust via IPC
Partage mobile	Même Kotlin qu'Android / iOS	Bundle web	Bundle web
Formats de packaging	18	5–7 via electron-builder	5 via tauri-bundler
Cold start	~0,2 s (GraalVM)	2–3 s	< 1 s
RAM au repos	30–120 MB*	200–500 MB	~87 MB*

Choisis Electron quand la vitesse de livraison et le bassin d'embauche JS comptent plus que la RAM ou le look natif. Choisis Tauri quand tu acceptes les WebViews par plateforme et un split Rust/JS pour de plus petits binaires. Choisis Nucleus quand l'équipe est déjà Kotlin et que tu veux Compose de bout en bout avec de vrais outils OS et de shipping.

Mesuré : démarrage, RAM et nombre de process

Même fenêtre Hello-World, quatre stacks, protocole identique sur une machine Windows 11 — temps réel du lancement du process jusqu'au premier handle de fenêtre, et private working set une fois la fenêtre stabilisée.

Hello-World	Stack	Cold start	Warm start	RAM (private WS)	Process
Nucleus (Tao)	Image native GraalVM	~0,17 s	~0,10 s	~30 MB	1
WinUI 3	.NET 9 + Windows App SDK	~0,20 s	~0,28 s	~32 MB	1
Flutter	Dart AOT + Skia	~0,28 s	~0,28 s	~33 MB	1
Tauri	Rust + WebView2	~0,74 s	~0,12 s	~87 MB	7

Le Gestionnaire des tâches sous-estime les apps WebView2. Le process Tauri affiche ~4 MB — la vraie empreinte (~87 MB) vit dans six helpers msedgewebview2.exe. Nucleus est un seul process.
Nucleus se place dans la même classe ~30 MB que WinUI 3 natif et Flutter tout en restant purement Kotlin/Compose.

macOS

Même protocole sur macOS 26 (Apple silicon) — temps réel jusqu'à la première fenêtre à l'écran, et RSS total sur tous les process que l'app lance. Le RSS inclut des pages de frameworks partagées ; comparer uniquement dans le tableau.

Hello-World	Stack	Cold start	Warm start	RAM (RSS, tous process)	Process
Nucleus (Tao)	Image native GraalVM	~0,32 s	~0,20 s	~115 MB	1
SwiftUI	référence native	~0,14 s	~0,14 s	~78 MB	1
Flutter	Dart AOT + Skia	~0,79 s	~0,17 s	~100 MB	1
Tauri	Rust + WKWebView	~0,91 s	~0,19 s	~173 MB	4

Notes

Les chiffres de performance sont typiques d'une app Hello-World. Cold start et RAM réels grandissent avec ce que charge l'app. Nucleus a deux cibles runtime : image native GraalVM pour le cold start et la taille binaire, et JVM + cache AOT pour le débit. Voir performance.

Dans les tableaux de comparaison, les chiffres Electron viennent de benchmarks publics. Les chiffres Nucleus, WinUI 3, Tauri et associés — y compris la RAM Tauri — ont été relevés de première main sur une seule machine Windows 11 (runs tièdes sauf mention) ; voir la section Mesuré. *La RAM Nucleus a été mesurée sur Windows 11 avec un build Hello World ; la taille binaire est l'installateur NSIS avec compression maximale.

Et ensuite

Nucleus vs Compose Multiplatform vanilla — ce que Nucleus ajoute par-dessus CMP.
Packaging — 18 formats vs le reste — comparaison du pipeline de packaging.
Pourquoi Nucleus — narrative produit pour les équipes Kotlin.
Migrer depuis JetBrains Compose Desktop — étapes drop-in.

Comparer