React で書いた Web アプリは、スマホでもそのまま動くのか

ブラウザでもスマホアプリでも動くアプリのフロントエンドを React で作ることになりましたが、モバイルの開発は初めてでした。
そこで、いくつも疑問が出てきました。
Web アプリのコードは、スマホアプリの中で動くのか。
プラットフォームごとに別のプロジェクトを作らなければならないのか。
調べて分かったことを書きます。

※本記事は英語から日本語へ Claude を使って翻訳しています。

結論

Web アプリのコードは、スマホアプリの中で動きます。
プラットフォームごとに別のプロジェクトを作る必要はありますが、Web 版とモバイル版のあいだで UI 実装の一部を共有できます。
ただし、そのぶんのコストもかかります。

調べてみると、React を使ってクロスプラットフォームのアプリを開発する方法は、主に三つ見つかりました。

方法	長所	短所	向く場面（例）
ネイティブの言語	- 性能の上限がいちばん高い - Apple と Google による長期のサポートがある	- 一つのアプリなのにコードベースが複数になる	作り込んだ UX が必要で、モバイル利用者への要求が高く、さらに複数のコードベースを維持できる余力があるなら、React のアプリに加えてネイティブの言語で書く。
React Native	- 共有した一つのコードベースから複数のプラットフォーム版を作れる（ただしプラットフォーム固有のコードが必要になる場合はある） - 求められるのは主に JavaScript の技能 - 挙動がネイティブに近い	- 性能の上限が下がる1 - フレームワークの更新が難しい - 標準の CSS が使えない（スタイルはコンポーネントごとに JavaScript のオブジェクトで定義する）2	スマホアプリを作り込みたいが、複数のコードベースを維持する余力はないなら、React Native を使う。
ガワネイティブ（WebView で包む殻）	- CSS が使える - 主となるコードベースが一つで済む - Web を先に作るプロジェクトなら開発が速い	- 複雑な操作では性能の上限が下がる3 - ネイティブの機能にはプラグインか橋渡しのコードが必要4	利用者の大半が Web アプリを使い、スマホアプリは二番目の入口だと見込むなら、ガワネイティブで React の Web アプリを包む。

表の評価は、実測に基づくものと、一般的な傾向にとどまるものが混ざっています。
「フレームワークの更新が難しい」「開発が速い」「保守の負荷」については、測ったものが手元にありません。
一般的な傾向であり、要件や構成で変わります。

分かったこと

Web アプリとスマホアプリは、何が違うのでしょうか。

• Web アプリは Web の技術（HTML、CSS、JavaScript）を使います。
• ネイティブのスマホアプリは、iOS なら Swift、Android なら Kotlin か Java を使うのが一般的ですが、JavaScript を動かすこともできます。

したがって、Web アプリの HTML/CSS の部分は、モバイルのネイティブ UI にそのまま使えません。

Web とスマホに向けたクロスプラットフォームのアプリを開発するとき、スマホ版の作り方は主に三つあります。

1. ネイティブの言語：Swift か Kotlin と、別立ての Web プロジェクト
2. React Native：JavaScript か TypeScript で書いた UI を、iOS と Android のネイティブ UI として描画するフレームワーク。Web と共有するには React Native for Web などの追加のレイヤーが要り、既存の React DOM のコードをそのまま使い回せるとは限らない
3. ガワネイティブ（Capacitor など）：各プラットフォームのネイティブの言語で書いた薄い入れ物の中に、Web アプリを描画する WebView（アプリに埋め込んだブラウザ）を持つ

このように、三つとも長所と短所があり、プロジェクトの必要に応じて選ぶことになります。
決め手になるのは、次の問いに答えられるかどうかだと思います。

• 主戦場はどのプラットフォームなのか
• 利用者の体験はどこまで良くする必要があるのか
• チームにどの技能があるのか

まとめ

Web アプリのスマホ版を実装する方法は、いくつかあります。
Web 中心のチームの多くは、開発が速くなるという理由でガワネイティブに傾くかもしれません。
ただし、より作り込んだ UX と、モバイルとの深い連携が必要になったら、チームの開発と保守の体制に応じて、ネイティブに描画するクロスプラットフォームのフレームワークか、ネイティブの言語を検討することになるかもしれません。

なお、この記事で比べたのは、React を前提にした選択肢だけです。
React にこだわらないなら、Flutter という道もあります。
Dart で書き、独自の描画エンジンで画面をすべて自前で描くため、ネイティブの部品にも WebView にも寄りかかりません。
既存の React の Web アプリと共有できるものは無くなりますが、モバイルの体験を最優先するなら、検討する価値はあります。

1. 同じアプリを三つの技術で作って実機で測ったベンチマークでは、iOS でのフレーム落ちが React Native 15.51%、ネイティブ 1.61% でした。公式ドキュメントも、JavaScript スレッドが 16.67ms 以内に終わらなければフレームを落とすと説明しています。ただしこのベンチマークは Expo でビルドしており、各フレームワークのバージョンは示されていません。 ↩

2. 公式ドキュメントのとおり、CSS ではなく JavaScript のオブジェクトで書きます。 ↩

3. Capacitor の公式リポジトリに、Android の WebView で複雑な画面が引っかかるという報告があります。Chrome の WebView 側の制約とされ、いまも解決していません。 ↩

4. ガワネイティブでは、プラグインを通してネイティブの機能を使います。 ↩