Chaos and Order

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

プロローグ — 「デスクトップは死んだ」は間違いだった

2010 年代半ば、モバイルアプリがすべての画面を占領するように見えた。しかし 2026 年の現実は違う。開発者ツール(VS Code・Cursor・JetBrains)、デザインツール(Figma デスクトップ・Affinity)、コラボツール(Slack・Discord・Notion・Linear)、セキュリティツール(1Password・Bitwarden)、メディアツール(OBS・Reaper・DaVinci Resolve)— すべてデスクトップが第一の表面だ。ウェブアプリは補助、モバイルは通知チャネル、本当の作業はデスクトップで起きる。

そこで「デスクトップアプリをどう作るか」が再び熱い問いになった。選択肢が多すぎてさらに熱い。Electron・Tauri・Wails・Neutralino・Compose Multiplatform・.NET MAUI・Flutter デスクトップ・Qt/PySide・Slint・Lazarus・GTK と各種バインディング — カテゴリ内に 11 個が生きており、それぞれ異なるトレードオフを主張する。

本稿はそのカテゴリ全体を一画面に並べる。1 か月前に書いた「Tauri 2 vs Electron 単独比較」記事はあるが、あれは二者の決闘だった。これはより広い地図 — ウェブ系陣営とネイティブ系陣営の差、単一 OS vs マルチ OS の野心、チーム言語が作る自然選択、そして「Linear・Cursor・Bitwarden・Affinity はなぜ全部違う道具を選んだのか」の答え。

一行で言うと:「最良のデスクトップフレームワーク」は存在しない。チーム言語・ターゲット OS・性能要求・バンドル予算の 4 軸が交差する点に、あなたに最適な道具がある。その交差点を素早く見つけることが本稿の目的だ。

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 for 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 一貫性

互いにトレードオフする 3 つを同時に満たす道具はない。

優先順位	適した道具
バンドルサイズ最小化	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 年分の Stack Overflow。
互換性: Chromium をまるごと持ち運ぶので、どこでも同じに見える。CSS・WebGL・WebRTC・Service Worker・コーデックすべて同じ。
巨大なエコシステム: electron-builder・electron-forge・spectron・auto-updater — エンタープライズ級のツールが山のように揃う。

短所:

バンドルサイズ: 150〜300MB。Discord の 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 のデスクトップほど成熟していない。

真の影:

WebView の断片化: 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 ウェブ陣営の比較

項目	Electron	Tauri 2	Wails	Neutralino
バックエンド言語	Node.js	Rust	Go	なし(JS のみ)
ウェブビュー	バンドル Chromium	システムウェブビュー	システムウェブビュー	システムウェブビュー
バンドルサイズ	150〜300MB	10〜40MB	10〜30MB	2〜5MB
空アプリのメモリ	100〜150MB	30〜60MB	30〜60MB	10〜30MB
モバイル	×	iOS/Android(2.0+)	実験的	×
エコシステム成熟度	星 5	星 4	星 3	星 2
学習曲線	低	中(Rust)	中(Go)	低

3 章 · ネイティブ技術陣営 — 直接ピクセルを描く者たち

ウェブビューを使わず、自前レンダラや OS ネイティブウィジェットで描くツール。性能天井が高く起動が速いが、学習曲線が急。

3.1 Qt / PySide — 35 年の巨人

Qt は 1991 年に始まった。35 年目。C++ で書かれ、Python バインディング(PySide6・PyQt6)がある。デスクトップネイティブ陣営の事実上 1 位。

利用例: Affinity Photo/Designer/Publisher(すべて Qt)、VirtualBox、KDE デスクトップ環境全体、Tesla 車両クラスタ UI、Adobe 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 フレームワーク。Android の Jetpack Compose をデスクトップと iOS まで拡張する。2024〜2025 年にデスクトップが安定 GA、iOS はベータから安定に移行中。

長所:

言語: Kotlin。Android 開発者がそのままデスクトップへ。
宣言的 UI: React 風パラダイム。UI = 関数。
レンダラ: Skia ベース。全 OS で同じピクセル。
JetBrains 自身が使用: IntelliJ の一部、Toolbox。

短所:

JVM 依存: ランタイムバンドルで 50〜150MB。GraalVM ネイティブイメージで縮める道はあるが面倒。
デスクトップウィジェットの自然さが弱い: Material Design 既定。デスクトップネイティブな見た目には弱い。
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 レンダラ: ピクセル単位の一貫性。
開発速度: ホットリロード、強力なウィジェットライブラリ。
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 を保証、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 への移行でエコシステムが混沌。

Linux 優先ツールには自然な選択。クロスプラットフォームには不向き。

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	モバイル	おすすめシナリオ
Electron	TS/JS	バンドル Chromium	150〜300MB	Win/macOS/Linux	×	大規模チーム、UI 変更速、互換性必須
Tauri 2	Rust + ウェブ	システムウェブビュー	10〜40MB	Win/macOS/Linux	iOS/Android	新規プロジェクト、バンドル小、Rust 可能チーム
Wails	Go + ウェブ	システムウェブビュー	10〜30MB	Win/macOS/Linux	実験的	Go バックエンドチーム、同一言語
Neutralino	JS	システムウェブビュー	2〜5MB	Win/macOS/Linux	×	トレイユーティリティ、小ツール
Qt / PySide	C++/Python	自前レンダラ	30〜80MB	全 OS + モバイル	iOS/Android	グラフィック/CAD、組み込み、性能天井
Compose MP	Kotlin	Skia	50〜150MB	Win/macOS/Linux	iOS/Android	Kotlin/Android チームのデスクトップ拡張
.NET MAUI	C#	ネイティブ	50〜120MB	Win/macOS	iOS/Android	Windows 中心 + モバイル
Flutter	Dart	Skia	30〜80MB	Win/macOS/Linux	iOS/Android	単一コードベース本気
Slint	Rust/DSL	自前レンダラ	1〜5MB	Win/macOS/Linux	組み込み	マイクロツール、組み込み UI
Lazarus	Pascal	ネイティブ	5〜15MB	全 OS	×	Delphi コード移植、小ツール
GTK + Rust	Rust	GTK	5〜20MB	Linux 優先	×	GNOME 統合、Linux 優先

読み方:「チームが使える言語」一列、「ターゲット 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。Microsoft が 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 の第一推奨。ネイティブルック、速い起動、小さなバンドル。
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 陣営。デスクトップと Android が自然。
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 年でさらに活発化する。

エピローグ — 選択チェックリストとアンチパターン

選択前チェックリスト

よくあるアンチパターン

「軽いから Tauri」 — チームに Rust を書ける人がいないのに開始 → バックエンドコマンドを追加するたびに停滞。
「単一コードベースだから Flutter」 — デスクトップ UX 検討せずに開始 → ショートカット/メニュー不足でユーザ不満。
「Microsoft だから MAUI」 — Linux ユーザが核心のツールで MAUI 選択 → リリース後に Linux 非対応で非難。
「Qt は真のネイティブ」 — 商用ライセンス費用未確認 → リリース直前のライセンス交渉で停止。
「Electron は重い」の一般論 — ユーザが 16GB RAM PC を使う環境で 200MB バンドルを恐れて Tauri 選択 → Rust 学習で 6 か月遅延。
「Compose はかっこいいから」 — Android 開発者なしのチームで開始 → Kotlin/Gradle ビルドシステムと格闘。
「うちのチームは何でもできる」 — 採用市場に候補がいない陣営を選択 → 次の採用でコスト急増。

1 週間で答えるべき 4 つの質問

誰が作るか — チーム言語
誰が使うか — ターゲット OS とユーザ環境
何を作るか — UI 変更頻度と性能要求
どれだけ続くか — 5 年後の採用/保守シナリオ

この 4 つに正直に答えれば候補は通常 2〜3 個に絞れる。そこから PoC 1 週間、決定 1 週間、その後本格開発。

次回予告

デスクトップアプリ自動更新のすべて: コード署名、公証、デルタ更新、Squirrel・Tauri Updater・Sparkle。
デスクトップアプリセキュリティモデル比較: Electron のコンテキスト分離、Tauri の capabilities、Qt の SBOM、macOS サンドボックス。
デスクトップアプリ配布チャネル戦略: 直接ダウンロード・Microsoft Store・Mac App Store・Snap・Flatpak・Homebrew。
デスクトップアプリ性能測定: 起動時間・メモリ・フレーム時間・入力遅延 — どう測りどう比較するか。

デスクトップは死んでいない。むしろ生きている。ツールは 11 個、正解はチームごとに違う。4 軸で切り、候補 2〜3 個に絞り、PoC 1 週間で決めよ。

参考 / References

Electron 公式: electronjs.org
Electron リリースノート: github.com/electron/electron/releases
Tauri 公式: tauri.app
Tauri 2.0 発表: tauri.app/blog/tauri-20
Wails 公式: wails.io
Wails v3 ロードマップ: v3alpha.wails.io
Neutralino 公式: neutralino.js.org
Qt 公式: qt.io
Qt 6.8 LTS 発表: qt.io/blog/qt-6.8-lts-released
PySide6 / Qt for Python: doc.qt.io/qtforpython
JetBrains Compose Multiplatform: jetbrains.com/compose-multiplatform
Compose iOS 進捗: github.com/JetBrains/compose-multiplatform
.NET MAUI 公式: dotnet.microsoft.com/apps/maui
Flutter Desktop: docs.flutter.dev/platform-integration/desktop
Slint UI: slint.dev
Slint 1.0 発表: slint.dev/blog/2023-04-03-announcing-slint-1-0
Lazarus IDE: lazarus-ide.org
Free Pascal: freepascal.org
GTK + Rust(gtk-rs): gtk-rs.org
GTK 公式: gtk.org
Vala: vala.dev
Avalonia: avaloniaui.net
Uno Platform: platform.uno
Iced (Rust): iced.rs
egui (Rust): egui.rs
Zed Editor — GPUI: zed.dev
Fyne (Go): fyne.io
gioui (Go): gioui.org
VS Code Electron 利用事例: code.visualstudio.com/docs
Discord Electron 利用事例(ブログ): discord.com/blog
Slack ネイティブ macOS 失敗譚: slack.engineering
Linear デスクトップアプリ変更議論: linear.app/blog
Notion デスクトップ Electron: notion.so
1Password 8.x 設計決定(Electron): 1password.community
Bitwarden デスクトップアーキテクチャ: bitwarden.com/help
Affinity(Qt 使用): affinity.serif.com
OBS Studio (Qt): obsproject.com
Reaper デスクトップフレームワーク: reaper.fm
BMW + Flutter 事例: flutter.dev/showcase
前回記事: Tauri 2 vs Electron 単独比較(本ブログ)