Cross-platform desktop apps

How it works

A native desktop app is written against each platform’s own UI toolkit, so supporting Windows, macOS and Linux means three front ends. Cross-platform frameworks share one front end and differ mainly in what draws it. Electron embeds Chromium and Node.js into the app’s binary. Its main process runs in Node.js, creates windows and handles menus, dialogs and tray icons; each window is a renderer process that shows ordinary HTML, CSS and JavaScript, the same multi-process design as a browser. Because every app carries its own browser, it looks and behaves the same everywhere, but even an empty app is large: Firezone measured about 100 MB for Electron’s default build. Tauri and Wails keep the web front end but use the web view the operating system already has, which Tauri reaches through its WRY library: WebView2 on Windows, WKWebView on macOS and WebKitGTK on Linux. The back end is a native program, Rust for Tauri and Go for Wails, and the page calls it through a message channel (Tauri’s IPC) that the core can filter. A minimal Tauri app can be under 600 KB, but the same HTML now renders in three different engines whose versions depend on the user’s system. Dioxus desktop uses the same system web view through WRY, with the application logic running as native Rust. A third group draws every pixel itself: Flutter compiles Dart to native Windows, macOS and Linux apps with its own widgets, and Dioxus Native renders HTML and CSS on the GPU with its own engine, Blitz, so no web view is involved. Whichever way it is drawn, each platform still gets its own installer (.msi or .exe, .dmg or .app, .deb, .rpm or AppImage), usually built on that platform and signed with that platform’s certificates.

Reach for it when

• One team must ship the same app on Windows, macOS and Linux, and its interface can be built from web technologies or one widget set
• A web team building a desktop client: Electron, Tauri and Wails reuse HTML, CSS and a JavaScript framework
• Small downloads and low memory matter, and you can test on each platform’s web view: a system-web-view framework such as Tauri
• The app must render exactly the same everywhere and use the newest web features on old operating systems: Electron’s bundled Chromium

Think twice when

• The product works as a website or a progressive web app; a desktop wrapper adds installers, updates and code signing for every platform
• Pixel-identical rendering on a system-web-view framework: WebView2, WKWebView and WebKitGTK are different engines, and on Linux the WebKitGTK version depends on the distribution release
• Deep integration with one platform’s look and features, such as a macOS-only utility: the native toolkit is less work than bridging to it

Technologies

Specific products, and what each does differently.

Web front end, native back end

The interface is drawn by the system web view; application code runs as native Rust.

TauriOpen sourceA framework for desktop and mobile apps with a web front end shown in the operating system’s own web view and a Rust core that holds the app’s logic and its access to the system.DioxusOpen sourceA React-like Rust UI framework for web, desktop and mobile from one codebase: Rust runs natively on desktop and phones and as WebAssembly in the browser, with a system web view or its own GPU renderer drawing the HTML and CSS.

Bundled browser engine

Each app ships its own copy of Chromium and Node.js, so it looks and behaves the same everywhere.

ElectronOpen sourceA framework for Windows, macOS and Linux apps written in HTML, CSS and JavaScript, which ships its own copy of Chromium and Node.js inside every app; Visual Studio Code runs on it.