每年，React Native社区的核心贡献者都会与React Native团队齐聚一堂，共同规划这一个项目的发展方向。

  去年也不例外，只是稍有不同。我们一般会在React Universe Conf（前身为React Native EU）召开的前一天，在弗罗茨瓦夫的Callstack总部会面。2024年，汲取以往的经验，我们将峰会连续举办了两天，这样我们就有更多自由交流的时间。

  这一年度传统活动为贡献者提供了宝贵的机会，让他们可以分享见解、表达关切，同时也让核心团队得以分享计划，并从React NativeECO的关键贡献者（包括合作伙伴公司、独立库作者和朋友们）那里收集反馈。

  我们对React Native的版本发布流程进行了广泛讨论。核心团队认可Meta以外的贡献者参与版本发布的价值，并强调了夜间构建版本发布的重要性，这对像React Native visionOS这样的外部平台、库维护者（如Reanimated）和框架（如Expo）尤其有益。我们还讨论了发布频率，一些人希望更频繁地发布以更快修复问题，而另一些人则担心这会对第三方库和升级工作产生影响。

  我们还集思广益，探讨如何减少无意的破坏性变更，并加强React Native与第三方依赖之间兼容性的沟通。

  这次讨论表明，管理React Native的版本发布很复杂，鉴于需要仔细考虑生态系统的各个不同部分，这一个话题十分敏感。

  既然新架构已经稳定发布，我们讨论了接下来应关注的重点。下一个重大突破会是什么呢？讨论围绕以下几个话题展开：

  Web兼容性：在关于React Strict DOM项目方向的讨论中得出结论，该项目应被视为临时的polyfill，而Xplat团队要将合适的跨平台功能集成到React Native的核心中。

  稳定核心API：事实上，对于这对应用开发者、库作者和外部平台意味着什么，我们应该达成更多共识。例如，可能有必要从共享的C++代码库中提取iOS和Android的平台原生逻辑。部分内容在LeanCore 2.0的讨论中有所涉及。

  旧架构支持：不出所料，团队确认基于并发渲染的React 19新功能在旧架构中没办法使用。新功能主要面向新架构。由于React 19发布计划中的阻碍，目前仍不清楚在新旧架构都支持的功能之间如何划分界限。

  React Native的第三方库：如今，库作者能够正常的使用TurboModules、ExpoModules，最近还有NitroModules来实现桥接原生平台功能的相同目标。我们应该更好的文档来指导怎么样才能做好这件事。

  混合开发文档：在峰会召开时，将React Native集成到原生应用的官方文档已经相当陈旧。从那以后，团队已经更新了适用于Android和iOS的最新、更简洁的文档。

  Metro web的摇树优化：Metro核心团队愿意合并Expo团队在这一领域的工作成果。

  本次会议专门讨论了微软提出的RFC（请求评论），其核心思想是将一部分Web API引入React Native。这旨在通过利用开发者熟悉的API，提高React Native的可扩展性，并吸引更多Web开发者，同时开放访问大量现有的、没明确React Native支持的开源Web库。

  标准化Web API规范不仅有益，而且对React Native的发展至关重要，这与我们的“多平台”愿景以及react-strict-dom项目很契合。Web通过其规范提供了统一的接口，而这正是React Native社区模块目前所缺乏的。微软已经确定了大约200个基本的Web API，可以首先在他们支持的平台（iOS、Android、Windows和macOS）上实现。

  我们鼓励库开发者尽可能使其API与Web规范保持一致，因为这种标准化将提高代码的可移植性和跨平台的开发者体验。

  虽然该提案对React Native的未来似乎很有益处，但我们仍在思考接下来的步骤。我们注意到的一个问题是API的管理，以及它们要不要与平台实现分开存放在不同的代码库中。另一个问题是，如果某个特定平台允许W3C规范未规定的行为，有极大几率会出现与官方规范的分歧。我们还需要仔细考虑如何避免捆绑不必要的模块，例如通过Babel插件。更不用说，这个计划的规模相当大。

  会议得出的结论是，我们都希望将更多的Web标准集成到React Native中。微软和Callstack可以合作完善最初的RFC，并作为社区项目，为少量API提供概念验证实现。这样，在扩大范围并获得React核心团队的正式认可之前，我们大家可以逐步验证设计和开发者体验。

  会议结论强调了两个关键点：第一，React Native社区在尽可能采用与Web兼容的规范方面高度一致。第二，我们应该制定明确的技术策略，以确定如何针对不一样平台分别维护这些Web API的实现。微软和Callstack可以合作完善最初的RFC，并作为社区项目，为少量API提供概念验证实现。这种渐进式的方法将让我们在扩大范围之前验证设计和开发者体验。

  2019年，React Native团队启动了Lean Core计划。目标是处理React Native核心的表面积问题，减少过时和遗留的API及组件。从那以后，React Native的组件和API表面早就应该进行另一轮清理了。

  如今，有许多组件没有正真获得积极维护，社区中有更好的替代方案。此外，还有一些重复的组件，为便于维护，最终应该进行整合。

  在API方面，许多JS层API与原生iOS和Android实现紧密相关，而不是真正的平台无关。例如，对于Pressable组件，我们有诸如android_disableSound和android_ripple这样的属性。理想情况下，React Native组件应该具有尽可能小的、不依赖于任何特定平台的API表面。

  随着外部平台的持续不断的发展并在生态系统中得到更广泛的应用，需要找到一种方法来减少React Native核心的组件和API表面，减轻React Native核心团队的负担，同时也让外部平台和库的维护者更容易跟上更新。

  另外，这也会让初学者更容易上手React Native，因为重复的组件和需要学习的“陷阱”会更少。在社区中有更好替代方案的情况下，可以引导并鼓励开发者使用这一些方案。

  Lean Core的高层动机以及对相关各方（开发者、库维护者、Meta）的好处

  执行Lean Core 2.0的明确行动计划，包括：弃用的高级流程；处理Meta内部使用的组件在社区中有更好替代方案的情况。

  下一步，一组核心贡献者将收集更多的遥测数据，评估社区替代方案，并编写一份RFC，详细说明提议的变更。

  最近，Marc Rousavy推出了Nitro Modules，作为创建原生模块的一种替代方法。Nitro Modules利用实验性的C++ Swift互操作功能，并融入了一系列增强功能，在某些情况下能大大的提升性能。然而，在本次会议中，我们讨论了Nitro Modules与现有的TurboModules之间的各种权衡。

  虽然Nitro Modules提供了一些性能优势，但它们也有局限性和需要仔细考虑的问题。例如，使用实验性的互操作功能可能会带来TurboModules中不存在的复杂性或兼容性问题。我们的讨论聚焦于这些权衡，以及将Nitro Modules的一些改进合并到React Native核心中的可能性，这可以让开发者受益于更高效的模块。

  外部平台充分体现了React Native的强大之处，我们大家可以在运行于移动电子设备、桌面电脑甚至VR/XR设备的不同平台之间共享一个JS代码库。目前，创建这样一个平台并非易事，实际上，关于如何创建、开发和维护这一些平台并没有相关指南。而且React Native核心在某一些程度上与Android和iOS平台紧密相连。未来，我们的目标可能是平等对待所有平台，并通过相同的API与C++/JS核心集成。

  在本次会议中，不同平台的维护者讨论了存在的问题、遇到的困难，以及统一创建和维护新外部平台流程的解决方案。

  本次会议的另一个方面是讨论CocoaPods以及与管理原生依赖相关的未来计划。最近，CocoaPods团队宣布他们已进入维护模式，不会再发布重大改进或新功能。有多种替代方案可供选择，在会议中我们讨论了它们的优缺点以及迁移方案。

  微软的Steven和Saad，同时也是react-native-windows和react-native-macos的维护者，主持了一场会议，倾听并收集贡献者关于桌面平台的反馈。讨论的话题包括探索怎么样提高React Native在桌面端的应用率（例如在Visual Studio中设置专用工作流程，或者将桌面端作为Nx的一部分进行展示），以及如何支持Expo，这一直是扩大应用场景范围的一个痛点。

  macOS和Windows在社区模块的可用性方面存在很大差异，这还在于iOS代码大多与macOS兼容，而RNW需要定制实现。在为Windows开发React Native新架构的过程中，团队发现C++模块有潜力实现更多的跨平台代码共享，有望减轻针对桌面平台开发的负担。有必要注意一下的是，在社区层面，Software Mansion正在为他们最受欢迎的模块添加桌面端支持，如React Native Screens、Gesture Handler和Reanimated。

  我们仍然惊叹于，仅仅几天时间、每天几个小时的交流，就能带来如此多的知识共享和思想碰撞。在这次峰会上，我们为一些计划埋下了种子，这些计划将有利于我们改进和重塑React NativeECO。

  如果你有兴趣参与React Native的开发，请务必加入我们的开源计划，并阅读我们网站上的贡献指南。我们也希望未来能与你线下相见！

  本文回顾了2024年React Native核心贡献者峰会的讨论成果，涵盖多个重要议题。在版本发布方面，探讨了发布流程、频率，以及减少破坏性变更和加强兼容性沟通的方法。新架构后续发展聚焦于Web兼容性、核心API稳定、旧架构支持、第三方库及相关文档等问题。

  Web API for Native Modules议题中，微软提议引入部分Web API，虽有好处，但在API管理、规范一致性及模块捆绑等方面存在挑战，计划由微软和Callstack先进行小规模概念验证。LeanCore 2.0旨在清理React Native核心的过时API和组件，减轻核心团队负担，后续核心贡献者将收集数据并制定改进方案。

  桌面端React Native则聚焦于提升其在桌面平台的应用率，解决社区模块可用性差异和对Expo的支持问题。这次峰会促进了知识共享和思想交流，为React Native生态系统的改进和重塑奠定了基础 。