Skip to content

Split View: 데스크톱 앱 프레임워크 2026 — Tauri · Electron · Wails · Compose · MAUI · Flutter · Qt · Slint 카테고리 전수 비교

|

데스크톱 앱 프레임워크 2026 — Tauri · Electron · Wails · Compose · MAUI · Flutter · Qt · Slint 카테고리 전수 비교

프롤로그 — "데스크톱은 죽었다"는 말은 틀렸다

2010년대 중반, 모바일 앱이 모든 화면을 차지할 것처럼 보였다. 그런데 2026년의 현실은 다르다. 개발자 도구(VS Code · Cursor · JetBrains), 디자인 도구(Figma 데스크톱 · Affinity), 협업 도구(Slack · Discord · Notion · Linear), 보안 도구(1Password · Bitwarden), 미디어 도구(OBS · Reaper · DaVinci Resolve) — 모두 데스크톱이 1차 표면이다. 웹 앱은 보조, 모바일은 알림 채널, 진짜 작업은 데스크톱에서 일어난다.

그래서 "데스크톱 앱을 어떻게 만들 것인가"는 다시 뜨거운 질문이다. 선택지가 너무 많아서 더 뜨겁다. Electron · Tauri · Wails · Neutralino · Compose Multiplatform · .NET MAUI · Flutter 데스크톱 · Qt/PySide · Slint · Lazarus · GTK + 다양한 바인딩 — 카테고리 안에 11개가 살아 있고, 각자 다른 트레이드오프를 고집한다.

이 글은 그 카테고리 전체를 한 화면에 놓는다. 한 달 전에 쓴 "Tauri 2 vs Electron 단일 비교" 글이 있지만, 그것은 두 프레임워크 사이의 결투였다. 이 글은 그보다 넓은 지도다 — 웹 기술 vs 네이티브 기술의 진영 차이, 단일 OS vs 멀티 OS의 야망, 팀 언어가 만드는 자연선택, 그리고 "Linear/Cursor/Bitwarden/Affinity는 왜 다 다른 도구를 골랐는가"의 답.

핵심 한 줄: "최고의 데스크톱 프레임워크"는 없다. 팀 언어, 타깃 OS, 성능 요구, 번들 예산 네 축이 교차하는 지점에 "당신에게 가장 적합한 도구"가 있다. 그 교차점을 빠르게 찾는 것이 이 글의 목표다.


1장 · 진짜 선택 축은 무엇인가

프레임워크 비교 글이 종종 실패하는 이유는 "어떤 것이 더 좋다"는 1차원 비교에 매달리기 때문이다. 데스크톱 프레임워크의 실제 선택은 최소 4차원이다.

1.1 네이티브 vs 웹뷰 렌더링

UI를 어떻게 그리느냐가 첫 번째 분기점이다.

  • 웹뷰 기반: HTML/CSS/JS로 그리고, OS의 웹뷰(Chromium · WebView2 · WebKit) 또는 번들된 Chromium이 픽셀을 찍는다. Electron · Tauri · Wails · Neutralino가 여기에 속한다.
  • 네이티브 렌더링: OS의 네이티브 위젯(Win32 · Cocoa · GTK)이나 자체 렌더러(Skia · Qt 자체 엔진)가 픽셀을 찍는다. Qt · Compose · MAUI · Flutter · Slint · Lazarus가 여기에 속한다.

웹뷰는 웹 개발자 풀을 그대로 쓸 수 있고 UI 변경이 빠르다. 네이티브는 시작 시간 · 메모리 · 키보드 단축키 · 접근성 · 트레이 통합에서 우위다. "둘 다 한다"는 도구는 없다 — 골라야 한다.

1.2 팀 언어가 만드는 자연선택

장기적으로 가장 강한 힘은 "팀이 이미 쓰는 언어"다.

  • TypeScript/JavaScript 팀 → Electron · Tauri · Wails(프런트는 웹) · Neutralino · React Native macOS/Windows
  • Rust 팀 → Tauri · Slint · gtk-rs · Iced · egui
  • Go 팀 → Wails · Fyne · gioui
  • C# 팀 → .NET MAUI · WinUI 3 · Avalonia · Uno Platform
  • Kotlin/Java 팀 → Compose Multiplatform · JavaFX · Swing(레거시)
  • Dart 팀 → Flutter 데스크톱
  • C++/Python 팀 → Qt · PySide · wxWidgets
  • Pascal 팀 → Lazarus / Free Pascal

언어를 바꾸면 채용도 도구도 빌드 파이프라인도 다 바뀐다. 그래서 "기존 팀이 1주일 안에 빌드를 돌릴 수 있는가"가 사실상 가장 강한 필터다.

1.3 타깃 플랫폼의 범위

  • Windows만 → WinUI 3 · WPF · Win32(레거시). 가장 좁고 가장 빠르다.
  • macOS만 → SwiftUI · AppKit. App Store 인증, 시스템 API 친화.
  • 데스크톱 3종(Win/macOS/Linux) → Electron · Tauri · Wails · Qt · Compose · Flutter · MAUI(Linux는 약함).
  • 데스크톱 + 모바일 → Tauri 2 · Flutter · Compose Multiplatform · MAUI · React Native + Capacitor.
  • 임베디드까지 → Slint · Qt · LVGL(전혀 다른 영역).

"데스크톱과 모바일 동시 출시"가 요구사항이면 후보가 좁아진다. Tauri 2, Flutter, Compose Multiplatform, MAUI 정도다.

1.4 번들 크기 vs 성능 천장 vs 일관성

서로 트레이드오프되는 세 가지를 동시에 만족시키는 도구는 없다.

우선순위적합한 도구
번들 크기 최소화Tauri · Wails · Slint · Lazarus
성능 천장 최대화Qt · Slint · 네이티브(SwiftUI/WinUI)
모든 OS에서 픽셀 일관성Flutter · Compose(자체 렌더링)
시스템 룩앤필 자연스러움Tauri(WebView 그대로) · Qt · Compose(데스크톱 테마)
개발 속도 (UI 변경 빠름)Electron · Tauri · Flutter

이 매트릭스가 첫 번째 화살표다. "우리는 무엇을 가장 중요하게 보는가" — 이 한 질문이 후보군을 3개 이하로 줄인다.


2장 · 웹 기술 진영 — Chromium의 짐을 짊어진 자들

웹뷰를 쓰는 4종을 같은 자리에 놓고 비교한다.

2.1 Electron — 여전히 코끼리

Electron은 2013년 GitHub Atom 에디터에서 시작했다. 그 시점부터 13년이 지난 2026년에도 데스크톱 앱 시장에서 가장 많이 쓰이는 프레임워크다. VS Code · Discord · Slack · Notion · Postman · 1Password · Obsidian · Linear · Figma 데스크톱 — 이 9개 중 8개가 Electron이다(Linear는 Tauri 평가 중이라고 알려져 있다).

장점:

  • 성숙도: 13년의 버그 수정, 13년의 패키지, 13년의 StackOverflow.
  • 호환성: Chromium을 통째로 들고 다니니까 어디서나 똑같이 보인다. CSS · WebGL · WebRTC · Service Worker · 코덱 전부 동일.
  • 거대한 생태계: electron-builder · electron-forge · spectron · auto-updater — 회사용 수준의 도구가 즐비.

단점:

  • 번들 크기: 150~300MB. 디스코드 90MB는 압축본이고 디스크에 200MB+가 풀린다.
  • 메모리: Chromium 사본이 통째로 메모리에 올라온다. 빈 앱이 100MB.
  • 시작 시간: Chromium 초기화 + V8 부팅 = 1~3초.

2026년 Electron은 v33~34 라인이고, Chromium 130대를 따라가고 있다. 안정적인 분기 릴리스, ASAR 패키징, 새로운 macOS 코드 서명 통합이 들어왔다.

2.2 Tauri 2 — 시스템 웹뷰 진영의 1위

2024년 10월 Tauri 2.0 GA 이후 1년 반이 지났다. 2026년 현재 Tauri는 시스템 웹뷰 진영에서 가장 큰 점유율을 가진다. Slack 같은 빅테크는 안 옮겨왔지만, 새 프로젝트의 30~40%가 Tauri를 고른다는 통계(불완전하지만)가 있다.

핵심 차별점:

  • 시스템 웹뷰 사용: Windows는 WebView2(Edge), macOS는 WKWebView(Safari), Linux는 WebKitGTK. Chromium을 번들하지 않는다.
  • 번들 크기: 10~40MB. Electron의 1/10.
  • Rust 코어: 백엔드 명령은 Rust로 작성. IPC 경계가 명확.
  • 모바일 지원: 2.0부터 iOS · Android. 단 모바일은 아직 1.x 데스크톱만큼 성숙하지 않다.

진짜 그늘:

  • 웹뷰 파편화: Linux의 WebKitGTK는 Windows의 Edge/Chromium보다 한참 뒤처진다. CSS 신기능, 코덱, JS 엔진 모두.
  • Rust 학습 곡선: 백엔드를 Rust로 짜야 하는 순간이 온다. 프런트엔드 팀에게 부담.
  • 생태계 깊이: Electron 13년치 패키지를 따라잡지 못한다.

자세한 비교는 이전 글 "Tauri 2 vs Electron 단독 비교"에 있다 — 이 글에서는 카테고리 안의 한 선수로 다룬다.

2.3 Wails — Go의 답

Wails는 Go로 백엔드를 짜고 프런트엔드는 웹 기술을 쓰는 프레임워크다. Tauri의 Go 버전이라고 부르는 사람도 있지만, 차이는 분명하다.

  • 언어: Tauri는 Rust, Wails는 Go. Go의 빌드 속도와 단순함이 강점.
  • 시스템 웹뷰: Wails도 Tauri와 같은 전략. WebView2 · WKWebView · WebKitGTK.
  • 2026 버전: Wails v2가 안정, v3가 알파/베타. v3는 다중 윈도우, 새 메뉴 API, 더 좋은 IPC.
  • 번들: 10~30MB, Tauri와 비슷.

Go 팀에게는 자연스러운 선택이다. 백엔드 인프라가 Go로 짜여 있고, 같은 언어로 데스크톱 클라이언트를 짜고 싶다면 Wails다.

2.4 Neutralino — 가장 가벼운 옵션

Neutralino는 Node.js조차 번들하지 않는다. C++ 기반의 작은 런타임만 띄우고, JS 코드는 웹뷰가 직접 실행한다.

  • 번들: 2~5MB. 카테고리 최소.
  • 백엔드: 별도 백엔드 언어가 없다. 시스템 API는 Neutralino가 제공하는 JS 함수로 호출.
  • 타깃: Win/macOS/Linux/Chrome OS.

진짜 가볍지만, 백엔드 무게가 필요한 앱(파일 인덱싱, 암호화, 로컬 DB)에는 어색하다. 작은 도구나 시스템 트레이 유틸리티에 적합.

2.5 웹 진영 비교

항목ElectronTauri 2WailsNeutralino
백엔드 언어Node.jsRustGo없음(JS만)
웹뷰번들 Chromium시스템 웹뷰시스템 웹뷰시스템 웹뷰
번들 크기150~300MB10~40MB10~30MB2~5MB
메모리(빈 앱)100~150MB30~60MB30~60MB10~30MB
모바일iOS/Android(2.0+)실험적
생태계 성숙도★★★★★★★★★★★★★★
학습 곡선낮음중간(Rust)중간(Go)낮음

3장 · 네이티브 기술 진영 — 픽셀을 직접 그리는 자들

웹뷰를 안 쓰고 자체 렌더러나 OS 네이티브 위젯으로 그리는 도구들. 이 진영은 성능 천장이 높고 시작이 빠르지만, 학습 곡선이 가파르다.

3.1 Qt / PySide — 30년 묵은 거인

Qt는 1991년에 시작했다. 35년차. C++로 짜여 있고, Python 바인딩(PySide6, PyQt6)이 있다. 데스크톱 네이티브 진영의 사실상 1위.

사용 예: Affinity Photo/Designer/Publisher(전부 Qt), VirtualBox, KDE 데스크톱 환경 전체, Tesla 차량 클러스터 UI, 어도비 Substance Painter 일부, Maya 인터페이스, OBS Studio.

장점:

  • 성숙도: 35년. 모든 OS, 임베디드, 모바일까지.
  • 위젯 라이브러리: Qt Widgets · Qt Quick(QML) · Qt 3D — 어떤 UI도 만들 수 있다.
  • 성능: 자체 렌더러. CPU/GPU 가속 모두 가능.
  • 상업 지원: The Qt Company의 유료 라이선스 + LTS.

단점:

  • 라이선스: GPL/LGPL/상업 듀얼. 상업 라이선스는 1인당 연 수천 달러.
  • C++ 진입 장벽: PySide로 우회 가능하지만 UI 빌드는 결국 Qt 위젯 패러다임.
  • 번들 크기: 30~80MB, 동적 링킹시 더 작음.

2026년 Qt 6.8 LTS 시점. QML이 점점 표준, Qt for Python(PySide6)이 안정.

3.2 Compose Multiplatform — JetBrains의 답

JetBrains가 Kotlin Multiplatform 위에 만든 UI 프레임워크. 안드로이드의 Jetpack Compose를 데스크톱과 iOS까지 확장한다. 2024~2025년 데스크톱 안정 GA, iOS는 베타에서 안정으로 이행 중.

장점:

  • 언어: Kotlin. Android 개발자가 그대로 데스크톱으로 옮길 수 있다.
  • 선언형 UI: React 같은 패러다임. UI = 함수.
  • 렌더러: Skia 기반. 모든 OS에서 같은 픽셀.
  • JetBrains 자체 사용 예: IntelliJ 일부, Toolbox.

단점:

  • JVM 의존: 런타임 번들 시 50~150MB. GraalVM 네이티브 이미지로 줄이는 길이 있지만 까다롭다.
  • 데스크톱 위젯 자연스러움 약함: Material 디자인 기본. 데스크톱 네이티브 룩이 약함.
  • iOS는 아직 베타: 데스크톱만큼 성숙하지 않다.

Kotlin 팀에게는 의심할 여지 없는 선택. 다른 팀에게는 채용 난이도가 변수.

3.3 .NET MAUI — Xamarin의 후계

Microsoft가 Xamarin.Forms의 후속으로 만든 크로스 플랫폼 UI 프레임워크. 2022년 GA, 2023~2024년에 안정성 확보, 2025년부터 본격 채택.

장점:

  • 언어: C#. Microsoft 생태계 깊이.
  • 타깃: Windows · macOS · iOS · Android. (Linux는 공식 미지원, 커뮤니티 백엔드 있음.)
  • XAML UI: WPF 출신 개발자 친화.
  • Visual Studio: 디버깅/디자인 통합.

단점:

  • macOS 지원 약함: Mac Catalyst를 통한 우회, 네이티브가 아님.
  • Linux 미지원: 데스크톱 3종을 다 노릴 수 없다.
  • 버그 안정화 시간: GA 후 2~3년간 베타 같은 시기.

Windows 중심 + 모바일 동시 출시가 목표이면 합리적. Linux 데스크톱 사용자가 중요하면 탈락.

3.4 Flutter 데스크톱 — Google의 야망

Flutter는 모바일에서 시작해 데스크톱까지 확장했다. 2022년 데스크톱 안정, 2023년부터 진지하게 받아들여지기 시작.

장점:

  • 단일 코드베이스: iOS · Android · Web · Windows · macOS · Linux 전부.
  • Skia 렌더러: 픽셀 단위 일관성.
  • 개발 속도: Hot Reload, 강력한 위젯 라이브러리.
  • Dart 언어: 학습 곡선 낮음, AOT 컴파일.

단점:

  • 데스크톱 UX 어색함: 모바일에서 출발해서 데스크톱 단축키, 메뉴 바, 다중 윈도우가 약하다.
  • 번들 크기: 30~80MB. 작지 않다.
  • 데스크톱 패키지 부족: 모바일에 비해 데스크톱용 플러그인이 적다.

사용 예: BMW의 차량 인포테인먼트, 일부 사내 도구. 본격적인 컨슈머 데스크톱 앱은 아직 적다.

3.5 Slint — Rust 네이티브 UI

Slint는 Rust(과거 SixtyFPS)로 짜인 네이티브 UI 프레임워크. 2024년 1.0, 2025~2026년 1.x 안정화. 임베디드와 데스크톱 양쪽을 노린다.

장점:

  • 번들: 1~5MB. 카테고리 최소급.
  • 성능: 60fps 60FPS 보장, GPU 가속.
  • Slint 언어: 자체 DSL로 UI를 선언. Rust/C++/JS와 바인딩.
  • 임베디드 친화: 미세 RAM 환경에서도 작동.

단점:

  • 생태계 작음: Qt의 1/100.
  • 라이선스: GPL/Royalty-Free/Ambassador/Commercial. 상업 사용은 라이선스 협의.
  • 위젯 빈약: 풍부한 위젯 라이브러리는 아직.

작은 데스크톱 도구, 임베디드 UI, 또는 Rust 일관성을 원하는 팀에게 적합.

3.6 Lazarus / Free Pascal — 살아남은 자

Pascal로 짠 Delphi의 오픈소스 후예. 1999년 시작. 2026년에도 활발히 개발 중.

장점:

  • 단일 바이너리: 5~15MB, 의존성 없음.
  • 속도: 네이티브 컴파일, 시작 즉시.
  • 호환성: Delphi 코드 거의 그대로 빌드.
  • 모든 OS: Win · macOS · Linux · BSD.

단점:

  • Pascal 채용 어려움: 신규 인력이 적다.
  • UI 트렌드 뒤처짐: VCL 계열, 현대적 디자인 시스템 부족.
  • 커뮤니티 작음: 활발하지만 작다.

레거시 Delphi 코드를 이식하거나, 작은 데스크톱 도구, 또는 Pascal 팀이 있다면 합리적.

3.7 GTK + 바인딩 (gtk-rs · Vala · PyGObject)

GTK는 GIMP에서 출발한 GNOME의 위젯 라이브러리. 30년 묵었다. Rust 바인딩(gtk-rs), Vala, Python(PyGObject) 등 다양한 언어로 쓸 수 있다.

장점:

  • GNOME 통합: Linux에서 네이티브 룩.
  • 작은 번들: GTK가 시스템에 깔려 있다면 더 작음.
  • 다양한 바인딩: Rust · Vala · Python · C.

단점:

  • macOS/Windows 어색함: 룩앤필이 그 OS에 맞지 않는다.
  • GTK4 마이그레이션 진행 중: GTK3에서 GTK4로 옮기는 중이라 생태계가 혼란.

리눅스 우선 도구라면 자연스러운 선택. 크로스 플랫폼은 어색.

3.8 그 외 카테고리

  • Avalonia (.NET): WPF 비슷한 XAML, 크로스 플랫폼. MAUI보다 Linux 지원이 좋다.
  • Uno Platform (.NET): WinUI XAML을 모든 OS로. WebAssembly까지.
  • Iced/egui (Rust): 작은 도구용 Rust UI.
  • Fyne/gioui (Go): Go 진영의 네이티브 UI.
  • wxWidgets: C++ 기반, OS 네이티브 위젯 래핑.

이 카테고리에 들어가는 후보가 너무 많아서 다 다루지 못한다. 위 12개 정도가 2026년에 진지하게 검토할 만한 도구다.


4장 · 결정 매트릭스 — 어디가 누구에게 맞는가

11개 후보를 4축에 놓고 시각화하면 다음과 같다.

도구언어렌더링번들데스크톱 OS모바일추천 시나리오
ElectronTS/JS번들 Chromium150~300MBWin/macOS/Linux큰 팀, 빠른 UI 변경, 호환성 필수
Tauri 2Rust + 웹시스템 웹뷰10~40MBWin/macOS/LinuxiOS/Android새 프로젝트, 번들 작게, Rust 가능 팀
WailsGo + 웹시스템 웹뷰10~30MBWin/macOS/Linux실험적Go 백엔드 팀, 같은 언어 통일
NeutralinoJS시스템 웹뷰2~5MBWin/macOS/Linux시스템 트레이 유틸, 작은 도구
Qt/PySideC++/Python자체 렌더러30~80MB모든 OS+모바일iOS/Android그래픽/CAD, 임베디드, 성능 천장
Compose MPKotlinSkia50~150MBWin/macOS/LinuxiOS/AndroidKotlin/Android 팀 데스크톱 확장
.NET MAUIC#네이티브50~120MBWin/macOSiOS/AndroidWindows 중심 + 모바일
FlutterDartSkia30~80MBWin/macOS/LinuxiOS/Android단일 코드베이스 진심
SlintRust/DSL자체 렌더러1~5MBWin/macOS/Linux임베디드마이크로 도구, 임베디드 UI
LazarusPascal네이티브5~15MB모든 OSDelphi 코드 이식, 작은 도구
GTK + RustRustGTK5~20MBLinux 우선GNOME 통합, 리눅스 우선

읽는 법: "팀이 쓸 줄 아는 언어" 한 열, "타깃 OS" 한 열을 골라서 교차점이 비어 있지 않은 행이 후보다. 보통 2~3개로 좁혀진다.


5장 · 실제 사례 — 큰 앱들은 무엇을 골랐는가

5.1 VS Code · Cursor · Windsurf · Zed

  • VS Code: Electron. Code OSS 베이스. Microsoft가 자체적으로 매우 무거운 최적화.
  • Cursor: Electron + VS Code OSS 포크. Electron을 골랐다기보다 VS Code 코드베이스를 그대로 쓰는 선택.
  • Windsurf (Codeium): Electron + VS Code OSS 포크. 같은 이유.
  • Zed: 자체 Rust + GPUI 프레임워크. Electron을 거부하고 처음부터 자체 GPU 가속 UI를 짰다.

교훈: VS Code 코드베이스를 재사용하면 Electron이 필연. 처음부터 짜면 자유.

5.2 Discord · Slack · Teams

  • Discord: Electron. 13년 전부터.
  • Slack: Electron. macOS 전용 네이티브 시도(2020~2021)는 실패하고 Electron으로 복귀.
  • Teams: Electron + WebView2. 마이크로소프트가 React Native 데스크톱으로 옮긴다는 소문이 있었지만 결국 안 옮겼다.

교훈: 큰 회사의 큰 앱은 마이그레이션 비용이 너무 크다. 일단 Electron이면 계속 Electron.

5.3 1Password · Bitwarden

  • 1Password: 8.x 버전부터 Electron. (이전 7.x는 네이티브.)
  • Bitwarden: Electron 데스크톱 + 웹 vault + 네이티브 모바일.

교훈: 보안 앱조차 Electron을 골랐다. 호환성과 개발 속도가 보안 인식보다 무겁다.

5.4 Linear · Figma · Notion

  • Linear: Electron 데스크톱. Tauri 평가 중이라는 이야기가 2025년에 있었다. 결과는 미정.
  • Figma 데스크톱: Electron 래퍼. 본질은 웹 앱.
  • Notion: Electron 데스크톱 + Notion Calendar(과거 Cron)도 Electron.

교훈: 웹 우선 회사들은 Electron이 자연스럽다. 같은 코드를 그대로 데스크톱에.

5.5 Affinity · Adobe · DaVinci

  • Affinity Photo/Designer/Publisher: Qt. 모든 OS 동일 코드베이스.
  • Adobe: 자체 C++ 프레임워크. (각 앱마다 다름. Photoshop은 자체, 일부는 CEF/Electron.)
  • DaVinci Resolve: 자체 C++ + Qt 일부.

교훈: 픽셀 성능이 중요한 그래픽 도구는 Qt나 자체 네이티브를 고집.

5.6 OBS · Reaper · Audacity

  • OBS Studio: Qt.
  • Reaper: 자체 C++ 프레임워크 (WDL/IPlug). 극단적으로 작은 번들과 빠른 시작.
  • Audacity: wxWidgets.

교훈: 미디어 도구는 성능/지연 시간 때문에 네이티브 진영을 고른다.

5.7 새로운 앱들의 선택

  • Linear Insights · Granola (2024~2025): Tauri 검토.
  • Warp Terminal: 자체 Rust + Metal/Vulkan.
  • Raycast: macOS 네이티브 Swift.
  • Mailtrap의 사내 도구: Tauri.
  • SilentKeys · Voxly: Tauri로 처음부터.

교훈: 2024년 이후 새 프로젝트는 Tauri를 진지하게 검토한다. 큰 회사 큰 앱은 안 옮긴다.


6장 · 타깃 플랫폼별 고려사항

6.1 Windows만 노린다면

  • WinUI 3 + .NET: Microsoft 1차 권장. 네이티브 룩, 빠른 시작, 작은 번들.
  • WPF: 레거시지만 안정. 큰 기업 내부 도구의 표준.
  • Win32 + C++: 극단적 성능. Office, AutoCAD 같은 거인.
  • Avalonia: WPF 비슷하면서 크로스 플랫폼 옵션 열어둠.

Windows 전용이면 Electron/Tauri는 사실 과한 선택이다.

6.2 macOS만 노린다면

  • SwiftUI: 2026년에는 거의 성숙. macOS 13+ 타깃이면 자연스러움.
  • AppKit: 전통. SwiftUI에서 누락된 API가 있을 때 보완.
  • Catalyst: iPad 앱을 mac으로. 결과물의 macOS 자연스러움은 미묘.

macOS App Store, 코드 서명, 노타리제이션을 진지하게 통과하려면 네이티브 진영이 편하다.

6.3 Linux만 노린다면

  • GTK + Rust/Vala: GNOME 환경에 가장 자연스러움.
  • Qt: KDE와 친화. Linux에서도 가장 안정적인 크로스 데스크톱 환경.
  • Flutter: 가능하지만 Linux 패키징은 거칠다.

Linux는 패키징(deb · rpm · flatpak · snap · AppImage)이 별도 일거리다.

6.4 데스크톱 3종 + 모바일

데스크톱과 모바일 동시 출시를 진지하게 노린다면 후보는 좁다.

  • Tauri 2: 한 코드베이스, 모바일은 별도 모듈, 웹뷰 일관성.
  • Flutter: 진짜 단일 코드베이스. 데스크톱 어색함은 감수.
  • Compose MP: Kotlin 진영. 데스크톱과 안드로이드 자연스러움.
  • MAUI: Windows 중심 + 모바일. macOS는 Catalyst.
  • React Native + Capacitor 조합: 모바일 RN + 데스크톱 Capacitor/Electron.

어느 것도 완벽하지 않다. "어디서 데스크톱이 더 중요한가, 어디서 모바일이 더 중요한가"를 솔직히 답하면 선택이 좁혀진다.


7장 · 미래에 거는 베팅 — 2026 이후

7.1 시스템 웹뷰의 일관성 개선

WebView2(Windows)와 WKWebView(macOS)는 점점 안정화되고 있다. 문제는 Linux의 WebKitGTK다. Linux의 시스템 웹뷰가 Chromium 수준으로 좋아지지 않으면 Tauri/Wails는 영원히 Linux에서 약점을 안고 간다.

대안 시도: Servo(Rust 브라우저 엔진)를 Tauri가 임베드한다는 RFC가 2025년에 나왔다. 진행은 느리다.

7.2 Compose Multiplatform iOS의 안정화

2026년 후반에 안정 GA 예상. 안정화되면 Kotlin 한 언어로 데스크톱 + 모바일을 다 노릴 수 있다. Flutter의 강력한 경쟁자.

7.3 Flutter의 데스크톱 UX 보강

데스크톱 단축키, 메뉴, 다중 윈도우 API가 2025~2026년에 빠르게 채워지고 있다. 진지한 데스크톱 앱이 Flutter를 채택할 가능성이 늘고 있다.

7.4 Rust 네이티브 UI 진영의 성장

Slint, egui, Iced, GPUI(Zed의 프레임워크) — Rust로 짠 네이티브 UI 프레임워크가 늘고 있다. 작은 도구와 성능 우선 앱에서 점유율이 커질 것.

7.5 AI 통합이 데스크톱 르네상스를 부추긴다

코딩 에이전트, 음성 비서, 로컬 LLM 도구 — 모두 데스크톱에서 가장 잘 작동한다. 데스크톱 프레임워크 카테고리는 향후 5년 동안 더 활발해질 것이다.


에필로그 — 선택 체크리스트와 안티패턴

선택 전 체크리스트

  • 팀의 1차 언어는 무엇인가 — 그 언어 진영부터 본다.
  • 타깃 OS는 몇 개인가 — Linux를 포함하는가, 모바일도 같이 가는가.
  • 번들 크기 예산이 있는가 — 사용자 환경(저사양 PC)이 변수인가.
  • 시작 시간이 중요한가 — 명령어 도구는 즉시성이 핵심.
  • UI가 자주 바뀌는가 — 그렇다면 웹뷰 진영이 빠르다.
  • 픽셀 성능이 중요한가 — 그래픽/미디어/에디터면 네이티브 진영.
  • App Store 배포가 필요한가 — Apple/Microsoft 인증 통과 부담.
  • 모바일을 같이 출시하는가 — 후보가 4개로 좁혀진다.
  • 채용 가능한 인력 풀이 충분한가 — 너무 작은 진영이면 다음 사람이 못 들어온다.
  • 5년 후에도 이 프레임워크가 살아 있는가 — 활동성, 커미터 수, 큰 후원자 여부 확인.

흔한 안티패턴

  • "가벼우니까 Tauri" — 팀에 Rust를 쓸 수 있는 사람이 없는데 시작 → 백엔드 명령 추가할 때마다 멈춤.
  • "단일 코드베이스니까 Flutter" — 데스크톱 UX 검토 없이 시작 → 단축키/메뉴 부재로 사용자 불만.
  • "Microsoft니까 MAUI" — Linux 사용자가 핵심인 도구인데 MAUI 선택 → 출시 후 Linux 미지원 비난.
  • "Qt는 진짜 네이티브" — 상업 라이선스 비용 미확인 → 출시 직전 라이선스 협상에서 멈춤.
  • "Electron은 무겁다"는 일반론 — 사용자가 16GB RAM PC를 쓰는 환경인데 200MB 번들을 두려워해서 Tauri 선택 → Rust 학습으로 6개월 지연.
  • "Compose는 멋지니까" — Android 개발자 없는 팀에서 시작 → Kotlin/Gradle 빌드 시스템과 씨름.
  • "우리 팀은 다 가능" — 채용 시장에 후보가 없는 진영 선택 → 다음 채용에서 비용 폭증.

1주일 안에 답해야 할 질문 4개

  1. 누가 만드는가 — 팀 언어
  2. 누가 쓰는가 — 타깃 OS와 사용자 환경
  3. 무엇을 만드는가 — UI 변경 빈도와 성능 요구
  4. 얼마나 오래 가는가 — 5년 후 채용/유지 보수 시나리오

이 4개에 정직하게 답하면 후보가 보통 2~3개로 좁혀진다. 거기서부터 PoC 1주, 결정 1주, 이후 본격 개발.

다음 글 예고

  • 데스크톱 앱 자동 업데이트의 모든 것: 코드 서명, 노타리제이션, 델타 업데이트, Squirrel · Tauri Updater · Sparkle.
  • 데스크톱 앱 보안 모델 비교: Electron의 컨텍스트 격리, Tauri의 capabilities, Qt의 SBOM, macOS sandboxing.
  • 데스크톱 앱 배포 채널 전략: 직접 다운로드 · Microsoft Store · Mac App Store · Snap · Flatpak · Homebrew.
  • 데스크톱 앱 성능 측정: 시작 시간 · 메모리 · 프레임 시간 · 입력 지연 — 어떻게 재고 어떻게 비교하는가.

데스크톱은 죽지 않았다. 더 살아 있다. 도구는 11개이고, 정답은 팀마다 다르다. 4축으로 자르고, 후보 2~3개로 좁히고, PoC 1주로 결정하라.


참고 / References

Desktop App Frameworks 2026 — Tauri, Electron, Wails, Compose, MAUI, Flutter, Qt, Slint: A Category-Wide Comparison

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