Capacitor製のWebViewアプリからReact Native製のハイブリッドアプリへ

React Native Meetup #16
https://react-native-meetup.connpass.com/event/317621/

Transcript

1. Capacitor製のWebViewアプリから React Native製のハイブリッドアプリへ @yukukotani 2024/05/30 - React Native Meetup #16
2. 小谷 優空 / @yukukotani ・SWE / VP of Technology @ Ubie, Inc. ・React Native 1年生 ・Student @ Univ. Tsukuba 自己紹介
3. 趣旨 ・UbieでCapacitor製アプリをReact Native製にリニューアルした ・移行の背景 ・React Nativeでハイブリッドアプリ、どうやるのか
4. 目次 1. アーキテクチャ概観 2. 移行の背景 3. ハイブリッドアプリの実装
5. モバイルアプリ誕生以前 ・Next.jsでWebアプリを開発 ・SSRサーバーとして運用 SSRサーバー Web Browser アクセス ビルド Next.js
6. 移行前: Capacitorアプリの構成 ・全画面が単一のWebViewでリモート参照 → シンプルにOTAアップデート ・既存のWebアプリをモバイルアプリ向けにビルドし、別ドメインで配信 ・モバイルアプリ向けのビルドからは Capacitor API でネイティブ機能を利用 Web向け サーバー Mobile App向け サーバー Capacitor Web Browser アクセス Capacitor API でネイティブ機能呼び出し ビルド ビルド WebViewでアクセス Next.js 単一コードベースだけど 別ビルド・別インスタンス
7. 移行後: React Nativeアプリの構成 ・基本はCapacitorをReact Nativeに置き換えただけ ・一部の画面はReact Nativeで実装しつつ、WebViewも引き続き利用 ・Capacitor APIを代替するブリッジを自作 Web向け ビルド Mobile App向け ビルド Expo (React Native) Web Browser アクセス ビルド ビルド Next.js 自作のブリッジ でネイティブ機能呼び出し 一部画面のみ WebViewでアクセス
8. 目次 1. アーキテクチャ概観 2. 移行の背景 3. ハイブリッドアプリの実装
9. 前提：Capacitorはめちゃくちゃ良かった Webアプリがある状態でモバイルアプリのポテンシャルを評価する1st stepとして 超おすすめI „ Capacitorのおかげで1週間でモバイルアプリを出せ4 „ その後もアプリ用の工数はほぼゼロで、新機能を継続的にデリバリー
10. なぜ移行したか：MVPを超えて本格開発するため エコシステ% ユーザー体( i Ionic/Capacitorに投資している大企業が少な‰ i 結果としてか、メンテナンスが滞っているものが多‰ i OTAアップデートの仕組みもあるにはあるが、枯れていな‰ i ネイティブ側SDKとWebViewの整合性問題など i WebView 1枚に閉じた表現力の限h i Ionicはよくできているが、言語化しにくい細かい「アプリっぽくなさ」があ… i オフライン対応を進めるために、全面リモートWebViewをやめたい ・体調が悪いユビーのユーザーには、小さな違和感でも引っかかってほしくない
11. なぜReact Nativeハイブリッドアプリか エコシステ s Meta, Microsoft, Amazon, Shopify といったテックジャイアントの安心C s 3rd-partyライブラリも比較的よくメンテナンスされている Expƒ s EASの出来がかなり良€ s さらにRSC対応して最高になると賭けた（実際進んでるっぽくて嬉しいm s Expo SDKも豊富、かつ Managed Workflow でアプデも困りにくい TypeScripš s 引き続きWeb版の資産を生かしたハイブリッドアプリにしたかっÊ s WebViewと言語が揃うことは認知負荷が減る以外のメリットも大きい（後述）
12. 目次 1. アーキテクチャ概観 2. 移行の背景 3. ハイブリッドアプリの実装
13. WebViewからのネイティブAPIコール
14. Capacitorのプラグイン機構 Capacitorの場合、プラグインを使ってWebViewからネイティブ機能を呼べる Web
15. 自作のブリッジ機構 自作の機構では、まず React Native 側で公開したい関数を書く React Native 型をexportしておくのがミソ
16. 自作のブリッジ機構 関数群をwrapしたメッセージハンドラをWebViewに渡す React Native
17. 自作のブリッジ機構 Web側から関数をそのままのシグネチャで呼べる 裏でメッセージングが行われてReact Native側で処理が走る(=RPC) Web React Native側でexportした 型だけをimport ⁨⁩全く同じシグネチャで呼び出し
18. 仕組み：Comlink Web Workersの関数・オブジェクトをメインスレッドから透過的に扱うライブラリ https://github.com/GoogleChromeLabs/comlink
19. 仕組み：WebWorkerとWebViewのアナロジー Comlink は postMessage によるメッセージングを隠蔽する → WebViewもメッセージングできるので応用可能 ブラウザ メインスレッド Web Worker postMessage postMessage WebView React Native postMessage injectJavaScript App→WebはJS埋め込みで 無理やりメッセージを送る
20. JavaScript/TypeScriptで書けることのすごさ JavaScriptという標準化された規格に乗っているからこそ、 Webの豊富なエコシステムを応用できる TypeScriptで揃っているからこそ、シンプルな仕組みでRPCができる これはReact Nativeにしかできないこと
21. 宣伝：react-native-webview-rpc OSSなのでぜひ使ってください ~300行程度なので読んでみてください https://github.com/yukukotani/react-native-webview-rpc
22. Web版をモバイルアプリ向けにビルド
23. おさらい：構成 Web向け ビルド Mobile App向け ビルド Expo (React Native) Web Browser アクセス ビルド ビルド Next.js 自作のブリッジ でネイティブ機能呼び出し 一部画面のみ WebViewでアクセス ・既存のWebアプリをモバイルアプリ向けにビルドし、別ドメインで配信 ・WebViewからブリッジ(RPC)でReact Nativeの関数を呼び出し
24. 環境変数でWeb/モバイルアプリの処理を分岐 例）ネイティブAPI呼び出し、UI出し分け ネイティブAPI (RPC)とWeb APIを呼び分ける例
25. ビルド時点で環境変数を注入 Tree ShakingやDead Code Eliminationで別環境向けのコードは消える →Web版のバンドルサイズ等に影響を与えずにモバイルアプリ向け拡張ができる
26. その他
27. その他 話しきれないので懇親会で話しましょ@ WebViewへの認証情報引き継d 逆にリニューアル前のアプリのWebViewからのクレデンシャル引き継d WebViewスタック積みまくると重い問t DeepLinkとWebViewの関係Æ Magicpodとの連携
28. Thanks!