デスクトップアプリフレームワーク 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)— すべてデスクトップが第一の表面だ。ウェブアプリは補助、モバイルは通知チャネル、本当の作業はデスクトップで起きる。

そこで「デスクトップアプリをどう作るか」が再び熱い問いになった。選択肢が多すぎてさらに熱い。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 つを同時に満たす道具はない。

このマトリクスが最初の矢印。「我々は何を最も重視するか」— この一問が候補を 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 ウェブ陣営の比較

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」一列を選び、交差点が埋まっている行が候補。通常 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 年でさらに活発化する。

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

選択前チェックリスト

• チームの第一言語は何か — その陣営から始める。
• ターゲット OS はいくつか — Linux を含むか、モバイルも一緒か。
• バンドルサイズの予算はあるか — ユーザ環境(低スペック PC)は変数か。
• 起動時間は重要か — CLI 系ツールは即時性が要。
• 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 サンドボックス。
• デスクトップアプリ配布チャネル戦略: 直接ダウンロード・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 単独比較(本ブログ)