ClaudeReact NativeFeb 3, 2025, 12:00 AM

React Native Core Contributor Summit 2024 Recap

A condensed section focused on the key takeaways first.

Original Post

Quick Digest

Summary

A condensed section focused on the key takeaways first.

claudeenmodel: claude-sonnet-4-20250514

React Native Core Contributor Summit 2024: New Architecture, Web APIs, and Platform Expansion

Key Points

  • Web APIs standardization initiative to implement 200+ essential APIs
  • LeanCore 2.0 to reduce API surface and improve platform agnosticism
  • Enhanced focus on out-of-tree platforms and desktop support

Summary

The React Native Core Contributor Summit 2024 brought together core contributors and the React Native team for two days of strategic discussions about the framework's future direction. With the New Architecture now stable, the summit focused on next-generation initiatives including Web API standardization, platform expansion, and ecosystem improvements.

Key Points

  • Release Process Evolution: Discussed improving release frequency, reducing breaking changes, and enhancing communication between React Native core and third-party dependencies
  • Post-New Architecture Roadmap: Identified key focus areas including web compatibility via React Strict DOM, API stabilization, and improved support for out-of-tree platforms
  • Web APIs Standardization: Microsoft's RFC proposes implementing ~200 essential Web APIs to improve scalability and attract web developers, with strong community alignment on the initiative
  • LeanCore 2.0 Initiative: Plans to reduce React Native's API surface by removing outdated components, consolidating duplicates, and making APIs truly platform-agnostic
  • Nitro Modules Discussion: Evaluated performance benefits and trade-offs of Marc Rousavy's alternative to TurboModules, exploring potential upstream integration
  • Platform Expansion: Addressed challenges in out-of-tree platform development, CocoaPods maintenance mode transition, and desktop platform adoption barriers
  • Ecosystem Improvements: Focus on better documentation, tree-shaking for Metro web, and standardized guidelines for platform creation and maintenance

Full Translation

Translations

A translation section that keeps the flow of the original article.

claudejamodel: claude-sonnet-4-20250514

React Native Core Contributor Summit 2024 振り返り

毎年、React Nativeコミュニティのコアコントリビューターは、React Nativeチームと一緒に集まり、このプロジェクトの方向性を協力して形作っています。昨年も例外ではありませんでした—小さな例外を除いて。通常、私たちはReact Universe Conf(旧React Native EU)の前日にWrocławのCallstack HQで会合を持ちます。2024年は、過去の経験から学び、より多くの自由な時間を一緒に過ごせるよう、2日間連続でSummitを開催しました。この年次恒例の伝統は、コントリビューターが洞察を共有し、懸念を表明し、コアチームが計画を共有し、パートナー企業、個人のライブラリ作者、友人を含むReact Nativeエコシステムの主要コントリビューターからフィードバックを収集する貴重な機会となっています。

Summitを以下のトピックをカバーする2つのトラックに分けました:

  • Releases
  • New Architectureの後に何が来るか?
  • Native ModulesのためのWeb APIs仕様
  • LeanCore 2.0
  • Nitro Modules - propsをjsi::Valuesとして公開することによるView Componentsのブロック解除
  • Out Of Tree Platforms & CocoaPods
  • React Native on Desktop

このブログ投稿では、この集まりの結果をちらっとお見せしたいと思います。

Releases

React Nativeのリリースプロセスについて広範囲にわたる議論を行いました。コアチームは、Meta外部のコントリビューターがリリースに関与することの価値を評価し、特にReact Native visionOSのようなOut-of-Treeプラットフォーム、ライブラリメンテナー(Reanimated)、フレームワーク(Expo)にとって有益なnightlyリリースの重要性を強調しています。

リリースの頻度について議論し、修正をより早く出荷するためにより頻繁なリリースを求める人もいれば、サードパーティライブラリやアップグレード作業への影響を懸念する人もいました。また、意図しない破壊的変更を減らし、React Nativeとサードパーティ依存関係間の互換性についてのコミュニケーションを改善する方法についてもブレインストーミングしました。

このセッションは、React Nativeのリリース管理がいかに複雑で、エコシステムのすべての異なる部分を考慮する必要があることを考えると、このトピックがいかに繊細であるかを示しました。

New Architectureの後に何が来るか?

New Architectureが安定版として出荷された今、次に何に焦点を当てるべきかを議論しました。次の大きなことは何でしょうか?トピックは以下を中心に展開されました:

  • Web互換性 – React Strict DOMプロジェクトの方向性についての議論で結論づけられ、Xplatチームが適切なクロスプラットフォーム機能をReact Nativeのコアに実装する間、一時的なpolyfillとして扱われるべきです。
  • コア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チームからの作業をマージすることにオープンです。

Native ModulesのためのWeb APIs

このセッションは、Web APIのサブセットをReact Nativeに持ち込むというアイデアを中心としたMicrosoftのRFCに専念しました。これは、馴染みのあるAPIを活用することで、React Nativeのスケーラビリティを向上させ、より多くのWeb開発者を引き付けることを目的としています。明示的なReact Nativeサポートを持たない既存のオープンソースWebライブラリの豊富な資産へのアクセスを開放します。

Web API仕様の標準化は有益であるだけでなく、React Nativeの成長にとって不可欠であり、私たちのMany Platformsビジョンとreact-strict-domプロジェクトとよく一致しています。Webはその仕様を通じて統一されたインターフェースを提供しますが、React Nativeコミュニティモジュールには現在これが欠けています。

Microsoftは、サポートするプラットフォーム(iOS、Android、Windows、macOS)で最初に実装できる約200の必須Web APIを特定しました。ライブラリ開発者には、可能な限りWeb仕様にAPIを合わせることを推奨します。この標準化により、プラットフォーム間でのコードの移植性と開発者体験が向上するからです。

提案はReact Nativeの将来にとって有益に見えますが、次のステップについてはまだブレインストーミング中です。私たちが気づいた懸念の一つは、APIのガバナンスと、プラットフォーム実装とは別のリポジトリに存在する必要があるかどうかです。もう一つは、特定のプラットフォームがW3Cで指定されていない動作を許可する場合に、公式仕様から逸脱することについてです。不要なモジュールのバンドルを避ける方法、例えばBabelプラグインを使用する方法を見つける必要があります。このような取り組みの範囲がかなり大きいことは言うまでもありません。

セッションの結論は2つの重要なポイントを強化しました:第一に、可能な限りWeb互換仕様を採用することについて、React Nativeコミュニティ全体で強い一致があります。第二に、これらのWeb API実装を異なるプラットフォームで別々に維持する方法について、明確な技術戦略を確立する必要があります。

MicrosoftはCallstackと協力して、元のRFCを洗練し、コミュニティイニシアチブとしてより少数のAPIの概念実証実装を作成できます。この段階的なアプローチは、範囲を拡大する前に設計と開発者体験を検証するのに役立ちます。

LeanCore 2.0

2019年、React NativeチームはLean Coreイニシアチブを開始しました。目標は、React Nativeコアの表面積に取り組み、古くてレガシーなAPIとコンポーネントを削減することでした。それ以来、React NativeのコンポーネントとAPI表面は、別のクリーンアップラウンドが長い間必要でした。

今日、積極的にメンテナンスされておらず、より良いコミュニティ代替品があるコンポーネントが多数あります。さらに、メンテナンス性のために最終的に統合されるべき重複したコンポーネントもあります。

API側では、多くのJSレイヤーAPIが真にプラットフォーム非依存ではなく、ネイティブiOSとAndroid実装に結び付けられています。例えば、Pressableでは、android_disableSoundandroid_rippleのようなpropsがあります。理想的には、React Nativeコンポーネントは特定のプラットフォームに結び付けられていない最小限のAPI表面を持つべきです。

Out-of-Treeプラットフォームが成長し、エコシステムでより多く採用されるにつれて、React NativeコアのコンポーネントとAPI表面を削減し、React Nativeコアチームの負荷を軽減し、Out-of-Treeプラットフォームとライブラリメンテナーが最新の状態を保つことを大幅に容易にする道筋が必要です。

追加のボーナスとして、これにより初心者のアプリ開発者がReact Nativeを習得することが容易になります。学習すべき重複したコンポーネントや「落とし穴」が少なくなるからです。より良いコミュニティ代替品がある場合、開発者は利用可能なコミュニティ代替品を使用するよう案内され、推奨されます。

セッション中、以下について議論しました:

  • Lean Coreの高レベルな動機と関係者(開発者、ライブラリメンテナー、Meta)への利益
  • 実際の本番React Nativeアプリで使用されているコンポーネントの集約ビュー
  • コアから削除される候補の基準
  • LeanCore 2.0を実行するための明確なアクションプラン:
    • 非推奨化の高レベルプロセス
    • より良いコミュニティ代替品があるコンポーネントをMeta内部で使用している場合の処理

次のステップとして、コアコントリビューターのグループがより多くのテレメトリとデータの収集、コミュニティ代替品の評価、提案された変更を詳述するRFCの作成を検討します。

Nitro Modules - propsをjsi::Valuesとして公開することによるView Componentsのブロック解除

最近、Marc RousavyがNative Modulesを作成する代替アプローチとしてNitro Modulesを紹介しました。Nitro Modulesは実験的なC++ Swift Interopを利用し、特定のシナリオでパフォーマンス向上につながる可能性のある多くの拡張機能を組み込んでいます。

しかし、このセッション中、Nitro Modulesと既存のTurboModules間の様々なトレードオフについて議論しました。Nitro Modulesはいくつかのパフォーマンス上の利点を提供しますが、対処する必要がある制限と考慮事項もあります。例えば、実験的なinterop機能の使用は、TurboModulesには存在しない複雑さや互換性の問題を引き起こす可能性があります。

私たちの議論は、これらのトレードオフと、Nitro Modulesの改善の一部をReact Native Coreにアップストリームする可能性に焦点を当てました。これにより、開発者は皆のためのより高性能なモジュールから恩恵を受けることができるでしょう。

Out-of-Tree Platforms & CocoaPods

Out-of-Tree PlatformsはReact Nativeの完全な力を提示し、モバイルデバイス、デスクトップ、さらにはVR/XRデバイスで動作する異なるプラットフォーム間で1つのJSコードベースを共有できます。現在、そのようなプラットフォームを作成することは最も簡単なプロセスではなく、実際には物事をどのように作成、開発、メンテナンスすべきかについてのガイドラインがありません。また、React Native CoreはAndroidとiOSプラットフォームに結び付けられています。

将来的には、すべてのプラットフォームが平等に扱われ、同じAPIを通じてC++/JSコアと統合されるシナリオを目指すことができます。

このセッション中、異なるプラットフォームのメンテナーは、問題は何か、何に苦労しているか、新しいOut-of-Treeプラットフォームの作成とメンテナンスプロセスを統一するための解決策は何であるべきかについて議論しました。

このセッションのもう一つの側面は、Cocoapodsとネイティブ依存関係の管理に関連する将来の計画について議論することでした。最近、Cocoapodsチームはメンテナンスモードに移行し、新しい主要な改善や機能は出荷されないと発表しました。使用できる様々な代替品があり、このセッション中にそれらの長所と短所、移行がどのようなものになるかについて議論しました。

React Native on Desktop

react-native-windowsとreact-native-macosのメンテナーであるMicrosoftのStevenとSaadが、デスクトッププラットフォームに関連するコントリビューターからのフィードバックを聞き、収集するセッションを主催しました。

議論されたトピックには、React Native for Desktopの採用を増やす方法の探求(Visual Studioでの専用ワークフローの提供や、NxでデスクトップをNxの一部として公開するなど)、より多くの採用にとって継続的な痛点であるExpoのサポート方法が含まれました。

macOSとWindows間でコミュニティモジュールの可用性に大きな格差があります。これは主に、iOSコードがmacOSとほぼ互換性があるのに対し、RNWには特注の実装が必要であるという事実によるものです。

React Native for WindowsのNew Architectureに取り組む中で、チームはC++モジュールがプラットフォーム間でさらなるコード共有を可能にし、デスクトッププラットフォームをターゲットにする負担を軽減することに期待を寄せています。

コミュニティ側では、Software MansionがReact Native Screens、Gesture Handler、Reanimatedなどの最も人気のあるモジュールにデスクトップサポートを追加する作業を行っていることは注目に値します。

数日間、数時間一緒に過ごすことで、これほど多くの知識共有とアイデアの相互受粉が生まれたことに、私たちはまだ感銘を受けています。このサミット中、React Nativeエコシステムの改善と再形成に役立つイニシアチブの種を植えました。

React Nativeの開発に参加することに興味がある場合は、私たちのオープンイニシアチブに参加し、ウェブサイトにあるコントリビューションガイドを読んでください。将来、直接お会いできることを願っています!