Skip to content
Published on

クロスプラットフォームデスクトップアプリ 2026 完全ガイド - Tauri 2 · Electron 34 · Wails 3 · NeutralinoJS · Flutter Desktop · Sciter · Slint · Iced 徹底分析

Authors

プロローグ - デスクトップは再び一次表面である

2010年代半ば、モバイルアプリがすべての画面を飲み込むように見えた。しかし2026年の現実は逆方向に進んだ。開発者ツール(VS Code · Cursor · JetBrains)、デザインツール(Figmaデスクトップ · Affinity)、コラボツール(Slack · Discord · Notion · Linear · カカオトーク デスクトップ)、セキュリティツール(1Password · Bitwarden)、メディアツール(OBS · Reaper · DaVinci Resolve · Cap) - すべてデスクトップが一次表面である。Webアプリは補助、モバイルは通知チャネル、本当の作業はデスクトップで起きる。

そのため「どの道具でクロスプラットフォームのデスクトップアプリを作るか」は再び最も熱い問いになった。1か月前に「デスクトップアプリフレームワーク カテゴリ比較」を書いた。あれは大きな地図だった。この記事はその地図を持って実際に道を歩く。候補ツールを順に入れ、バンドルをビルドし、メモリを測り、パッケージとコード署名を試し、その結果として何を選ぶべきか結論を出す。

一行の核: 2026年は「ElectronかTauriか」ではない。Wails 3 · Flutter Desktop · Slint · Iced · Lynx · Avalonia · MAUI - 陣営が増え、それぞれに異なる強みがある。この記事の目標は、その陣営の違いを30分で整理し、5つの基準で「あなたのチームの道具」を選ばせることだ。


1章 · 2026年のデスクトップ市場 4つのトレンド

1.1 同梱Chromiumからシステムウェブビューへ

10年間Chromiumを丸ごと持ち運ぶ時代が終わりつつある。WebView2(Windows) · WKWebView(macOS) · WebKitGTK(Linux)が十分に安定し、これを使うとバンドルサイズが約10分の1になる。Tauri 2 · Wails 3 · NeutralinoJSはすべてシステムウェブビュー陣営だ。

1.2 モバイルまで広がるデスクトップフレームワーク

Tauri 2が2024年にiOS/Androidサポートを追加し、「デスクトップ + モバイルの単一コードベース」が再び候補に上がった。Flutterはデスクトップをモバイルに足したケースで、Compose Multiplatform · MAUIも同じ野心を持つ。

1.3 Rust陣営の本格参入

Tauri · Slint · Iced · Xilem · egui · gtk-rs - Rustでデスクトップ UI を書く道具が6種を超える。2026年時点で「新プロジェクトをRustで始める」のはリスクではなく合理的な選択肢である。

1.4 パッケージとコード署名の標準化

macOS Developer ID + Notarization、Windows Authenticode + EV、Linux Flatpak/Snap - 5年前は各OSが違うやり方だったが、2026年にはelectron-builder · Tauri Action · GitHub Actionsワークフローがほぼ標準テンプレートとして固まった。


2章 · Electron 34 - 依然として象、しかし道は狭まる

2.1 出自と現在

Electronの本名はAtom Shellである。2013年GitHubがAtomエディタを作るために始め、その後OpenJS Foundationに移管された。2026年5月時点でElectron 34が安定ラインで、Chromium 130系列を追っている。v34からASAR Integrityがmacosおよびwindowsで強制検証され、新しいutility process API、ネイティブグラスエフェクトサポートが入った。

2.2 採用例

  • VS Code · Cursor · Trae
  • Slack · Discord · Notion · Linear
  • 1Password 8 · Bitwarden
  • Figmaデスクトップ · GitHub Desktop · Postman
  • Spotify(長年)
  • カカオトーク デスクトップ

2.3 バンドルサイズとメモリ

空のHello Worldがディスク上で約150MB、圧縮ダウンロードで80MB前後。空アプリで100200MBのメモリ、実アプリは200500MB、DiscordやSlackは1GBを超えることもある。

2.4 長所

  • 13年の成熟度。すべてのエッジケースが既に解決済み。
  • Chromium互換性: WebGL · WebRTC · Service Worker · コーデックすべて同じ挙動。
  • electron-builder · electron-forge · Spectron · electron-updaterなど企業レベルの道具が豊富。

2.5 短所

  • バンドルサイズ150~300MB。
  • メモリ - 空アプリで100MB+。
  • 起動時間 - Chromium起動 + V8初期化 = 1~3秒。
  • セキュリティ - node integration + remote moduleの誤用でRCEになりうる。

3章 · Tauri 2 - システムウェブビュー陣営の一位

3.1 出自と現在

Tauriは2019年にDaniel Thompson-Yvetotが始めたプロジェクトで、MITライセンスのRustベースのデスクトップフレームワークである。2024年にv2が正式リリースされiOS/Androidサポートが追加され、2026年5月時点ではデスクトップ + モバイルを同時に扱う陣営の標準として定着した。

3.2 採用例

  • Spacedrive(クロスプラットフォーム ファイルエクスプローラ)
  • Mockoon(API モックサーバ)
  • Pot translator(翻訳ツール)
  • Cap(オープンソースの画面録画)
  • Lens(Kubernetes IDE、一部モジュール)

3.3 バンドルサイズとメモリ

空のHello Worldで約10MB。システムウェブビューを使うのでChromium本体を持ち運ばない。メモリも50~100MBでElectronの3分の1。

3.4 長所

  • バンドルサイズはElectronの約15分の1。ダウンロードもディスク負荷も軽い。
  • メモリ半分以下。
  • Rustバックエンドの安全性と速度。
  • v2のiOS/Androidサポート - 単一コードベースで5プラットフォーム。

3.5 短所

  • システムウェブビューのバージョン差。macOSのWKWebViewとWindowsのWebView2の動きが微妙に異なる。
  • WebGL · コーデック互換性がChromiumほど均質ではない。
  • Rust学習曲線。バックエンドを書くにはRustを知る必要がある。
  • 7年目のプロジェクトだが、生態系はElectronほど厚くない。

4章 · Wails 3 - Go陣営のデスクトップ解

4.1 出自と現在

WailsはLea Anthonyが2019年から作っているGoベースのデスクトップフレームワーク。MITライセンス。v3アルファが2024年から公開され、2026年時点では正式リリース直前。コンセプトはTauriとほぼ同じ(システムウェブビュー + コンパイル済みバックエンド)だが、バックエンド言語がGoである点が違う。

4.2 バンドルサイズとメモリ

空のアプリで約15MB。メモリ60~120MB。Tauriとほぼ同じ領域。

4.3 長所

  • Goチームには自然な選択肢。バックエンドインフラをGoで作る会社が、デスクトップツールも同じ言語で作れる。
  • 単一バイナリビルドの単純さ。
  • ビルド速度がTauriより速い(GoはRustより速くコンパイルされる)。

4.4 短所

  • ユーザー数がTauriより少ない。生態系が薄い。
  • モバイルサポートなし。
  • v3がまだアルファ。

5章 · NeutralinoJS - 超軽量陣営

5.1 出自と現在

NeutralinoJSはShalitha Surangaが2020年に始めたTypeScriptベースのデスクトップフレームワーク。MITライセンス。コンセプトがさらに極端で - 「RustもGoも要らない、システムウェブビューだけ使えばいい」。バックエンドをコンパイルするステップ自体が存在しない。

5.2 バンドルサイズとメモリ

空アプリ約25MB。最小である。メモリも4080MB。

5.3 長所

  • 最小バンドル。ダウンロード1秒。
  • ビルド自体がほぼ即時。
  • TypeScript一言語で完結。

5.4 短所

  • バックエンド機能が限定的。CPU負荷の高い作業はNative Extensionが必要。
  • 資料が少なく、道具も少ない。
  • セキュリティモデルがTauriほど精緻ではない。

6章 · Flutter Desktop - 独自レンダリング陣営

6.1 出自と現在

Flutterは2017年Googleがモバイル用に始めたフレームワーク。Dart言語 + Skiaレンダリングエンジン。2022年にデスクトップがstableになり、2026年にはWindows · macOS · Linuxすべてproduction-ready状態。

6.2 採用例

  • Rive(アニメーション ツール)
  • Reflectly(ジャーナリング アプリ)
  • Wonderous(世界の不思議ガイド)
  • Superlist(ToDoアプリ)
  • 日本のSmartHRの一部デスクトップ モジュール

6.3 バンドルサイズとメモリ

空アプリ3050MB。システムウェブビューは使わないが、Skiaエンジンを持ち運ぶ。メモリ100150MB。

6.4 長所

  • すべてのOSでピクセル一貫性。デザイナーが承認したまま出る。
  • モバイルと同じコードベース - デスクトップは同じUIコードの拡張。
  • 60fpsの滑らかなアニメーション。

6.5 短所

  • ネイティブのルック&フィールではない。どのOSでも「自然」ではない。
  • Dart言語が陣営を狭める。
  • システム統合(トレイ · メニューバー · ショートカット)がElectronより弱い。

7章 · Sciter - 商用HTML/CSSエンジン

7.1 出自と現在

SciterはAndrew Fedonioukが2008年から作っているプロプライエタリな商用デスクトップエンジン。HTML/CSSの一部を独自エンジンで描画し、バンドルサイズが5MB以下。Norton AntiVirus · BitDefender · ESET · Comodo - セキュリティ製品の多くがSciterでUIを作っている。

7.2 バンドルサイズとメモリ

5MB以下。メモリ30~60MB。デスクトップツールの中では最小級。

7.3 長所

  • 最小フットプリント。
  • HTML/CSSの馴染みやすさ + ネイティブに近い性能。
  • セキュリティ製品で13年の本番運用実績。

7.4 短所

  • プロプライエタリ ライセンス。非商用は無料だが商用はライセンス料がかかる。
  • オープンソース道具の生態系がない。
  • 一般のWeb標準の一部だけサポート。

8章 · Slint 1.x - 組み込み + デスクトップ陣営

8.1 出自と現在

SlintはSixtyFPS GmbH(Olivier Goffartら元Qtコア開発者)が2020年に始めたRust + DSLベースのGUIツールキット。1.0が2023年にリリースされ、2026年時点で1.6ライン。組み込みシステムとデスクトップの両方をターゲットにしている。

8.2 ライセンス

  • ロイヤルティ + GPLデュアル ライセンス
  • または商用ライセンス
  • オープンソース プロジェクトであればGPLパスが使える

8.3 長所

  • 独自レンダラ - GPUアクセラレーション、60fpsの滑らかさ。
  • 組み込み(STM32級MCU)からデスクトップまで一つのコードベース。
  • DSLデザイナが別にあるので、デザインとコードの分離が綺麗。

8.4 短所

  • 新しいDSLを学ぶ必要がある。
  • 生態系が小さい。
  • ライセンスが実質的にデュアルで、商用利用時に整理が必要。

9章 · Iced - Elmインスパイアの Rust GUI

9.1 出自と現在

IcedはHector Ramonが2019年から作っているRust GUIライブラリ。MITライセンス。Elmアーキテクチャ(Model-View-Update)に着想を得ている。

9.2 長所

  • 関数型パターンが一貫している。状態管理がクリーン。
  • 純粋なRust - 他言語のランタイム不要。
  • 起動が速い。

9.3 短所

  • ウィジェット ライブラリが小さい。カスタム ウィジェットを多く書く必要がある。
  • 組み込み/モバイル サポートが弱い。
  • 2026年でも1.0前の状態。

10章 · DruidからXilemへ - Linebenderの進化

10.1 Druidの終了

DruidはRaph LevienのLinebenderグループが2018年から作っていたRust GUIツールキットだったが、2023年末から事実上メンテナンス停止(deprecated)状態になった。後継がXilemである。

10.2 Xilem - 新しい試み

XilemはSwiftUIの宣言的パターン + Rustの安全性 + Linebenderのグラフィックス ノウハウを組み合わせた実験プロジェクトである。2026年時点でまだ0.xライン、production-readyではないが、Rust陣営で最も注目されているGUI実験の一つだ。


11章 · egui - イミディエイト モード陣営

11.1 出自と現在

egui(発音 eh-gooey)はEmil Ernerfeldtが2020年から作っているRustの即時モードGUIライブラリ。MITライセンス。C++のDear ImGuiと似たコンセプト。

11.2 採用先

  • Rerun(CV/ロボティクス可視化ツール) - 大きな採用事例
  • デバッグ オーバーレイが必要なゲーム/ツール
  • 高速プロトタイピング

11.3 長所

  • 学習曲線が短い。1時間でGUI画面を作れる。
  • 起動が非常に速い。
  • Web(WASM)もサポート。

11.4 短所

  • デザイン自由度が低い。ウィジェット ルックが非常にシンプル。
  • 大型アプリには不向き。デバッグ ツールや可視化により向く。

12章 · GTK 4 + Adwaita - Linuxネイティブ陣営

12.1 出自と現在

GTKは1998年からあるLinuxデスクトップ ツールキットの本家である。2020年のGTK 4以降は、GNOMEデザインシステム ライブラリであるlibadwaita(Adwaita)と組み合わせて使うのが標準。2026年時点ではGTK 4.16、libadwaita 1.6ライン。

12.2 採用例

  • GNOMEデスクトップ環境のすべての一次アプリ
  • Files · Calendar · Maps · Photos · Music
  • Bottles(Wineマネージャ)
  • 多数のGNOME Circleアプリ

12.3 長所

  • GNOME Linuxで100%ネイティブ ルック。
  • Vala · Python · Rust(gtk-rs) · Cと多様なバインディング。
  • アクセシビリティと国際化が非常に強い。

12.4 短所

  • macOS · Windowsでは一級市民ではない。動くがルック&フィールがぎこちない。
  • GTK 3から4への移行がまだ進行中。

13章 · Qt 6.8 LTS + PyQt6/PySide6

13.1 出自と現在

Qtは1995年からあるC++ベースのクロスプラットフォーム GUIツールキットの皇帝。Trolltech → Nokia → The Qt Companyへ所有権が移動。2024年10月にQt 6.8 LTSがリリース。2026年時点で6.8が安定LTS、6.9が最新。

13.2 ライセンス

  • LGPLv3(オープンソース - 動的リンク義務)
  • GPL
  • 商用ライセンス(静的リンク + 商用サポート)

13.3 採用例

  • Affinity Designer · Photo · Publisher
  • OBS Studio
  • Maya · Autodesk製品の一部
  • Calibre(電子書籍管理)
  • KDE Plasmaのすべてのアプリ

13.4 PyQt6 / PySide6

  • PyQt6はRiverbank ComputingのGPL/商用Pythonバインディング
  • PySide6はQt公式のLGPL Pythonバインディング
  • 2026年にはPySide6の方がより使われている(ライセンスがより友好的)

14章 · wxWidgets - 古典的なC++

wxWidgetsは1992年からある最古のクロスプラットフォーム C++ツールキット。各OSのネイティブ ウィジェットを呼ぶのでルック&フィールが自然。短所はモダン デザインが難しく、GPUアクセラレーションが弱いこと。2026年に新プロジェクトがwxWidgetsを選ぶことは稀だが、レガシーなデスクトップ アプリは未だ多い。


15章 · JavaFX 23 - Javaのデスクトップ

15.1 出自と現在

JavaFXは2008年にSunが始めたJavaベースのGUIツールキット。2018年のJava 11からJDKから分離され、OpenJFXプロジェクトとして独立。2026年時点でJavaFX 23が最新。

15.2 採用先

  • 金融トレーディング デスクトップの一部
  • 教育用IDE(BlueJ · Greenfoot)
  • 一部のSaaS会社の管理ツール

15.3 評価

  • Javaチームには自然な選択肢
  • ただし新プロジェクトがJavaFXを選ぶ機会は減っている - Kotlin + Compose Multiplatformに席を譲りつつある

16章 · Avalonia 11 - クロスプラットフォーム XAML

16.1 出自と現在

Avaloniaは2013年にSteven Kirkが始めた.NETベースのクロスプラットフォーム UIフレームワーク。WPFのXAMLパターンをそのまま継承しつつ、Windowsだけでなくmacos · Linux · iOS · Android · WebAssemblyまでサポートする。2026年時点でAvalonia 11.xが現行。

16.2 採用例

  • JetBrains Rider · WriterSide(一部)
  • AvaloniaUI自体のデモとサイト
  • 各種ゲーム開発ツール

16.3 評価

  • WPF経験者にとって最も自然な移行先
  • .NET陣営の本物のクロスプラットフォームUI解
  • MAUIよりデスクトップフレンドリー(MAUIはモバイル優先)

17章 · .NET MAUI 9 - Microsoft公式

17.1 出自と現在

MAUI(Multi-platform App UI)は2022年にMicrosoftがXamarin.Formsの後継として出した.NETクロスプラットフォーム フレームワーク。2024年11月.NET 9と共にMAUI 9がリリース。

17.2 評価

  • モバイル優先の設計 - デスクトップはWindows + macOSのみ(Linuxなし)
  • WPF/WinFormsチームの進化路線
  • Linuxデスクトップを無視するため「本当のクロスプラットフォームではない」と評されることもある

18章 · SwiftUI on macOS + Mac Catalyst

18.1 SwiftUI

Appleが2019年WWDCで発表した宣言的UIフレームワーク。2026年時点でmacOS 15 Sequoia以降はデスクトップでも一級市民。App Storeで最も自然なmacOSアプリはすべてSwiftUI。

18.2 Mac Catalyst

iPadアプリをほぼそのままmacOSで動かす互換レイヤー。2019年導入。動くがネイティブmacOSの見た目ではなく、「iPadが大画面で動いている」感が強い。

18.3 評価

  • macOS単独ならSwiftUIが正解
  • クロスプラットフォームが必要ならSwiftUIは候補ではない - Windows/Linuxなし

19章 · CometとLynx - 2025~2026の新陣営

19.1 Comet

Cometは元Plasmicチームが2025年に発表したデスクトップ ビルダーで、コンポーネント マーケットプレイス + コード出力 + 各種バックエンド統合をまとめたツール。2026年時点でベータ後半。「デザイナーがコードなしで始め、開発者が本物のコードで引き継ぐ」ワークフローを狙う。

19.2 Lynx

TikTokの親会社ByteDanceが2025年3月にオープンソース化したクロスプラットフォーム フレームワーク。React Nativeに近いコンセプトだが、デスクトップまで一次表面として含む。社内では一部の自社アプリで使われ、外部での採用も増えている。


20章 · NW.js - 古典的なElectron代替

NW.js(旧Node-webkit)は2011年にRoger WangがIntelで始めたデスクトップ フレームワーク。Electronの兄弟分でコンセプトはほぼ同じだが、NW.jsはノードとChromiumの統合方式が違う。2026年に新プロジェクトがNW.jsを選ぶことは稀だが、一部の中国製デスクトップ ゲームランチャーはまだ使っている。


21章 · バンドルサイズ一覧

ツール空アプリ ディスク空アプリ メモリ起動時間
Sciter5MB以下30~60MB0.3秒
NeutralinoJS2~5MB40~80MB0.4秒
Tauri 210~15MB50~100MB0.5秒
Wails 315~25MB60~120MB0.6秒
Flutter Desktop30~50MB100~150MB0.7秒
Slint5~15MB40~80MB0.3秒
Iced10~20MB50~100MB0.4秒
egui5~10MB40~80MB0.3秒
Avalonia30~60MB80~140MB0.8秒
Electron 34150~300MB100~250MB1~3秒
Qt 6.8(LGPL動的)20~40MB + Qtランタイム60~120MB0.5秒

22章 · ネイティブAPI到達範囲 - どこまで届くか

デスクトップ アプリが本当の価値を出すには、OSと深く統合する必要がある。

22.1 よく必要な統合

  • ファイル ダイアログ(開く · 保存)
  • システム トレイ/メニューバー アイコン
  • 通知(macOS Notification Center、Windows Action Center、Linux libnotify)
  • ディープリンク(myapp:// のようなURLスキーム ハンドラ - 本文ではインライン コード内で表記する)
  • クリップボード(テキスト · 画像 · カスタム フォーマット)
  • グローバル ショートカット
  • 自動起動
  • ウィンドウ装飾のカスタマイズ

22.2 陣営別の成熟度

  • Electron: 最も完成している。dialogTrayNotificationglobalShortcutprotocol APIが13年間磨かれてきた。
  • Tauri 2: ほぼ対等。v2からモバイルAPIまで合わせてさらに広がった。
  • Wails 3: 主要統合はできるが、一部エッジケースは不足。
  • Flutter Desktop: 基本的なシステム統合はあるが、深さはElectronより浅い。system_traywindow_managerなどのコミュニティ パッケージが補う。
  • Qt: 非常に強い。25年のノウハウ。

22.3 インラインコード推奨パターン

ウェブビュー埋め込みタグのようなものは、インライン バックティックで囲んで表記する。本文では <webview> のようなタグを使わず、バックティック内でのみ扱う。<window> のような表記も同様にインライン コードで囲む。


23章 · コード署名と公証 - 本物の配布の関門

23.1 macOS

  • Developer ID証明書(Apple Developer Program、年99ドル)
  • コード署名 + Notarization(公証)が義務化(macOS 10.15以降)
  • Sparkle自動アップデート、またはelectron-updater

23.2 Windows

  • Authenticode証明書(年300ドル前後から)
  • EV(Extended Validation)証明書は1500ドル+ - SmartScreen評判がより速く積み上がる
  • electron-builder · NSIS · Squirrel.Windows · Inno Setup

23.3 Linux

  • Flatpak(Flathub)
  • Snap(Canonical)
  • AppImage
  • deb(Debian/Ubuntu)
  • rpm(Fedora/SUSE)

23.4 2026年トレンド

GitHub Actionsがビルド/署名/配布の標準パイプラインになった。Tauri Action · electron-builder Action · flutter-action - ワークフロー テンプレートが5分で適用できる。


24章 · 自動アップデート システム

24.1 Squirrel(.Windows/.Mac)

Atom時代からある古典的なアップデータ。Electronがデフォルトで採用。デルタ アップデートをサポート。

24.2 electron-updater(electron-builderの一部)

GitHub Releases · S3 · カスタム サーバからアップデートを取得する。最も多く使われるElectronアップデータ。

24.3 Tauri Updater

Tauriの公式アップデータ。minisignでパッケージ署名検証。

24.4 Sparkle(macOS)

Andy Matuschakが2006年から作っているmacos専用アップデータ。ほぼすべてのmacOSネイティブ アプリが使っている。

24.5 Google Omaha / omaha-server

Google Chromeが使っているアップデート サーバ。オープンソースのomaha-serverで自己ホスティング可能。


25章 · 韓国と日本のデスクトップ アプリの風景

25.1 韓国

  • カカオトーク デスクトップ: Electronベース。2026年でも最もインストールされている韓国製デスクトップ アプリ。
  • Naver Whale: 独自のChromiumフォーク ブラウザ + Whale Winterモード。
  • Jandi デスクトップ(Toss/Jandi): Electron。
  • Notion韓国: 本家Electronそのまま。
  • LINE デスクトップ: Electronベース(LINEは日本のNHNだが韓国でも広く使われている)。

25.2 日本

  • GitMind デスクトップ: マインドマップ ツール。Electron。
  • サイボウズ Office デスクトップ クライアント: 日本企業コラボの標準。Electron。
  • Backlog Desktop: Nulabのプロジェクト管理アプリ。Electron。
  • 楽天 ラクラク メール: デスクトップ メール クライアント。
  • マネーフォワード デスクトップ: 家計簿。
  • SmartHRの一部モジュール: Flutter Desktopを実験中。

26章 · ハイブリッド パターン - ネイティブの中にウェブビューを挿す

クロスプラットフォームではなく、単一OSのネイティブを使いながら、特定の画面だけウェブビューで扱うパターンも多い。

26.1 Windows

  • WPF + WebView2: WPFアプリで特定ページだけChromium Edge埋め込み
  • WinForms + WebView2
  • WinUI 3 + WebView2

26.2 macOS / iOS

  • AppKit + WKWebView
  • UIKit + WKWebView
  • SwiftUI + WKWebView ラッパー(正式な WebView コンポーネントが標準化される最中)

26.3 使用例

  • 韓国カカオバンク デスクトップの一部 - WPFベースにWebView2埋め込み
  • 日本の楽天の一部デスクトップ ツール - ネイティブ + ウェブビュー併用
  • 1Password 8の一部画面 - 本体はElectronだが課金/サブスク画面だけ外部ウェブ

27章 · 決定マトリクス - 5つの質問で絞り込む

27.1 質問1 - チームの主力言語は何か

  • TypeScript/JavaScript → Electron · Tauri · Wails · NeutralinoJS
  • Rust → Tauri · Slint · Iced · egui
  • Go → Wails
  • Dart → Flutter Desktop
  • C# → MAUI · Avalonia · WPF
  • Java/Kotlin → JavaFX · Compose Multiplatform
  • Swift → SwiftUI on macOS

27.2 質問2 - モバイルも同じコードベースか

  • 必須 → Tauri 2 · Flutter · Compose Multiplatform · MAUI · Lynx · React Native
  • 不要 → 他の候補すべて

27.3 質問3 - バンドル サイズがどれほど重要か

  • 非常に重要(20MB未満) → Tauri · Wails · NeutralinoJS · Slint · Sciter
  • 中程度(50MB以下) → Flutter · Avalonia
  • 無関係(150MB+) → Electron

27.4 質問4 - Linuxデスクトップが一級市民か

  • 必須 → Electron · Tauri · Wails · Flutter · Qt · GTK · Avalonia
  • 不要(Windows + macOSのみ) → MAUIが可

27.5 質問5 - ライセンス制約は

  • 完全にMIT/Apacheが欲しい → Electron · Tauri · Wails · NeutralinoJS · Flutter · Iced · egui · Avalonia
  • LGPL可 → Qt(動的リンク)
  • GPL可 → Slint(または商用ライセンス)
  • 商用ライセンス購入可 → Sciter · Slint · Qt

28章 · アンチパターンと罠

28.1 「Electronだから重くてもいい」

逆である。Electronでも軽くできる。VS Codeがそうだ。ASARパッケージ、モジュール lazy ロード、V8スナップショット、仮想スクロール - 最適化テクニックが存在する。Electron採用が「最適化を諦める」言い訳になってはいけない。

28.2 「Tauriに変えればメモリが3分の1になる」

半分本当、半分嘘。空アプリは3分の1。しかし実アプリがChromium機能を多用すると(WebGL · コーデック · DRM)、システム ウェブビューがそれを全部サポートしなかったり、違う動きをしたりする。移行コストがメモリ削減を上回ることがある。

28.3 「Flutter Desktopはモバイルと同じだから無料」

UIコードは同じ。しかしシステム統合コード(トレイ · メニューバー · ショートカット · ウィンドウ管理)は全部新しく書く必要がある。「コード90%共有」は真実だが、その10%がデスクトップ体験を作る。

28.4 「Qtは無料ではない」という誤解

QtはLGPL動的リンクなら無料。商用ライセンスが必要なのは静的リンクや、モバイル/組み込みなど特殊ケースである。Qtライセンスへの恐れが合理的なツールを阻んではいけない。

28.5 「新しいツールは無条件に良い」

Slint · Iced · Xilem · Lynx - 興味深いが本番リスクがある。試作品やサイド プロジェクトなら良い。ミッション クリティカルなプロダクトなら5年以上の道具が安全。


29章 · 実際の移行事例 - 何が良くて何が痛いか

29.1 Linearデスクトップ - ElectronからTauri評価

Linearは2024年にTauri移行を評価したと伝わる。結果は「当面Electron維持」。理由はmacOS Apple SiliconでElectronが意外と良く動き、移行人員コストが大きいこと。

29.2 カカオトーク デスクトップ

長年自社C++クライアントだったが、2020年代初頭にElectronベースに転換。結果は両義的 - UI更新が速くなったが、メモリ使用量が大きくなったとユーザーから不満。

29.3 Cap 画面録画

最初からTauri 2でスタート。ビルド サイズ12MB、Apple Siliconで軽い。Tauriのモデル事例の一つ。

29.4 1Password 7 → 8

1Password 7はネイティブだったが、8でElectronベースに変更。コード共有と機能速度のための決定だったが、一部のmacOSユーザーが「以前の方が良かった」と不満。Electronの価格を明確に示した事例。


30章 · 結論 - 「あなたの一番」は何か

5分の意思決定ガイド:

  1. チーム言語が最も強力なフィルタ: 言語が決まれば候補が半分以下に減る。
  2. モバイル共有の要否が二番目のフィルタ: 必須ならTauri 2 · Flutter · Compose · MAUI · Lynxに狭まる。
  3. バンドル サイズ / メモリ上限が三番目のフィルタ: 低スペックPCのユーザーが多いならElectronは最後の候補。
  4. システム統合の深さが四番目のフィルタ: トレイ · 通知 · ショートカット · メニューバーがすべて一級である必要があるならElectron · Tauri · Qt。
  5. ライセンス + 予算が五番目のフィルタ: 会社の状況によってSciterやQt商用ライセンスが合理的になることもある。

この5つの質問で候補が1~3個に絞られる。次は30分のPoCで決定 - 起動時間、ビルド速度、パッケージング単純さが本当に約束通り良いかを自分で確認する。

「最高のクロスプラットフォーム デスクトップ フレームワークは何か」は間違った問いだ。「我々のチームに合理的なツール3つは何か」が本当の問いであり、この記事はその答えに素早く辿り着くための地図である。


References