この記事の目的は、2024 年に新しい 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 月）などの機能により、この目標に向けて大きな一歩が踏み出されました。

「新しいアーキテクチャ」（私のStackOverflow の投稿 2022、または公式ドキュメントを参照）で、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 の Bare ワークフローで始めることに対して、何の利点も提供しません。

Expo Dev Client

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

まとめ

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

P.S.

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

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