TauriはWebフロントエンドをOSのWebViewで包むアプリ基盤

Web UIとRustバイナリを一つのアプリにする

Tauriは、HTML、JavaScript、CSSへコンパイルできるフロントエンドをユーザーインターフェースに使い、Rustで作ったバイナリをバックエンドに置くフレームワークです。フロントエンドはバックエンドのAPIと通信し、デスクトップとモバイルの配布物へまとめられます。READMEが掲げる小さく高速なバイナリという表現はプロジェクトの目標であり、個々のアプリでサイズや起動時間を測った結果ではありません。

ウィンドウ管理にはtao、描画にはWRYを使います。WRYはOSのWebViewを共通インターフェースとして扱い、macOSとiOSではWKWebView、WindowsではWebView2、LinuxではWebKitGTK、AndroidではAndroid System WebViewを利用します。同じWebコードでも実際の描画エンジンとOSの版が変わるため、ブラウザだけでなく配布先のWebViewでレイアウト、入力、フォント、権限を確認する必要があります。

localhostサーバーに依存しない表示経路

機能一覧にはNative WebView Protocolがあり、TauriはWebViewの内容を配るためにlocalhostのHTTPまたはHTTPSサーバーを作らないと説明されています。Webアプリをそのまま公開サーバーとして起動する構成とは違い、アプリ内部の資産とRust側のAPIを結ぶ境界を設計します。どのコマンドをフロントエンドへ公開するか、ファイルやOS機能へどこまで触れさせるかは、アプリごとに定義する必要があります。

Tauriにはapp bundlerがあり、macOSの.appと.dmg、Linuxの.deb、.rpm、AppImage、WindowsのNSISによる.exeとWiXによる.msiを作れます。デスクトップ向けのself updater、システムトレイ、ネイティブ通知、GitHub Action、VS Code拡張も機能として列挙されています。配布形式が多いことは、署名、依存WebView、更新経路、各OSのインストール権限を個別に管理する必要があることも意味します。

create-tauri-appから始める条件

開始手順は、対象システムのprerequisitesを入れ、create-tauri-appで新しいプロジェクトを作る流れです。READMEの例はnpm create tauri-app@latestです。これはプロジェクトの雛形を作る入口で、完成したアプリの機能、権限、配布署名まで自動で決めるコマンドではありません。採用するフロントエンド、RustのAPI、必要なプラグインを決めてから権限を絞る必要があります。

対応表ではWindows 7以降、macOS 10.15以降、iOSとiPadOS 9以降、Android 7以降が挙げられています。LinuxはTauri v1でwebkit2gtk 4.0、Tauri v2でwebkit2gtk 4.1が必要で、例としてUbuntu 18.04とUbuntu 22.04が示されています。なおAndroidは現在8以降と記載され、表の下限との違いがあります。表だけをコピーせず、採用するTauri版、SDK、WebViewパッケージ、配布対象を固定して確認するのがよいでしょう。

デスクトップとモバイルの共通部分を見極める

TauriはmacOS、Windows、Linux、Android、iOSを同じ枠組みで扱いますが、OSのWebViewと配布方式は同一ではありません。WindowsのWebView2、LinuxのWebKitGTK、AppleのWKWebView、Android System WebViewでは、CSS、フォント、メディア、セキュリティポリシー、入力方法が変わります。フロントエンドを共有できても、ウィンドウ、通知、トレイ、ファイル選択、バックグラウンド動作を同じ前提で扱えない部分があります。

フロントエンドとRustバックエンドのAPIがアプリの境界になります。ARCHITECTURE.mdへ案内されているように、tao、WRY、WebView、バックエンドの関係を追ってから、OS固有の機能をどの層へ置くかを決めるべきです。配布前には、対応OSの最小版、WebViewの更新状態、権限要求、クラッシュ時のログ、更新失敗からの復帰を端末ごとに記録します。

ビルド成果物と安全性を別に検証する

バンドラーやself updaterが用意されていることは、生成されたインストーラーが自社の配布要件を満たすことを意味しません。署名証明書、更新サーバー、ロールバック、インストール時の権限、アプリが読み書きするディレクトリを実際のパイプラインで確認する必要があります。WebViewへ公開するRustコマンドに過剰なファイル権限を与えないことも、アプリ設計の中心です。

Native WebView Protocolはlocalhostサーバーを作らない構成を示しますが、これだけで入力や外部接続が安全になるわけではありません。ユーザー入力をRustへ渡す境界、外部URLの読み込み、通知やトレイからの操作、OS別のWebView更新を個別にレビューします。GitHub ActionやVS Code拡張も便利な部品として列挙されていますが、CIの秘密情報、生成物の署名、拡張の権限はアプリ本体と別の審査対象です。

コミュニティ、ドキュメント、ライセンス

貢献する人には既存issueを確認し、Discordで担当状況を確かめ、Contributing Guideを読んでからプルリクエストを出すよう案内されています。RustとJavaScriptのソース内にインラインドキュメントを置く方針があり、ドキュメントサイトのホスティングリポジトリも別に示されています。TauriはCommons Conservancyのプログラムとして持続可能なオープンソースコミュニティを目指し、Open Collectiveで支援を受ける組織形態です。

コードのライセンスは、該当箇所によりMITまたはMIT/Apache 2.0です。ロゴはCC-BY-NC-NDで、コードとロゴの条件は同じではありません。ライセンスは再利用の法的条件を定めますが、WebView、SDK、依存ライブラリ、アプリが同梱する素材の条件や、配布後のサポートを一つにまとめるものではありません。Tauriを選ぶなら、まず一つのフロントエンドで最小OSセットを作り、権限、実行ファイル、インストーラー、更新、画面表示を通してから対象プラットフォームを増やすのが堅実です。

編集部の結論

Tauriは、HTML、JavaScript、CSSへコンパイルできる既存のフロントエンドを使いながら、RustのバイナリとOS標準のWebViewでデスクトップやモバイルへ配布したい開発者に適しています。localhostサーバーを前提にしないNative WebView Protocol、各OS用のバンドル、システムトレイ、通知が判断材料です。反面、WebViewの種類、OS版、Rust側の権限、署名と更新、モバイル固有の挙動は個別に検証する必要があります。READMEは対応表と開始コマンドを示しますが、アプリの安全性や性能を一括で保証するものではありません。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes