この記事の目的は、2025年に新しい React Native プロジェクトを開始する場合、他の開発者に Expo を使用するかどうかについて有意義な洞察を提供することです。

そうすることを決めた場合、多くの疑問が生じます：

• マネージドワークフローを使うべきか？
• ベアワークフローを使うべきか？
• Expo Go を使用すべきか？
• EAS を利用すべきか？
• CNG とは何か？
• そしてこれらはすべて、Expo なしでの React Native とどのように関連しているのか？

上記のすべての質問に対して、7年間 React Native に大きく依存してきたソフトウェア開発エージェンシーの技術的意思決定者としての私の知識と経験に基づいて回答することを目指しています。それほどに、弊社は React Native を本日のモバイルアプリ作成の優れた方法と考え、すべてのモバイルアプリケーションを React Native で提供しています。

そして正直に言うと、その大きな要因は Expo 自体と Expo のコミュニティです。

基本から始めましょう

このトピックに関する利用可能な文献は一般的に時代遅れです。多くの記事は以前の知識に基づいており、最新の機能に追いついていません。Expo は過去 3年間で大幅に進化し、React Native エコシステムは着実に「新しいアーキテクチャ」に適応しています。

これらの開発は、ネイティブ開発の複雑さを抽象化することにより、モバイルアプリケーションを構築、デバッグ、テスト、リリースすることを以前よりも簡単にしています。

React Native

数年前の React Native

主にウェブ技術（React、JavaScript、CSS、Flexbox）に精通した個人が、ネイティブ要素をレンダリングするモバイルアプリケーションを構築できるクロスプラットフォームフレームワークでした。

ビジネスの観点からは、主にシリアライゼーションとブリッジによるパフォーマンスの問題により、ある程度限定されていました。

技術的な観点からは、ネイティブ部分に触れずにネイティブ要素を持つモバイルアプリを提供できると（ウェブ）開発者を誤解させる可能性がありましたが、これはほぼ常に幻想であることが証明されました。ネイティブコードを書かなくても、ネイティブツール（XCode、CocoaPods、Android Studio、Maven）に精通することが必要でした。

それは使えないフレームワークでしたか？全くそんなことはありません。依然として利点は欠点を上回っており、今ではそれが以前よりも多いです。

iOS と Android の間でほとんどのコードベースが共有可能であること、UI の組み合わせ可能性、およびストアに再提出することなくユーザーにコード変更をプッシュできる能力は、React Native にとって依然として重要なセールスポイントでした。

今日の React Native

私の意見では、幸運にも18歳になる前に、React Native は成長しています。それは、React、JavaScript/TypeScript、CSS/Flexbox を使用して、ネイティブ部分と対話することなくネイティブ要素をレンダリングするクロスプラットフォームモバイルアプリを開発するために、限定的なネイティブ知識またはネイティブ知識がない人々を可能にするフレームワークになりつつあります。

Hermes（React Native 向けに最適化された JS エンジン）、Flipper（デバッガー）、Fast Refresh（関数コンポーネントとフックの状態を維持する）、その他多くの機能とともに、ネイティブモジュールの自動リンク（2019年7月）などの機能により、この目標に向けて大きな一歩が踏み出されました。

「新しいアーキテクチャ」（私の2022年からの StackOverflow の投稿、または公式ドキュメントを参照）で、React Native はついにその主なパフォーマンス制限と UI の複雑さを克服しています。

しかし、私の考え（弊社チームの意見を反映したもの）では、最も重要なステップは間違いなく Expo であり、特に過去3年間に導入された変更でした。

Expo

数年前の Expo

React Native 開発者向けのフレームワークであり、プリビルドされたアプリと SDK を提供することで、ネイティブ開発の複雑さを簡略化することを目的としていました。開発者は Expo の SDK（現在 Expo Go として知られるアプリにプリビルドされている）を使用することに限定されていました。さらにネイティブ機能が必要な場合、Expo から純粋な React Native ワークフローに「エジェクト」する必要があり、その際に Expo モジュールの利用ができなくなりました。

コミュニティの Expo の機能とエコシステムの一部を利用しながらも、より多くの制御と柔軟性を求めるニーズに応えて、2019 年 6 月にベアワークフローが導入されました。これにより、開発者は Expo の SDK に制限されることなく Expo の一部を使用できるようになりました。これを可能にした重要なマイルストーンは、Expo の UniModules 機能であり、純粋な React Native プロジェクトで Expo モジュールを使用できるようにしました。

これは、ネイティブニーズに Expo の SDK が十分な場合、マネージドワークフロー（現在は Expo Go を使用することに似ている）を使用し、iosおよびandroidフォルダーに触れることなく進めることができることを意味していました。

しかし、Expo の SDK に含まれていない追加のネイティブモジュールが必要な場合、ベアワークフロー（基本的には Expo モジュールを使用する純粋な React Native アプリ）にエジェクトしました。Expo モジュールを引き続き使用できますが、Expo Go の機能は使用できず、アプリをデバイスにビルドし（Expo Go なし）、Android Studio と XCode を使用してネイティブ部分（iosおよびandroidフォルダー）を管理する必要がありました。

この例が示すように、過去にさかのぼるほど、Expo を使用するかどうかの技術的決定が重要になります。

それは完全に、そして私の意見では明確に変わりました。そして勝者は：Expo（つまり、React Native）です。

今日の Expo

クロスプラットフォームの React Native コードベースのネイティブコンポーネントをうまく抽象化するフレームワークであり、必要に応じて簡単にネイティブコードを書くオプションを提供します。そして EAS を使用すると、それはさらに多くのことになります。より迅速かつ容易に開発および出荷するための完全なツールキットです。

マネージドワークフロー（iosおよびandroidフォルダーがCNGによって継続的に生成され、ソースコントロールにコミットされずに管理される）からベアワークフロー（iosおよびandroidフォルダーが管理され、ソースコントロールにコミットされ、プロジェクト内で直接ネイティブコードを書くことができる）への移行はシームレスですが、おそらく不要です。

2021年4月に導入された Config プラグインを使用すると、開発者は Expo のapp.jsonを介してマネージドワークフローでネイティブコードを制御できるようになりました。その後、Expo は変更された構成に基づいてオンデマンドでネイティブのiosおよびandroidフォルダーを生成します。これは、マネージドワークフローの Expo アプリを使用する開発者がベアワークフローにエジェクトする必要がないようにするためのパッケージの作者に推奨される方法になりました。それほどに、ejectという機能は Expo から削除されました。それは時代遅れになり、マネージドとベアの間の境界線がぼやけてきました。現在は簡単かつ徐々に移行できます。

したがって、現在、マネージドとベアワークフローの Expo アプリの唯一の違いは、基本的にはコンフィグプラグインに基づいてネイティブフォルダーを生成するか（マネージド）、ソースコードにコミットしてプロジェクト内で直接ネイティブコードを書くことができるかどうか（ベア）という点です。

CNGを使用して、ローカル Expo モジュールを組み合わせることで、マネージドワークフローで独自のカスタムネイティブモジュールを書くことができます。これはほとんどのユースケースにとって十分である可能性が高いです。

EAS

Expo は、これまでに説明したフレームワーク以上のものに進化しています。Expo チームは、開発者がより迅速かつ容易にアプリを構築して出荷できるようにするために、さまざまなクラウド機能を開発しました。

それはいくつかのコンポーネントで構成されています：

• EAS Build：クラウド内でビルドすることを可能にし、Android Studio または XCode のセットアップを不要にします。これは、Mac から作業していない場合の iOS 開発にとって重要であり、XCode を置き換えることができます。
• EAS Update：アプリストアのレビュープロセスを経ずに、アプリの JavaScript、画像、およびその他のアセットを即座に更新することを可能にします。ベアワークフローとマネージドワークフローの両方で利用可能です。
• EAS Submit：Apple App Store と Google Play Store へのアプリの提出プロセスを簡素化します。提出プロセスのさまざまなステップを自動化し、より面倒でエラーが発生しやすいものにします。

これらの機能を使用すべきですか？

それは好みと予算次第です。例えば、Scriptide では通常ローカルでビルドするので、日常的な開発に EAS Build を使用しません。しかし、CI には良いオプションです。

一方、EAS Update と Submit に大いに依存しています。特に、チームがアプリ提出の手順（特に iOS 関連の直感的でない手順）に慣れていない場合、多くの時間を節約できるからです。

Expo を使うか使わないか？

弊社は決定が明確だと考えています。アプリが React Native で構築するのに適している場合は、常に Expo を使用すべきです。

より関連する質問はおそらく次のとおりです：Expo（および EAS）のどの部分を使用すべきですか？

Expo Go を使用すべき？

それは特定のニーズに依存します。はいよりもいいえの方が可能性が高いです。

はい： ちょうど始めていて実験したい場合は、Expo Go を使用してください。それはより簡単です。ダウンロードして、QR コードをスキャンし、JS バンドルを読み込んで、始めることができます。React Native チームもそれを推奨しています。

いいえ：

次のいずれかが必要な場合：

• ディープリンキングと URL スキーム（例：OAuth ログイン）
• プッシュ通知
• 支払い
• カスタムネイティブコード
• カスタムネイティブモジュール
• バックグラウンドタスク
• 高度なグラフィックスとアニメーション

技術的に可能であっても、Expo Go でそれらを実装することはお勧めしません。リリースプロセスが異なる方法で機能するためです。

ツール（XCode、Android Studio）に自信があり、アプリをローカルでビルドすることが問題でない場合は、それを使用することをお勧めしません。Go からアプリをリリースするときに環境が変わり、人生を複雑にする可能性があります。

expo-dev-clientを使用すると、技術的な制限なしでカスタムアプリで Expo Go のあらゆる機能（高度なデバッグなど）を使用できます。

マネージドワークフローかベアワークフローか

前述したように、主な違いはネイティブフォルダーを生成するか（マネージド）、ソースコントロールにコミットするか（ベア）、そして Local Expo Modules（マネージド）を通じてか直接（ベア）ネイティブコードを書くかです。

技術的には、ベアワークフローは現在（Expo CLI がインストールされている）ベア React Native アプリと同等です。React Native CLI で始める場合でも、通常、多くの Expo モジュールを使用します。これらは通常、特定の要件に対する最良のクラスです。そして、expo installは自分で行うよりもパッケージを互いに互換性があるように簡単にインストールするのに役立つので、Expo CLI で始める理由はありませんか？

結論： マネージドワークフローで始めて、ネイティブレイヤーの完全な制御が必要で、何をしているのかを知っている場合にのみベアに切り替えるべきです。

React Native CLI を選択する理由はありません。Expo CLI のベアワークフローで始めることには、特に他の利点はありません。

Expo Dev Client

こちらを使用するべきです。それによって失うものは何もありませんが、より良いデバッグ体験とその他の有用な機能を得ることができます詳細はドキュメントで。

まとめ

Expo を使用することはほとんど常に安全な賭けです。弊社にとっては、通常マネージドワークフローで Expo Go を使用しないことが最適なポイントです。

P.S.

私も Scriptide もいかなる形で Expo と提携しているわけではありません。構築されているものと、React Native を前進させる方法に感謝しています。これにより、ソフトウェア開発エージェンシーとしての弊社の生活がより簡単で楽しいものになります。未来が何をもたらすかに興奮しています。

もしご質問や記事に関するコメントがある場合は、メールまたはLinkedInでお気軽にご連絡ください。