Stack Guide
What to build a desktop app with in 2026
Desktop is one of the few places where the framework choice is visible to the user: it shows up as download size, as memory in Activity Monitor, and as how long the window takes to appear. This guide picks a default, names the specific cases where the heavier option is still correct, and covers signing, notarization, and updates - the work that turns a build into something people can install.
About 6 min read. Recommendations verified August 2026.
The recommended desktop stack
Tauri 2 as the shell, your existing web frontend inside it, and Rust only where you actually need the operating system. Every layer here has a first-party plugin, which is the difference between a weekend and a month.
| Layer | Pick | Why |
|---|---|---|
| Shell | Tauri 2 | Uses the system WebView instead of bundling Chromium, so installers land in single-digit megabytes and the same project also targets iOS and Android. |
| Frontend | React 19 on Vite | Tauri is framework agnostic, so bring what your team writes. Svelte 5 is the lighter option and matches the spirit of the stack. |
| Native layer | Rust commands | You write Rust only for filesystem, process, and OS work exposed to the frontend as typed commands. Most apps end up with a few hundred lines. |
| Local storage | SQLite | The official SQL plugin gives you a real database on disk. Use the store plugin for preferences and the keychain for secrets, never localStorage. |
| Auto-update | tauri-plugin-updater | Signs each release with a dedicated updater key, separate from your OS code-signing identity, and reads a static latest.json you can host anywhere. |
| macOS signing | Developer ID | $99 a year. Sign, notarize through the App Store Connect API, then staple the ticket. Skip it and Gatekeeper tells users your app is damaged. |
| Windows signing | Azure Trusted Signing | Cheaper than a traditional EV certificate and avoids the hardware token. An EV certificate still buys instant SmartScreen reputation if you can afford one. |
| Packaging | Tauri bundler | Produces .dmg and .app on macOS, NSIS and MSI on Windows, and .deb, .rpm, and AppImage on Linux from one command. |
| Release automation | tauri-action | A matrix build across macOS, Windows, and Linux runners that signs, bundles, and attaches every artifact plus the updater manifest to a GitHub release. |
| Crash reporting | Sentry | Desktop crashes are invisible unless you collect them. Capture both the WebView errors and the Rust panics, and ask before sending anything. |
The verdict
Start with Tauri 2. Move to Electron only when you hit a specific, named blocker from the list below - not preemptively, and not because a benchmark said so.
The size and memory gap is real, and it is large
Electron bundles Chromium and Node with every copy of your app. Tauri does not - it renders in WKWebView on macOS, WebView2 on Windows, and WebKitGTK on Linux, and compiles your backend to a native Rust binary. The consequences are not subtle. Tauri's own floor for a minimal application is under 600 KB; realistic apps ship installers in the single-digit megabytes, against 80-200 MB for the Electron equivalent. Idle memory runs roughly 30-100 MB versus 150-400 MB.
That gap is why Tauri has been the fastest-growing option in the category since v2 shipped, with public repository counts up around 55 percent year over year. It is also why the honest caveat matters: you are testing against three different WebView engines, not one. A CSS feature that works in Chrome may not work in the WebKitGTK build on an older Ubuntu, and you will find out from a user, not from CI.
Electron's answer is that it ships the same Chromium everywhere, which is worth 150 MB to plenty of teams. Slack, VS Code, Discord, and Figma's desktop app all made that trade deliberately. If your app leans on WebRTC, WebGL, heavy canvas work, DRM video, or any browser feature where a rendering difference is a support ticket, one guaranteed engine is a feature and not bloat.
When something other than Tauri wins
Electron
Pick it when you need one guaranteed Chromium on every platform, when you depend on Node native modules with no Rust equivalent, or when your team has zero Rust appetite and a deadline. The ecosystem is genuinely unmatched: electron-builder, electron-updater, Squirrel, crash reporting, and a decade of answered questions for every OS integration you can name.
Native Swift and SwiftUI
Pick it when the Mac is the product. Menu bar utilities, document apps, anything that needs to feel indistinguishable from Apple's own software, or anything selling on the Mac App Store to a design-literate audience. You give up every other platform, and in exchange you get the fastest, smallest, most native result available.
A web app plus a PWA install
Pick it when the only reasons you wanted desktop were a dock icon and offline caching. Zero install friction, zero code signing, zero release engineering, and you keep shipping daily. You give up filesystem depth, background processes, native menus, and global shortcuts - check that list honestly before you build a shell.
Shipping checklist before your first public build
Every item here has bitten a real project. None of it is optional if strangers will install the app.
- Code sign on both platforms. An Apple Developer ID Application certificate for macOS, plus notarization and stapling for anything distributed outside the App Store. On Windows, sign with Azure Trusted Signing or an EV certificate - an unsigned installer triggers a SmartScreen block that most users never click through.
- Keep the updater key separate. Tauri's updater signature is its own keypair, unrelated to your OS signing identity. Store the private key and its password as CI secrets, back them up somewhere you will still have in three years, and never rotate them casually - clients that trust the old key stop updating.
- Test the update path, not just the install. Build the previous version, install it, then publish the new one and confirm the running app actually finds, downloads, verifies, and restarts into it. This is the single most commonly broken part of a desktop release.
- Build on all three runners. Cross-compiling desktop apps is more trouble than a GitHub Actions matrix across macOS, Windows, and Linux. Sign macOS builds on a macOS runner. Tie it into your CI/CD pipeline so a tag produces every artifact.
- Decide on stores early. The Mac App Store means sandboxing, entitlements, and Apple's cut; the Microsoft Store means MSIX packaging. Direct download plus auto-update is simpler and is what most developer-facing tools do. Choosing later means re-architecting file access.
- Collect crashes from day one. Wire error monitoring into both the WebView and the Rust side before launch. Desktop users do not file bug reports; they uninstall.
Desktop app questions, answered
Is Tauri ready to replace Electron in 2026?
For most new apps, yes. Tauri 2 shipped mobile targets, a stable plugin system, and a permissions model, and adoption has grown faster than any competitor in the category. The remaining gaps are ecosystem depth and the fact that you test against three WebView engines rather than one bundled Chromium. Existing Electron apps with working release infrastructure rarely have a good business reason to port.
Do I need to know Rust to build a Tauri app?
Not to start. The frontend is ordinary HTML, CSS, and JavaScript, and the official plugins cover filesystem access, dialogs, notifications, shell commands, SQL, and the updater without writing any Rust yourself. You need Rust the first time you want something no plugin covers, and that is usually a small typed command rather than a subsystem. Budget a week of learning if nobody on the team has touched it.
How much smaller is a Tauri app than an Electron app?
Roughly an order of magnitude. A minimal Tauri app can come in under 600 KB and realistic ones ship installers in the single-digit megabytes, against 80-200 MB for a comparable Electron build. Idle memory is the more important number day to day: around 30-100 MB for Tauri versus 150-400 MB for Electron, because Electron runs its own Chromium instead of the WebView the operating system already has loaded.
Should I distribute through the app stores or direct download?
Direct download with auto-update for developer tools and anything you want to ship weekly, because you avoid review delays, sandbox restrictions, and the store's revenue cut. Use the Mac App Store when your audience is consumers who expect to find software there, and accept that sandboxing and entitlements will constrain how your app touches the filesystem. Decide before you write the file-access code, not after.
Where to go next
The full head-to-head lives in Tauri vs Electron. Pick what renders inside the shell in the frontend framework directory, and if the same product needs phones too, Tauri 2's mobile targets and the mobile app stack are the two routes worth comparing. Shipping a companion terminal command? The CLI tool stack covers that release pipeline.