Skip to content

✍️ 필사 모드: Desktop App Frameworks 2026 — Tauri, Electron, Wails, Compose, MAUI, Flutter, Qt, Slint: A Category-Wide Comparison

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Prologue — "Desktop Is Dead" Was Wrong

In the mid-2010s it looked like mobile apps would swallow every screen. The 2026 reality is different. Developer tools (VS Code, Cursor, JetBrains), design tools (Figma desktop, Affinity), collaboration tools (Slack, Discord, Notion, Linear), security tools (1Password, Bitwarden), media tools (OBS, Reaper, DaVinci Resolve) — the desktop is the primary surface for all of them. Web apps are supporting cast, mobile is a notification channel, and real work happens on the desktop.

So "how should we build a desktop app" is a hot question again. Hotter because the options have multiplied. Electron, Tauri, Wails, Neutralino, Compose Multiplatform, .NET MAUI, Flutter desktop, Qt/PySide, Slint, Lazarus, GTK with various bindings — eleven serious candidates in one category, each insisting on a different trade-off.

This post puts the whole category on one screen. There's an earlier post comparing Tauri 2 vs Electron one-on-one — that was a duel. This is the wider map: the web-tech camp vs the native-tech camp, single-OS vs multi-OS ambitions, the natural selection that team language imposes, and the answer to "why did Linear, Cursor, Bitwarden, and Affinity all pick different tools?"

The one-liner: there is no "best desktop framework." Your team's language, your target OS, your performance needs, and your bundle budget cross at exactly one point, and that's where the right tool lives. The goal here is to help you find that intersection fast.


1. The Real Selection Axes

Framework comparisons often fail because they fight a 1-D battle of "which is better." Real desktop framework selection is at least 4-D.

1.1 Native vs Webview Rendering

How you draw the UI is the first fork.

  • Webview-based: HTML/CSS/JS draws the UI; the OS webview (Chromium, WebView2, WebKit) or a bundled Chromium puts pixels on the screen. Electron, Tauri, Wails, Neutralino sit here.
  • Native rendering: Either OS-native widgets (Win32, Cocoa, GTK) or a custom renderer (Skia, Qt's own engine) draws the pixels. Qt, Compose, MAUI, Flutter, Slint, Lazarus belong here.

Webview gives you the giant web-developer talent pool and fast UI iteration. Native wins on startup time, memory, keyboard shortcuts, accessibility, and tray integration. Nothing does both — you have to choose.

1.2 Team Language Is the Strongest Force

Long-term, the strongest force is the language the team already speaks.

  • TypeScript/JavaScript team → Electron, Tauri, Wails (frontend is web), Neutralino, React Native for macOS/Windows.
  • Rust team → Tauri, Slint, gtk-rs, Iced, egui.
  • Go team → Wails, Fyne, gioui.
  • C# team → .NET MAUI, WinUI 3, Avalonia, Uno Platform.
  • Kotlin/Java team → Compose Multiplatform, JavaFX, Swing (legacy).
  • Dart team → Flutter desktop.
  • C++/Python team → Qt, PySide, wxWidgets.
  • Pascal team → Lazarus / Free Pascal.

Change the language and you change hiring, tooling, build pipelines, everything. So "can the existing team get a build green in a week" is in practice the strongest filter.

1.3 Target Platform Scope

  • Windows only → WinUI 3, WPF, Win32 (legacy). Narrowest and fastest.
  • macOS only → SwiftUI, AppKit. App Store-friendly, native system API access.
  • Three desktops (Win/macOS/Linux) → Electron, Tauri, Wails, Qt, Compose, Flutter, MAUI (Linux weak).
  • Desktop plus mobile → Tauri 2, Flutter, Compose Multiplatform, MAUI, React Native plus Capacitor.
  • Embedded too → Slint, Qt, LVGL (a different category entirely).

If "ship desktop and mobile at the same time" is the requirement, the candidate list narrows fast. Roughly Tauri 2, Flutter, Compose Multiplatform, MAUI.

1.4 Bundle Size vs Performance Ceiling vs Consistency

Three things trade against each other. No tool satisfies all three.

PriorityBest tools
Minimum bundle sizeTauri, Wails, Slint, Lazarus
Maximum performance ceilingQt, Slint, native (SwiftUI/WinUI)
Pixel-perfect consistency across all OSesFlutter, Compose (own renderer)
Natural system look and feelTauri (system WebView), Qt, Compose (desktop themes)
Development speed (UI changes are fast)Electron, Tauri, Flutter

This matrix is the first arrow. "What do we care about most?" — that single question shrinks the candidate set to three or fewer.


2. The Web-Tech Camp — Carrying Chromium's Weight

Four contenders that use a webview. We put them side by side.

2.1 Electron — Still the Elephant

Electron started in 2013 with GitHub's Atom editor. Thirteen years later in 2026 it's still the most-used desktop app framework on the market. VS Code, Discord, Slack, Notion, Postman, 1Password, Obsidian, Linear, Figma desktop — eight of those nine are Electron (Linear is reportedly evaluating Tauri).

Strengths:

  • Maturity: thirteen years of bug fixes, thirteen years of packages, thirteen years of Stack Overflow answers.
  • Compatibility: it carries a full Chromium, so it looks the same everywhere. CSS, WebGL, WebRTC, service workers, codecs — all identical.
  • Massive ecosystem: electron-builder, electron-forge, spectron, auto-updater — enterprise-grade tooling abounds.

Weaknesses:

  • Bundle size: 150 to 300MB. Discord's 90MB is compressed; 200MB-plus lands on disk.
  • Memory: a full Chromium copy in RAM. An empty app starts at 100MB.
  • Startup time: Chromium init plus V8 boot = one to three seconds.

In 2026 Electron is around v33/34, tracking Chromium 130-something. Stable branch releases, ASAR packaging, and improved macOS code-signing integration are the recent themes.

2.2 Tauri 2 — Top of the System-Webview Camp

A year and a half after Tauri 2.0 GA in October 2024. As of 2026, Tauri holds the largest share inside the system-webview camp. Big-tech apps haven't migrated, but incomplete surveys put thirty to forty percent of new projects on Tauri.

Distinctive features:

  • System webview: WebView2 (Edge) on Windows, WKWebView (Safari) on macOS, WebKitGTK on Linux. No bundled Chromium.
  • Bundle size: 10 to 40MB, roughly one tenth of Electron.
  • Rust core: backend commands are Rust; the IPC boundary is explicit.
  • Mobile support: iOS and Android since 2.0. Mobile is less mature than 1.x's desktop story, though.

Real shadows:

  • WebView fragmentation: WebKitGTK on Linux trails Edge/Chromium on Windows by a lot — CSS features, codecs, JS engines.
  • Rust learning curve: there's always a moment when you have to write a backend command in Rust. That hurts a frontend team.
  • Ecosystem depth: nowhere near thirteen years of Electron packages.

Full deep-dive in the earlier Tauri 2 vs Electron post. Here Tauri is one player in the bigger lineup.

2.3 Wails — Go's Answer

Wails lets you write the backend in Go with a web-tech frontend. People call it "Tauri for Go" but the differences matter.

  • Language: Tauri is Rust, Wails is Go. Go's build speed and simplicity are the appeal.
  • System webview: same strategy as Tauri — WebView2, WKWebView, WebKitGTK.
  • 2026 versions: Wails v2 is stable, v3 is in alpha/beta. v3 adds multi-window, a new menu API, and better IPC.
  • Bundle: 10 to 30MB, in Tauri territory.

Natural pick for a Go team. If your backend infrastructure is in Go and you want the desktop client in the same language, Wails is the path.

2.4 Neutralino — The Lightest Option

Neutralino doesn't even bundle Node.js. A small C++ runtime hosts the app and the webview executes the JS directly.

  • Bundle: 2 to 5MB. The minimum in the category.
  • Backend: no separate backend language; system APIs are exposed as JS functions Neutralino provides.
  • Targets: Win, macOS, Linux, Chrome OS.

Genuinely light, but awkward when you need real backend weight (file indexing, encryption, local DB). Best for small tools and tray utilities.

2.5 The Web Camp at a Glance

ItemElectronTauri 2WailsNeutralino
Backend languageNode.jsRustGoNone (JS only)
WebviewBundled ChromiumSystem webviewSystem webviewSystem webview
Bundle size150~300MB10~40MB10~30MB2~5MB
Empty-app memory100~150MB30~60MB30~60MB10~30MB
MobileNoiOS/Android (2.0+)ExperimentalNo
Ecosystem maturityfive starsfour starsthree starstwo stars
Learning curveLowMedium (Rust)Medium (Go)Low

3. The Native-Tech Camp — Drawing Pixels Directly

No webview. Either a custom renderer or OS-native widgets put pixels on the screen. Higher performance ceiling, faster startup — but a steeper learning curve.

3.1 Qt / PySide — The 35-Year Giant

Qt started in 1991. Thirty-five years old. Written in C++, with Python bindings (PySide6, PyQt6). The de facto number one of the desktop-native camp.

Real users: Affinity Photo/Designer/Publisher (all Qt), VirtualBox, the entire KDE desktop environment, Tesla's vehicle cluster UI, parts of Adobe Substance Painter, Maya's interface, OBS Studio.

Strengths:

  • Maturity: thirty-five years. Every OS, embedded, mobile too.
  • Widget library: Qt Widgets, Qt Quick (QML), Qt 3D — any UI you can imagine.
  • Performance: own renderer with both CPU and GPU acceleration.
  • Commercial support: The Qt Company's paid license plus LTS.

Weaknesses:

  • Licensing: GPL/LGPL/commercial triple license. Commercial seats run several thousand dollars per developer per year.
  • C++ barrier: PySide is a workaround but UI building still lives in Qt's widget paradigm.
  • Bundle size: 30 to 80MB; smaller with dynamic linking.

In 2026 we're at Qt 6.8 LTS. QML is increasingly the default, and Qt for Python (PySide6) is stable.

3.2 Compose Multiplatform — JetBrains's Bet

JetBrains's UI framework built on Kotlin Multiplatform. It extends Android's Jetpack Compose to desktop and iOS. Desktop reached stable GA in 2024/2025; iOS is transitioning from beta to stable.

Strengths:

  • Language: Kotlin. Android developers move to desktop with no language change.
  • Declarative UI: React-like paradigm. UI as a function.
  • Renderer: Skia-based. Same pixels on every OS.
  • JetBrains uses it themselves: parts of IntelliJ, Toolbox.

Weaknesses:

  • JVM dependency: bundling the runtime adds 50 to 150MB. GraalVM native image trims it down but is fiddly.
  • Desktop-native look is weak: Material Design by default; doesn't quite feel native to desktop.
  • iOS is still beta: less mature than the desktop story.

Unambiguous pick for a Kotlin team. For other teams, hiring is the variable.

3.3 .NET MAUI — Xamarin's Heir

Microsoft's successor to Xamarin.Forms — a cross-platform UI framework. GA'd in 2022, stabilized through 2023 and 2024, real adoption since 2025.

Strengths:

  • Language: C#. Deep ties into the Microsoft ecosystem.
  • Targets: Windows, macOS, iOS, Android. (Linux is not officially supported; there's a community backend.)
  • XAML UI: friendly territory for WPF veterans.
  • Visual Studio: integrated debugging and design.

Weaknesses:

  • Weak macOS story: macOS via Mac Catalyst — not truly native.
  • No Linux support: you can't hit all three desktops.
  • Stabilization time: the first two to three years post-GA felt like beta.

Reasonable when Windows is the focus and mobile ships alongside. Disqualified if Linux desktop users matter.

3.4 Flutter Desktop — Google's Ambition

Flutter started on mobile and grew to desktop. Stable desktop in 2022, taken seriously from 2023 onward.

Strengths:

  • One codebase: iOS, Android, web, Windows, macOS, Linux — all of them.
  • Skia renderer: pixel-level consistency.
  • Development speed: hot reload, a powerful widget library.
  • Dart: shallow learning curve, AOT-compiled.

Weaknesses:

  • Desktop UX still awkward: mobile heritage means shortcuts, menu bars, and multi-window are weak.
  • Bundle size: 30 to 80MB. Not small.
  • Plugin gap: fewer desktop plugins compared with mobile.

Real users: BMW's in-car infotainment, various internal tools. Serious consumer desktop apps are still rare.

3.5 Slint — Rust-Native UI

Slint (formerly SixtyFPS) is a Rust-written native UI framework. 1.0 in 2024, 1.x stabilizing through 2025 and 2026. Targets embedded and desktop both.

Strengths:

  • Bundle: 1 to 5MB. Class-leading.
  • Performance: locked sixty frames per second with GPU acceleration.
  • Slint language: its own DSL to declare UI, binding to Rust/C++/JS.
  • Embedded-friendly: works in tight RAM environments.

Weaknesses:

  • Tiny ecosystem: one-hundredth the size of Qt's.
  • Licensing: GPL/Royalty-Free/Ambassador/Commercial. Commercial use means a license conversation.
  • Sparse widget library: not the rich library you'd expect.

Best for small desktop tools, embedded UIs, or teams that want consistent Rust across the stack.

3.6 Lazarus / Free Pascal — The Survivor

The open-source heir of Delphi, in Pascal. Started in 1999. Still actively developed in 2026.

Strengths:

  • Single binary: 5 to 15MB with no dependencies.
  • Speed: native compilation, instant startup.
  • Compatibility: Delphi code builds with very few changes.
  • Every OS: Win, macOS, Linux, BSD.

Weaknesses:

  • Pascal hiring is hard: a thin pipeline of new talent.
  • UI trends lag: VCL lineage, light on modern design systems.
  • Small community: active but small.

Reasonable for porting legacy Delphi code, for small desktop tools, or when you already have a Pascal team.

3.7 GTK plus bindings (gtk-rs, Vala, PyGObject)

GTK is GNOME's widget library, born inside GIMP. Thirty years old. Usable from many languages — Rust (gtk-rs), Vala, Python (PyGObject), C.

Strengths:

  • GNOME integration: native look on Linux.
  • Small bundle: smaller still when GTK is already on the system.
  • Variety of bindings: Rust, Vala, Python, C.

Weaknesses:

  • Awkward on macOS/Windows: the look doesn't fit those OSes.
  • GTK4 migration ongoing: the ecosystem is straddling GTK3 and GTK4.

Natural pick for Linux-first tools. Cross-platform is awkward.

3.8 The rest of the category

  • Avalonia (.NET): WPF-like XAML, cross-platform. Better Linux support than MAUI.
  • Uno Platform (.NET): WinUI XAML on every OS — including WebAssembly.
  • Iced / egui (Rust): small-tool Rust UI options.
  • Fyne / gioui (Go): native UI from the Go camp.
  • wxWidgets: C++ wrapping OS-native widgets.

There are too many to cover all of them. The twelve above are the ones worth seriously evaluating in 2026.


4. The Decision Matrix — Who Fits Where

Eleven candidates plotted on four axes.

ToolLanguageRenderingBundleDesktop OSMobileBest scenario
ElectronTS/JSBundled Chromium150~300MBWin/macOS/LinuxNoBig team, fast UI iteration, compatibility required
Tauri 2Rust + webSystem webview10~40MBWin/macOS/LinuxiOS/AndroidGreenfield project, small bundle, Rust-capable team
WailsGo + webSystem webview10~30MBWin/macOS/LinuxExperimentalGo-backed team, single language
NeutralinoJSSystem webview2~5MBWin/macOS/LinuxNoTray utility, small tool
Qt / PySideC++/PythonOwn renderer30~80MBAll OSes plus mobileiOS/AndroidGraphics/CAD, embedded, performance ceiling
Compose MPKotlinSkia50~150MBWin/macOS/LinuxiOS/AndroidKotlin/Android team extending to desktop
.NET MAUIC#Native50~120MBWin/macOSiOS/AndroidWindows-first plus mobile
FlutterDartSkia30~80MBWin/macOS/LinuxiOS/AndroidTruly single codebase
SlintRust/DSLOwn renderer1~5MBWin/macOS/LinuxEmbeddedMicro tools, embedded UIs
LazarusPascalNative5~15MBAll OSesNoDelphi code port, small tools
GTK + RustRustGTK5~20MBLinux-firstNoGNOME integration, Linux-first

How to read: pick a "language we can ship in" column and a "target OS" column. Rows where the intersection isn't empty are your shortlist. It usually narrows to two or three.


5. Real Examples — What the Big Apps Picked

5.1 VS Code, Cursor, Windsurf, Zed

  • VS Code: Electron. Code OSS base. Microsoft does heavy in-house optimization on top.
  • Cursor: Electron plus a VS Code OSS fork. The choice was "reuse VS Code's codebase," and Electron came along for free.
  • Windsurf (Codeium): Electron plus a VS Code OSS fork. Same reason.
  • Zed: a custom Rust framework called GPUI. Rejected Electron and built its own GPU-accelerated UI from scratch.

Lesson: reusing the VS Code codebase means Electron. Starting from scratch means freedom.

5.2 Discord, Slack, Teams

  • Discord: Electron from day one, thirteen years ago.
  • Slack: Electron. A macOS-native attempt in 2020/2021 failed and they reverted to Electron.
  • Teams: Electron plus WebView2. Rumors of a React Native for Windows migration; in the end it didn't happen.

Lesson: for big-company big apps the migration cost is too high. Once Electron, still Electron.

5.3 1Password, Bitwarden

  • 1Password: Electron since 8.x. (Earlier 7.x was native.)
  • Bitwarden: Electron desktop plus a web vault plus native mobile.

Lesson: even security apps picked Electron. Compatibility and dev velocity outweighed the "Electron is scary for security" reaction.

5.4 Linear, Figma, Notion

  • Linear: Electron desktop. Reportedly evaluating Tauri in 2025; outcome unclear.
  • Figma desktop: an Electron wrapper. Essentially a web app.
  • Notion: Electron desktop. Notion Calendar (formerly Cron) was also Electron.

Lesson: web-first companies land on Electron naturally. The same code shipped as desktop.

5.5 Affinity, Adobe, DaVinci

  • Affinity Photo/Designer/Publisher: Qt. One codebase for every OS.
  • Adobe: in-house C++ frameworks, varying by app. Photoshop is proprietary; some use CEF/Electron.
  • DaVinci Resolve: in-house C++ plus parts of Qt.

Lesson: graphics tools where pixel performance matters stick to Qt or proprietary native.

5.6 OBS, Reaper, Audacity

  • OBS Studio: Qt.
  • Reaper: an in-house C++ framework (WDL/IPlug). Extremely small bundle, extremely fast startup.
  • Audacity: wxWidgets.

Lesson: media tools pick native because of performance and latency.

5.7 Picks from new apps

  • Linear Insights, Granola (2024/2025): evaluating Tauri.
  • Warp Terminal: in-house Rust with Metal/Vulkan.
  • Raycast: native macOS Swift.
  • Mailtrap internal tools: Tauri.
  • SilentKeys, Voxly: Tauri from day one.

Lesson: post-2024 greenfield projects evaluate Tauri seriously. Big-company big apps don't move.


6. Per-Platform Considerations

6.1 Windows-only target

  • WinUI 3 plus .NET: Microsoft's first-party recommendation. Native look, fast startup, small bundle.
  • WPF: legacy but stable. The standard for large enterprise internal tools.
  • Win32 plus C++: extreme performance. Office and AutoCAD live here.
  • Avalonia: WPF-like with the cross-platform option open.

For Windows-only, Electron and Tauri are overkill.

6.2 macOS-only target

  • SwiftUI: largely mature by 2026. Natural choice if you can target macOS 13-plus.
  • AppKit: tradition. Use to cover what SwiftUI misses.
  • Catalyst: iPad apps brought to Mac. The macOS-ness of the result is subtle.

For serious Mac App Store presence, code signing, and notarization, native is easier.

6.3 Linux-only target

  • GTK plus Rust/Vala: most natural in a GNOME environment.
  • Qt: friendly with KDE. Most stable cross-desktop Linux option.
  • Flutter: possible, but Linux packaging is rough.

Linux packaging (deb, rpm, flatpak, snap, AppImage) is its own job.

6.4 Three desktops plus mobile

If "ship desktop and mobile at the same time" is real, the candidate list is short.

  • Tauri 2: one codebase, mobile as a module, webview consistency.
  • Flutter: truly one codebase. Accept the desktop awkwardness.
  • Compose MP: the Kotlin camp. Desktop and Android feel natural.
  • MAUI: Windows-first plus mobile. macOS via Catalyst.
  • React Native plus Capacitor combo: RN on mobile, Capacitor/Electron on desktop.

None is perfect. Answer honestly "where does desktop matter more, where does mobile matter more?" and the choice narrows.


7. Bets for the Future — Beyond 2026

7.1 System webviews getting more consistent

WebView2 (Windows) and WKWebView (macOS) are stabilizing. The problem child is WebKitGTK on Linux. Until Linux's system webview catches up to Chromium, Tauri and Wails carry a permanent Linux weakness.

Workaround attempt: an RFC in 2025 proposed embedding Servo (the Rust browser engine) into Tauri. Progress is slow.

7.2 Compose Multiplatform iOS stabilizing

Stable GA expected in the second half of 2026. Once stable, you can target desktop plus mobile from one Kotlin codebase — strong Flutter competition.

7.3 Flutter's desktop UX filling in

Desktop shortcuts, menu APIs, multi-window APIs are filling in quickly through 2025 and 2026. The chance of serious desktop apps adopting Flutter is rising.

7.4 Growth of the Rust-native UI camp

Slint, egui, Iced, GPUI (Zed's framework) — Rust-native UI frameworks are multiplying. Expect share gains in small tools and performance-first apps.

7.5 AI integration is fueling a desktop renaissance

Coding agents, voice assistants, local LLM tools — they all work best on the desktop. The desktop framework category will get more active for the next five years.


Epilogue — Checklist and Anti-Patterns

Pre-decision checklist

  • What is the team's primary language? Start with that camp.
  • How many target OSes — does Linux count, does mobile ship alongside?
  • Is there a bundle budget — are users on low-end PCs?
  • Does startup time matter — for a CLI-adjacent tool it's everything.
  • Does the UI change often — webview camp is faster.
  • Does pixel-level performance matter — graphics/media/editors go native.
  • Is App Store distribution required — Apple/Microsoft notarization adds friction.
  • Is mobile shipping alongside — the candidate list shrinks to four.
  • Is hiring possible in this camp — too small a camp means the next hire never lands.
  • Will this framework still exist in five years — activity, committer count, big sponsors.

Common anti-patterns

  • "Tauri because it's light" — starting Tauri with no Rust-capable person on the team. Every backend command stalls the team.
  • "Flutter because one codebase" — adopting Flutter without auditing desktop UX. Users complain about missing shortcuts and menus.
  • "MAUI because Microsoft" — picking MAUI when Linux users matter. Post-launch complaints about Linux being unsupported.
  • "Qt because it's truly native" — not checking commercial license cost. Negotiations stall the launch.
  • "Electron is heavy" as a general fact — fearing a 200MB bundle for users on 16GB RAM PCs, picking Tauri, eating six months learning Rust.
  • "Compose is cool" — starting with no Android developers. Wrestling with Kotlin/Gradle build systems instead of shipping.
  • "Our team can do anything" — picking a camp with no hiring pipeline. Future-hire costs explode.

Four questions to answer in a week

  1. Who builds it? — team language.
  2. Who uses it? — target OS and user environment.
  3. What does it do? — UI change frequency and performance needs.
  4. How long does it live? — five-year hiring and maintenance scenario.

Answer those honestly and the candidate set usually shrinks to two or three. From there: one-week PoC, one-week decision, then real development.

Next-post preview

  • Everything about desktop auto-update: code signing, notarization, delta updates, Squirrel, Tauri Updater, Sparkle.
  • Desktop app security model comparison: Electron's context isolation, Tauri's capabilities, Qt's SBOM story, macOS sandboxing.
  • Desktop distribution channel strategy: direct downloads, Microsoft Store, Mac App Store, Snap, Flatpak, Homebrew.
  • Desktop app performance measurement: startup time, memory, frame time, input latency — how to measure and how to compare.

Desktop isn't dead. It's more alive than ever. Eleven tools, no single right answer. Slice on four axes, narrow to two or three, decide in a one-week PoC.


References

현재 단락 (1/295)

In the mid-2010s it looked like mobile apps would swallow every screen. The 2026 reality is differen...

작성 글자: 0원문 글자: 23,218작성 단락: 0/295