Picking a stack for small desktop apps: Rust, Swift, Tauri, Electron
An honest comparison of Rust GUI toolkits, Swift, Tauri and Electron for small desktop apps: app size, memory, native feel, development speed, platforms, accessibility and updates.
Choosing a stack for a small desktop app is a different question from choosing one for a big product. When the whole app is a single window that does one job, a 200 MB download and a slow first launch are a much larger share of the experience. We make small tools for macOS, Windows and Linux, and we build desktop apps for clients, so this comparison comes up a lot. Here is how we think about Rust, Swift, Tauri and Electron, and when each one makes sense.
A note on the numbers first. Sizes and memory figures for desktop apps depend heavily on what the app does, which libraries it pulls in, whether it ships universal binaries for Apple silicon and Intel, and how you measure. The ranges in the hero chart and below are rough, for a small app, and meant to show orders of magnitude. Measure your own before you make a decision on them.
The four options, briefly
Swift with SwiftUI and AppKit is Apple's own path. The Swift runtime ships with macOS, so a small app does not have to bundle it, and the controls are the real system controls.
Rust with a GUI toolkit means a native binary with the interface drawn by a Rust library such as egui, iced or Slint, or bindings to a platform toolkit like GTK. Most of these draw their own widgets rather than using the operating system's.
Tauri pairs a Rust backend with a web interface rendered by the operating system's own web view: WKWebView on macOS, WebView2 on Windows and WebKitGTK on Linux. Tauri 2, released in 2024, also added iOS and Android targets.
Electron bundles its own copy of Chromium and Node.js with every app. It is what many of the best known desktop apps are built on, and it is the most predictable way to run the same web code everywhere.
Size and memory
This is where the differences are largest and most visible.
An Electron app carries a full browser engine, so even a very small one tends to land somewhere around 80 to 250 MB installed, depending on the platform and packaging. Idle memory for a simple window is commonly 100 MB or more once you add up the main process, the renderer and the helper processes.
Tauri avoids bundling a browser, so small apps are often in the single digit megabytes to low teens. Memory is lower than Electron but not as low as people sometimes expect, because the system web view still runs its own processes, and those count too.
A Swift app on macOS can be tiny, often a few megabytes, because it leans on frameworks already in the operating system. Memory for a simple window is modest.
Rust GUI apps produce a single native binary. Size depends mostly on the toolkit and dependencies, typically a handful of megabytes up to the low tens. Memory is usually low, though toolkits that draw with the GPU have some fixed overhead.
Does size matter for a small tool? We think it does, more than for a big one. If someone downloads a utility to rename files or share a folder, a 150 MB installer feels out of proportion, and they notice.
Native feel and accessibility
Native feel is the hardest thing to measure and the easiest to notice. It is keyboard shortcuts that behave the same as every other app, text fields that support the system spell checker and text services, menus in the right place, correct scrolling physics, window behaviour, dark mode and right to left text.
Swift wins here on the Mac, because it is the real thing. Web based stacks (Tauri and Electron) can get close with care, but the default is a web page in a window, and users can tell. Rust toolkits that draw their own widgets look consistent across platforms, which is good, and look like none of them, which is less good.
Accessibility follows a similar pattern. Native AppKit and SwiftUI controls work with VoiceOver out of the box. Chromium and the system web views have mature accessibility support, so a web interface with proper semantic HTML and ARIA can do well in Electron or Tauri. Rust toolkits vary a lot. Some, including egui, integrate with the AccessKit project to expose their widgets to screen readers. Others are still working on it. If accessibility matters for your app, and it should, check the specific toolkit's current state before you commit rather than assuming.
Development speed and reach
Electron is usually the fastest way to ship something that works on three platforms, especially if the team already writes web code. The ecosystem is huge, the debugging tools are familiar, and the same app behaves almost identically everywhere because it brings its own engine.
Tauri is close behind for web developers. The frontend can be any web framework. The trade is that you depend on three different web engines. Something that renders perfectly in WebView2 on Windows might behave slightly differently in WebKit on macOS or in WebKitGTK on Linux, so you test more.
Swift is fast if you are building for Apple platforms only. SwiftUI in particular makes small interfaces quick to write. It does not help you on Windows or Linux in any practical way for GUI work.
Rust GUI toolkits are the slowest to build interfaces in, for most teams. The language is strict, the toolkits are younger, and layout and styling take more code than in HTML and CSS. In return you get a fast, small binary with no web engine, and business logic that is easy to share with a command line version or a server.
Our own apps all target macOS, Windows and Linux, some as a single binary and some as a desktop app with a command-line twin, and the right stack has not been the same for all of them. A Mac-only utility and a tool that has to feel at home on Windows and Linux are different jobs.
Updates, signing and distribution
Whatever you pick, small apps still need the boring parts, and they take longer than people expect.
- Signing. On macOS, apps distributed outside the App Store need a Developer ID signature and notarization by Apple, or Gatekeeper will warn users. On Windows, signed installers build reputation with SmartScreen faster than unsigned ones.
- Updates. Swift apps outside the App Store commonly use Sparkle. Tauri has an updater plugin that checks signed update manifests. Electron apps typically use electron-updater or the built-in autoUpdater. Rust GUI apps usually need you to build or pick an updater yourself.
- Security updates. Electron apps ship their own Chromium, so browser security fixes only reach users when you ship a new version. Tauri and Swift apps get web view and framework fixes through operating system updates.
That last point is easy to overlook. With Electron, keeping up with Chromium releases is part of the job for as long as the app exists.
When each one makes sense
Here is the short version of how we would decide for a small app today:
- Mac only, and it should feel like part of the system: Swift. There is no real competitor.
- Three platforms, a web team, and an interface with lots of text, forms or lists: Tauri, as long as you can test on all three web engines.
- Three platforms, a complex interface, and you need it to behave identically everywhere: Electron. Accept the size, and plan for regular Chromium updates.
- A tool where the core work is heavy (file processing, networking, parsing) and the interface is simple: Rust, with a toolkit whose accessibility you have checked. Or Rust for the core and a thin native interface on each platform, which costs more but gets the best of both.
None of these is wrong. The more common mistakes are about fit: a two-screen utility shipping a whole browser, or a team learning a new language and a young GUI toolkit at the same time as they learn the problem. If you are planning a desktop app and want a second opinion on the stack, that is the kind of question we answer in our custom development work. You can also see the small tools we have made ourselves on our desktop apps page, and judge for yourself.