💫

Tauri2でスマホアプリをWebの知識だけで高速開発した感想

2024/12/05に公開

初めに

恐怖のメール

11月某日にこんなメールが来た

昨年のGoogle play developer consoleの規約改変直前に、駆け込みでアカウントを作っていたのでした。いつかはこういう通知が来るだろうと思っていたが、忙しさにかまけて対応するのを忘れてしまっていました。

スマホアプリ開発未経験者がこの先生きのこるには

個人的な事情で恐縮ですが、私はWeb系のエンジニアとしては経験がありますがスマホアプリについてはほぼ未経験です。正直メールが来た時点では最低限の体裁を整えた形でリリースできる自信が全くありませんでした。

Tauri2という福音

完全にこれは僥倖だったのですが、おりしも、10/2にTauri2が安定版リリースを果たしたばかりでした
https://v2.tauri.app/blog/tauri-20/

結果

結論から言うと1週間程度で音声入力で壁打ちするためのアプリを制作してリリースできました。(限定公開アプリ)。なのでアカウントの削除は回避されました。

Tauri2ってどうなの?

スマホアプリ未経験と言いましたが実際は(個人開発など、趣味の範囲内で)若干の経験があります。これまでに使ってきた技術スタックは

  • React Native
  • Capacitor

という、Tauri2と同様、ネイティブ言語上ではWebViewを動かし、その上で(主に)JavaScriptを動かすことでスマホアプリの機能性を実現するアークテクチャのスタックを使用していました。
正直なところ詳細は避けますがこれらのスタックの使用経験から、スマホアプリの開発は敬して遠ざけていました。なぜかというと

  • ネイティブ機能がうまく動作しないのでGitHubのissueを掘って問題解決する。もしくは自分でIssueを挙げる
  • ビルドがうまくいかないので同上
  • デバッグがうまくできないので同上

といったようなことがあったからです。
また個人的な事情を言うと私はReactについてはあまり経験がないので、React Nativeの開発者体験があまり良くないと言うこともありました。
ただ、これらの技術スタックに触っていたのは1-2年程度前のことになりますので、今はこれらの問題は解決されているものと思います。

Tauri2に対する期待値もそれほど高くありませんでした。そもそもTauriはデスクトップ向けのスタックという印象もあり、メールが来た時点では全く視野に入っていませんでした。技術ニュースなどでも「Eelctron代替」と紹介されることが多い。

なのですが、この期待はいい意味で裏切られました。

Tauri2 意外とモバイル開発に使えそう

使ってみて以下の3点がいいなと思いました。

1.🥳自由度の高さ X 🍂枯れた技術の安定性

Tauri2で開発したアプリをビルドするまでのツールチェインは以下のようになります(JSのビルドツールにViteを選択した場合)

ユーザのJavaScriptコード -> ①JavaScript Framework(React, Vue, Solid...) -> ②Vite / ③Tauri(Rust) -> ④ネイティブコード(Kotlin, Swift) -> スマホOS(Android, IOS)

  • ①のJavaScript Frameworkは自分で好きなものを選ぶことができます。
  • ②ViteはJSのビルドツールとしては業界標準と言ってよく安定性が高いです。
  • ③Rustは型安全性、メモリ安全性がとても高い言語です。型の縛りやメモリ管理の縛りがきつい分Rustのコードの安定性はとても高いです。
  • ④Tauriの思想上、スマホのネイティブ言語のコードの機能はあくまでスマホOSのAPIを呼び出すためのスタブとしての役割に限局されており、メインのロジックはRust上で提供されています。つまり、ネイティブコードの不安定性やデバイスによる差異を③のRustのコードで吸収している格好になります。

このように安定性を重視した構成な一方、①〜④の全ての層で、ユーザがフロントエンドフレームワークを選択したり自前で機能を実装したりできる自由があります。
安定しているツールチェインを使えばよくわからない理由でビルドできないといった理不尽なバグに苦しめられなくて済み、かつ不足している機能を自前実装する自由もあります。

2.一つのコードベースで💻デスクトップも🌐ブラウザ版もいける

デスクトップについては言うまでもないですね。
ブラウザ版については若干コードベースの修正が必要になるかもしれません。例えば

  • クレデンシャル情報の管理方法などアーキテクチャレベルの修正
  • Tauri特有のAPIを使っている箇所の修正

アーキテクチャに関してはブラウザアプリにしたい場合ブラウザアプリ化を見据えて最初に設計しておくといいでしょう。実際Tauri上で動作するJSコードはViteでビルドされたSPAなので、そのような設計にしておいて損はないと思います(SSRがやりたい場合とかは別ですが)。
Tauri特有のAPIに関して言うとシグネチャがブラウザのAPIに限りなく寄せてあるので、最小限の修正で済みました。例:
https://v2.tauri.app/reference/javascript/http/

個人的には、社内システムのクライアントアプリとかを作りたい時とかにこれはすごくメリットがデカいのではと思っています。
PWAでも頑張れば同じようなことができなくもないですが、ネイティブ機能が使えるのは大きいです。またアプリの配信をどうするかという問題もあります。
余談ですが私が以前所属していた会社の先輩でPWAとサービスワーカーを使って現場で使う社内ツールを作っている人がいたのを思い出しましたが、Tauri2を使えばそういう苦労もなくなるかもしれません。

3.🎯ターゲットデバイスの違いを意識せずにネイティブ機能を実行

最後に、ネイティブ機能について紹介します。先ほど申し上げた通り、アプリのメインルーチンはRust上で動作し、ネイティブ機能を実行する際はRustのコードからネイティブコードを通じてOSのAPIを叩くという構成になっています。(JavaScriptからのRustのコード実行はCommandという形で定義してJS上から実行できます。)
Tauri2(Rust)のレイヤーで抽象化しているおかげでターゲットの違いを意識せずにネイティブ機能を実行できます。
各種のネイティブ機能は、Pluginという形で提供されており、各機能がTauri本体と疎結合になっています。
バックグラウンド実行など、モバイル/デスクトップアプリでの一般的な用途にはTauri本体にtauri::async_runtime::spawn といったAPIが用意されています
WevView上のJSコード、Tauri本体、プラグイン+ネイティブコードそれぞれが疎結合になるように注意深くアーキテクチャが設計されているのがお分かりいただけると思います。

実際の開発

技術スタック・アーキテクチャ

バックエンド: Tauri2
ビルドツール: Vite
FrontEnd : Solid.js

よかった点

デバッグはそれなりにやりやすい

chrome://inspect/#devices による開発者ツールの表示や、adb logcat などを使えばプリントデバッグ的なことができます。HMRもある程度までは機能します。

firebase browser SDKやその他のライブラリがちゃんと動いた

個人的に一番意外だったのはfirebase browser SDKがWebView上でちゃんと動いたことです。正直動かないと思っていました。開発していたアプリはデータストアや認証にfirebaseを使用していたので、これが動くことでかなりの工数削減につながりました。
また、
https://github.com/ricky0123/vad
こちらのwasmを使っているライブラリも適切に設定すればちゃんと動作しました
Viteは神

大変だと思われる点

Rustコードのデバッグが難しい

例えばプラグイン
https://v2.tauri.app/reference/javascript/http/
を使った時、HTTPエラーでデータのフェッチに失敗した時どこにどうエラーが出るのかよくわかっていません。また、Rustは難解な言語なので習得には時間がかかりそうです。

Webの知識は実際必要

当然ですがTauri2はWebの技術スタックベースなのでWebの知識は必要になります。例えばcorsやcookieなどと言ったことの詳細まで把握していないと思わぬところでハマる可能性が高いと思います。

古いスマホでは動作しない?

Google playに審査に出した際に次のような問題が発生しました。

手元の実機では発生しませんし、正直これだけだと対処しようがないと思われたのですが、調べたところ、2020年前後発売のSamsung galaxyでこのエラーメッセージが出るそうです。仕方ないのでAPIレベルを24(Android 7)から31(Android 12)まで引き上げて対処しました。このように対処したところ審査にも通り、うまく行きました。
何かの間違いで、古いAndroidでは動作しないプラグインを入れてしまっているのかもしれませんが、要調査です。場合によってはTauri2のGitHubにIssueを挙げたいと思っています。

今後の課題と展望

機種による相性の問題

前項で書いた通り、機種による相性の問題がまだありそうです。正直ここを克服しないとproduction readyの技術スタックとはいえないかもしれません。

知名度が低い

ReactNativeなどと比べてスマホアプリの開発環境としての知名度は低いと思います。

業務システムのクライアントアプリとか作るのに便利そう

前の項目で一回述べましたが、ローコストに業務システムのクライアントアプリとか作るのに便利そうです。

ゲーム開発とかにも使えそう

3Dをゴリゴリ使ったゲームは流石に難しいでしょうが、いわゆるブラウザゲームと呼ばれるような、ブラウザのJSとHTML、CSSだけで完結した2Dのゲームとかならいけそうな気がします。ブラウザゲームなどをスマホゲームにパッケージして展開していくことも簡単になりそうです。

以上です。

Discussion