毎年、React Native コミュニティのコアコントリビューターは React Native チームと集まり、このプロジェクトの方向性を共同で検討します。昨年も例外ではありませんでしたが、小さな違いがありました。通常は React Universe Conf（旧 React Native EU）の前日に Wrocław の Callstack HQ で集まりますが、2024 年は過去の経験を踏まえ、サミットを連続する 2 日間で開催し、より多くの非構造化された交流時間を確保しました。この年次の伝統は、コントリビューターが見解や懸念を共有し、コアチームが計画を共有して React Native エコシステムの主要な貢献者（パートナー企業、個人ライブラリ作者、協力者など）からフィードバックを得る貴重な機会になっています。サミットは以下のトラックに分かれて議論を行いました。
- Releases
- What's next after the New Architecture?
- Web APIs spec for Native Modules
- LeanCore 2.0
- Nitro Modules - Unblocking View Components by exposing props as
jsi::Values
- Out Of Tree Platforms & CocoaPods
- React Native on Desktop
この記事では、この集まりで得られた結果の概要をお伝えします。
Releases
React Native のリリースプロセスについて広範に議論しました。コアチームは Meta 以外のコントリビューターがリリースに関与する価値を認めており、特に Out-of-Tree プラットフォーム（例：React Native visionOS）、ライブラリ（Reanimated）、フレームワーク（Expo）にとって有益な nightly リリースの重要性を強調しました。
リリース頻度については、修正をより速く出したいという要望と、サードパーティライブラリやアップグレード作業への影響を懸念する声とで意見が分かれました。また、意図しない破壊的変更を減らす方法や、React Native とサードパーティ依存関係の互換性に関するコミュニケーション改善策についてブレインストーミングしました。今回のセッションは、React Native のリリース管理がどれほど複雑で繊細な問題であるかを改めて示しました。
What's next after the New Architecture?
New Architecture が安定版としてリリースされた今、次に注力すべきことを議論しました。次に来る大きな取り組みは何か、という点で話題は以下のような項目に集まりました。
- Web compatibility
- React Strict DOM プロジェクトの方向性を巡る議論では、これは一時的なポリフィルとして扱うべきであり、Xplat チームが React Native のコアに適切なクロスプラットフォーム機能を実装していくべき、という結論に近い意見が出ました。
- コア API の安定化
- アプリ開発者、ライブラリ作者、Out-of-Tree プラットフォームにとって「安定化」が何を意味するのか、より合意が必要であることが明らかになりました。例えば、共有される C++ コードベースから iOS と Android 固有のロジックを抽出する必要が出てくるかもしれません。これは LeanCore 2.0 の議論とも一部重なります。
- 旧アーキテクチャのサポート
- 予想どおり、並行レンダリングに基づく React 19 の新機能は旧アーキテクチャでは動作しません。新機能は主に新アーキテクチャをターゲットにしており、React 19 のリリーススケジュール上の制約から、新旧アーキテクチャの間でどこまで機能を共存させるかの線引きはまだ明確ではありません。
- React Native 向けサードパーティライブラリ
- 現在、ライブラリ作者は TurboModules、ExpoModules、最近では NitroModules を使ってネイティブ機能を橋渡しできますが、それらをうまく使うためのドキュメントがより必要です。
- Brownfield ドキュメント
- サミット開催時点でネイティブアプリに React Native を統合する公式ドキュメントが古くなっていましたが、その後 Android と iOS 向けによりシンプルで最新のドキュメントが提供されました。
- Metro の web 向け tree-shaking
- コアの Metro チームはこの分野で Expo チームの作業を取り込むことに前向きです。
Web APIs for Native Modules
このセッションは Microsoft の RFC に焦点を当て、Web API のサブセットを React Native に導入するというアイデアを議論しました。目的は、馴染みのある API を活用して Web 開発者を呼び込み、既存の多くのオープンソース Web ライブラリへのアクセスを開くことにあります。
Web API 仕様に準拠することは、React Native の成長にとって有益であり必須でもあり、Many Platforms のビジョンや react-strict-dom プロジェクトとも整合します。Web は仕様を通じて統一されたインターフェースを提供していますが、現在の React Native コミュニティモジュールはそのような統一を欠いています。
Microsoft はまず実装可能な重要な Web API を約 200 個特定しており、対応プラットフォームは iOS、Android、Windows、macOS です。ライブラリ開発者は可能な限り Web 仕様に API を合わせることを推奨され、これによりコードの移植性と開発者体験が向上します。
ただし、この提案にはいくつかの課題があります。
- API のガバナンス（別リポジトリで管理する必要があるか）
- あるプラットフォームが W3C 仕様にない挙動を許す場合の仕様からの乖離
- 不要なモジュールをバンドルしない方法（例えば Babel プラグインでの選別）
- 取り組みのスコープが非常に大きい点
セッションの結論としては二つの主要な点が強調されました。第一に、可能な限り Web 互換の仕様を採用することに対してコミュニティ全体で強い一致があること。第二に、各プラットフォーム向けの Web API 実装をどう技術的に切り分けて維持するかについて明確な戦略が必要であることです。
Microsoft と Callstack が共同で RFC を洗練し、より小さな API セットでのプロトタイプ実装（PoC）をコミュニティイニシアチブとして作ることが提案されました。この段階的なアプローチにより、範囲を広げる前に設計と開発者体験を検証できます。
LeanCore 2.0
2019 年に React Native チームは Lean Core イニシアチブを開始し、コアの表面積を減らし、古くなったレガシー API やコンポーネントを削減することを目標にしました。以降、React Native のコンポーネントや API のクリーンアップは再度必要になっています。多くのコンポーネントが積極的にメンテされておらず、コミュニティが提供するより良い代替が存在します。また、重複しているコンポーネントは最終的に統合されるべきです。
JS 側の多くの API は真にプラットフォーム非依存ではなく、iOS や Android 固有の実装に結び付いています。例えば Pressable には android_disableSound や android_ripple のようなプロパティがあります。理想的には、React Native のコンポーネントは特定のプラットフォームに紐づかない最小限の API 表面だけを持つべきです。
Out-of-Tree プラットフォームが成長するにつれ、コアのコンポーネントと API の表面積を削減する道筋が必要であり、これはコアチームの負担軽減だけでなく、Out-of-Tree プラットフォームやライブラリのメンテナが追従しやすくする効果もあります。加えて、重複するコンポーネントや学習コストが減ることで、新しいアプリ開発者が React Native を始めやすくなります。コミュニティにより良い代替がある場合は、開発者にその利用を案内することができます。
セッションでは以下を議論しました：
- Lean Core の大きな動機付けと関係者にもたらす利益（開発者、ライブラリ保守者、Meta など）
- 実際のプロダクション React Native アプリで使用されているコンポーネントの集約ビュー
- コアから削除する候補となる基準
- Lean Core 2.0 を実行するための明確なアクションプラン：
- 廃止プロセスのハイレベルフロー
- Meta が内部で使用しているがコミュニティにより良い代替があるケースの扱い
次のステップとして、コアコントリビューターのグループがより多くのテレメトリとデータを収集し、コミュニティの代替案を評価し、提案する変更を詳述した RFC をまとめる予定です。
Nitro Modules - Unblocking View Components by exposing props as jsi::Values
最近、Marc Rousavy が Nitro Modules を導入しました。Nitro Modules は実験的な C++ と Swift のインタロップを利用した代替的なネイティブモジュール作成手法で、特定のシナリオでパフォーマンス向上が期待される複数の改善点を取り入れています。
しかし、このセッションでは Nitro Modules と既存の TurboModules の間のトレードオフについて議論しました。Nitro Modules は一部のケースでパフォーマンス上の利点を提供しますが、実験的なインタロップ機能の利用は TurboModules にはない複雑さや互換性の問題を導入する可能性があります。
議論は主にこれらのトレードオフに集中し、Nitro Modules の改善点の一部を React Native Core に upstream する可能性や、それにより誰もがより高速なモジュールの利点を享受できる道筋について検討しました。
Out-of-Tree Platforms & CocoaPods
Out-of-Tree Platforms は React Native の真価を発揮する領域であり、モバイルやデスクトップ、さらには VR/XR デバイス上でも一つの JS コードベースを共有できます。しかし、こうしたプラットフォームを作るプロセスは現状それほど容易ではなく、作成・開発・保守の手順についての明確なガイドラインが存在しません。また、React Native Core は現状 Android と iOS にある程度結び付いています。将来的には全てのプラットフォームが平等に扱われ、同一の C++/JS コアを同じ API で統合できるようにすることを目指せます。
セッションでは各プラットフォームのメンテナが集まり、問題点、苦労している点、そして新しい Out-of-Tree プラットフォームを作成・維持するプロセスを統一するための解決策について議論しました。
また CocoaPods に関する将来計画についても話しました。最近 CocoaPods チームはメンテナンスモードに移行し、大きな改善や新機能は出ない方針を示しました。利用可能な代替手段はいくつかあり、それぞれの利点・欠点や移行のイメージについて議論が行われました。
React Native on Desktop
Microsoft の Steven と Saad（react-native-windows と react-native-macos のメンテナ）がデスクトッププラットフォームに関するフィードバック収集のためのセッションを主催しました。議論されたトピックには以下が含まれます：
- Visual Studio における専用ワークフローの整備や、Nx にデスクトップを露出するなど、デスクトップ向け React Native の採用促進策
- Expo をどのようにサポートするか（採用の継続的な障壁となっている点）
コミュニティモジュールの提供状況には macOS と Windows の間で大きな差があり、その主な要因は iOS コードが macOS と高い互換性を持つ一方で、RNW（react-native-windows）はそれぞれ専用の実装を必要とする点です。
Windows 向けの New Architecture 作業中、チームは C++ モジュールがプラットフォーム間でさらに多くのコード共有を可能にすると見ており、これはデスクトップターゲットの負担軽減につながると期待しています。
コミュニティ側では Software Mansion が React Native Screens、Gesture Handler、Reanimated といった人気モジュールにデスクトップサポートを追加する作業を進めています。
結び
数日間にわたり数時間を共に過ごすことで、非常に多くの知見共有とアイデアの交差が生まれたことに改めて感銘を受けました。このサミットでは、React Native エコシステムを改善し再構築するための取り組みの種をまくことができました。
React Native の開発に参加したい方は、ぜひオープンイニシアチブに参加し、私たちのウェブサイトにある contribution guide をお読みください。今後、皆さんに直接お会いできることを楽しみにしています！」}ៅureau