Krate
The comparison
| Question | Electron | Tauri | Flutter | Qt | Krate |
|---|---|---|---|---|---|
| What you ship | A package per OS | A bundle per OS | A build per OS | A build per platform | One .krate file |
| What the user installs | Your package | Your package; WebView2 on older Windows | Your package; VC++ redistributables on Windows | Your app with Qt's libraries | The Krate runtime, once |
| Per-OS builds | Yes; some installers only build on their own OS | Yes; macOS bundles on a Mac, MSI on Windows | Yes, with each OS's toolchain | Yes, each platform's environment | No; one build |
| Signing | Sign and notarize per OS | Sign and notarize per OS | Notarize on macOS; signed MSIX on Windows | macdeployqt can sign for notarization | None per OS for the app file |
| Sandbox and permissions | Renderers sandboxed; main process not | Capabilities for the frontend; core unconstrained | App Sandbox on macOS builds | OS consent APIs; no Qt sandbox | Whole app starts with no file or network access |
| App languages | JavaScript, HTML, CSS | Web frontend, Rust core | Dart | C++, QML, Python | Rust, or built with AI |
| Phones | No | Yes | Yes | Yes | Not yet |
| Maturity | Established; latest three majors supported | Stable v2; v3 in alpha | Stable, 3.47 | Qt 6.12, September 2026 | Young, 0.5.4 |
Sources: Electron distribution, signing and sandbox; Tauri distribution, security and webviews; Flutter desktop, macOS builds and platforms; Qt deployment, permissions and platforms. Wails and Neutralinojs are on the Electron alternatives page.
Three questions that decide it
- Do you have a web codebase you want to keep? Then Electron or Tauri. Flutter, Qt and Krate each want their own interface code.
- Do you need phones from the same project? Then Flutter, Qt or Tauri. Krate and Electron are desktop only.
- Do you want to hand people one file for every desktop? Then Krate. Every other option here produces a separate build for each operating system.
A fourth question sits under all of them: who decides what the app may touch? In most frameworks the developer decides. In Krate the person running the app sees what it asks for and grants it, and the runtime enforces that.
Signing and installers, whichever you pick
A native installer is signed for each system. On macOS, software distributed with a Developer ID must be notarized by Apple (Apple). On Windows, unsigned apps show a SmartScreen warning, and new signed apps can still warn until they build reputation (Microsoft).
A .krate file is not a native installer, so there is no per-OS signing of the app. The Krate runtime itself is installed once, and on macOS it is signed and notarized by Apple. More on the code signing page.
When to pick something else
- You need iOS or Android: Flutter, Qt or Tauri.
- You need a mature accessibility stack or enterprise widgets: Qt or Electron.
- You want to keep an existing web codebase: Electron or Tauri.
- Your team writes C++, Dart or JavaScript and does not want Rust or AI-written code: Qt, Flutter or Electron.
Pick Krate when one sandboxed file for every desktop matters more than those. The same .krate files pass automated checks on macOS, Windows and Linux in CI: 10 apps on all three at Krate 0.5.4. The limits page lists what Krate cannot do yet.
Questions
What is the best cross-platform desktop app framework?
It depends on what you ship. For a web codebase, Electron or Tauri; for phones too, Flutter, Qt or Tauri; for one sandboxed file on every desktop, Krate.
Which framework needs no build per operating system?
Krate: you build one .krate file and the runtime on each system opens it. The others produce a build for each operating system.
Which frameworks avoid a browser engine?
Flutter and Qt draw their own interface, and so does Krate's runtime. Electron bundles Chromium, and Tauri uses the system WebView.
Is Krate production ready?
Krate is young, at 0.5.4. The capability boundary is enforced, and the limits page is explicit about what is missing; it does not yet claim hardening against deliberately hostile code.