今天，我们很高兴发布 React Native 0.78！

此版本在 React Native 中发布了 React 19，以及其他相关功能，如对 Android Vector 可绘制对象的原生支持以及 iOS 更好的 Brownfield 集成。

亮点​

• React 19
• 朝着更小更快的版本发布
• Metro 中 JavaScript 日志的选择加入
• 添加了对 Android XML 可绘制对象的支持
• iOS 上的 ReactNativeFactory

每年，React Native 社区的核心贡献者都会与 React Native 团队聚在一起，共同塑造该项目的方向。

去年也不例外，只是略有不同。我们通常在 React Universe Conf（前身为 React Native EU）前一天在弗罗茨瓦夫 Callstack 总部会面。2024 年，从过去的经验中吸取教训，我们将峰会举办了两天，以便我们有更多非结构化的相处时间。

这个年度传统已成为贡献者分享见解和表达担忧的宝贵机会，也成为核心团队分享计划并从 React Native 生态系统的主要贡献者（包括合作伙伴公司、个人库作者和朋友）那里收集反馈的机会。

我们将峰会分为两个轨道，涵盖以下主题

• 发布
• 新架构之后是什么？
• Native Modules 的 Web API 规范
• LeanCore 2.0
• Nitro Modules - 通过将 props 公开为 jsi::Values 来解除 View 组件的阻塞
• 树外平台和 CocoaPods
• React Native on Desktop

在这篇博文中，我们想向您预先展示一下本次聚会的成果。

发布​

我们对 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 来实现桥接原生平台功能的相同目标。我们需要关于如何做好这一点的更好文档。
• Brownfield 文档 – 在峰会召开时，将 React Native 集成到原生应用中的官方文档已经过时。从那时起，团队跟进了适用于 Android 和 iOS 的最新且更简单的文档。
• Metro web 的 Tree-shaking – 核心 Metro 团队对合并 Expo 团队在该领域的工作持开放态度。

Native Modules 的 Web API​

本次会议专门讨论 Microsoft 关于将 Web API 子集引入 React Native 的 RFC。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发人员。开放访问大量现有的没有明确 React Native 支持的开源 Web 库。

Web API 规范的标准化不仅有益，而且对于 React Native 的发展至关重要，并且与我们的多平台愿景和 react-strict-dom 项目非常吻合。Web 通过其规范提供了一个统一的接口，而 React Native 社区模块目前缺少该接口。Microsoft 已确定大约 200 个基本的 Web API，可以首先为他们支持的平台实施：iOS、Android、Windows 和 macOS。

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

虽然该提案似乎对 React Native 的未来有利，但我们仍在集思广益，探讨下一步的行动。我们注意到的一个担忧是 API 的治理，以及它们是否需要与平台实现位于不同的存储库中。另一个担忧是，如果特定平台允许 W3C 未指定的行为，则可能会偏离官方规范。我们需要弄清楚如何避免捆绑不必要的模块，例如使用 Babel 插件。更不用说这项倡议的范围非常大。

会议结论强化了两个关键点：首先，React Native 社区在尽可能采用 Web 兼容规范方面达成了强烈共识。其次，我们需要为如何在不同平台上单独维护这些 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_disableSound 和 android_ripple 之类的 props。理想情况下，React Native 组件应该具有尽可能小的 API 表面，该表面不与任何特定平台相关联。

随着树外平台的增长并被生态系统更多地采用，需要有一条路径来减少 React Native 核心的组件和 API 表面，从而减轻 React Native 核心团队的负担，并使树外平台和库维护者更容易保持最新状态。

作为额外的奖励，这将使初学者应用开发者更容易上手 React Native，因为他们需要学习的重复组件和“陷阱”更少。在有更好的社区替代方案的情况下，可以引导开发者并鼓励他们使用可用的社区替代方案。

在会议期间，我们讨论了

• Lean Core 的高层动机以及对相关方（开发者、库维护者、Meta）的好处
• 在一些真实世界的生产 React Native 应用中使用的组件的聚合视图
• 从核心中删除的候选组件的标准
• 执行 Lean Core 2.0 的明确行动计划，包括
  • 弃用的高级流程
  • 处理 Meta 内部正在使用具有更好社区替代方案的组件的情况，

作为下一步，核心贡献者小组将研究收集更多遥测数据和数据，评估社区替代方案，并整理一份详细说明拟议更改的 RFC。

Nitro Modules - 通过将 props 公开为 jsi::Values 来解除 View 组件的阻塞​

最近，Marc Rousavy 引入了 Nitro Modules 作为创建 Native Modules 的替代方法。Nitro Modules 利用实验性的 C++ Swift Interop，并包含许多可以提高某些场景下性能的增强功能。但是，在本次会议期间，我们讨论了 Nitro Modules 和现有 TurboModules 之间涉及的各种权衡。

虽然 Nitro Modules 提供了一些性能优势，但它们也存在需要解决的局限性和注意事项。例如，使用实验性的互操作功能可能会引入 TurboModules 中不存在的复杂性或兼容性问题。我们的讨论重点关注这些权衡以及将 Nitro Modules 的一些改进向上游合并到 React Native Core 的可能性，这将使开发者能够从更高性能的模块中受益。

树外平台和 CocoaPods​

树外平台展示了 React Native 的全部功能，我们可以在移动设备、桌面设备甚至 VR/XR 设备上运行的不同平台之间共享一个 JS 代码库。目前，创建这样一个平台并非易事，实际上没有关于如何创建、开发和维护事物的指南。此外，React Native Core 在某种程度上与 Android 和 iOS 平台相关联。未来，我们的目标可能是实现这样一种场景，即所有平台都被平等对待，并通过相同的 API 与 C++/JS 核心集成。

在本次会议期间，不同平台的维护者讨论了问题是什么，他们遇到了什么困难，以及统一创建和维护新树外平台的过程的解决方案应该是什么。

本次会议的另一个方面是讨论 CocoaPods 以及与管理原生依赖项相关的未来计划。最近，CocoaPods 团队宣布他们已转向维护模式，并且不会发布新的重大改进或功能。有各种替代方案可以使用，在本次会议期间，我们讨论了它们的优缺点，以及迁移会是什么样子。

React Native on Desktop​

来自 Microsoft 的 Steven 和 Saad，react-native-windows 和 react-native-macos 的维护者，主持了一次会议，以倾听和收集与桌面平台相关的贡献者的反馈。讨论的主题包括探索如何提高 React Native for Desktop 的采用率（例如在 Visual Studio 中拥有专门的工作流程，或将桌面作为 Nx 的一部分公开），以及如何支持 Expo，这对于更多采用来说是一个持续的痛点。

macOS 和 Windows 之间社区模块的可用性存在很大差异，这主要是因为 iOS 代码大多与 macOS 兼容，而 RNW 需要定制的实现。在为 React Native for Windows 开发新架构时，该团队看到了 C++ 模块的潜力，它可以实现更多跨平台的代码共享，这有望减轻面向桌面平台的负担。值得注意的是，在社区方面，Software Mansion 正在努力为他们最受欢迎的模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面支持。

---

我们仍然对几天时间一起花费几个小时所产生的知识共享和思想交流印象深刻。在本次峰会期间，我们为有助于我们改进和重塑 React Native 生态系统的倡议播下了种子。

如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议并阅读我们网站上的 贡献指南。我们希望在未来也能与您亲自见面！

今天，我们很高兴发布 React Native 0.77！

此版本发布了多项功能：新的样式功能，例如支持 display: contents、boxSizing、mixBlendMode 和 outline 相关属性，以提供更强大的布局选项；Android 16KB 页面支持，以与较新的 Android 设备兼容。我们还在通过将其迁移到 Swift 来实现社区模板的现代化，同时继续支持和维护与喜欢 Objective-C 的开发者的兼容性。

默认启用新架构的 React Native 0.76 现已在 npm 上发布！

在 0.76 版本博客文章中，我们分享了此版本中包含的重大更改列表。在这篇文章中，我们将概述新架构以及它如何塑造 React Native 的未来。

新架构增加了对现代 React 功能的全面支持，包括 Suspense、Transitions、自动批处理 和 useLayoutEffect。新架构还包括新的 Native Module 和 Native Component 系统，使您可以编写类型安全的代码，直接访问原生接口，而无需桥接。

此版本是我们自 2018 年以来一直致力于的 React Native 从头开始重写的成果，并且我们格外小心地使新架构成为大多数应用的渐进式迁移。2021 年，我们创建了 新架构工作组，以与社区合作，确保整个 React 生态系统的平稳升级体验。

大多数应用都能够以与任何其他版本相同的努力程度采用 React Native 0.76。最流行的 React Native 库已经支持新架构。新架构还包括一个自动互操作层，以实现与面向旧架构的库的向后兼容性。

今天，我们很高兴发布 React Native 0.76！

这是 React Native 的一个重要里程碑，因为我们默认启用了新架构，并且我们正在引入 React Native DevTools。这是我们的团队 6 年辛勤工作的结晶，并得到了我们令人难以置信的开发者社区的支持。

亮点​

• 默认启用 React Native 新架构
• React Native DevTools
• 更快的 Metro 解析
• Box Shadow 和 Filter 样式 props

重大更改​

• 删除了对 react-native-community/cli 的依赖
• 由于原生库合并，Android 应用缩小了约 3.8Mb
• 更新了最低 iOS 和 Android SDK 要求

今天，我们很高兴发布 React Native 0.75！

此版本发布了多项功能，例如支持 % 值的 Yoga 3.1、针对新架构的多个稳定化修复，以及引入了建议用户使用 React Native 框架的建议。

亮点​

• Yoga 3.1 和布局改进
• 新架构稳定化
• 使用框架

重大更改​

• TypeScript 中的 Touchables 不能再用作泛型表达式中的类型
• 最后一个支持 minSdk 23 和 minIOSVersion 13.4 的版本
• Android：JSIModule 已被删除
• Android：PopUp Menu 从核心中删除
• iOS：最终确定推送通知弃用工作
• 社区 CLI：删除 ram-bundle 和 profile-hermes 命令

在 React Conf 上，我们更新了关于开始构建 React Native 应用的最佳工具的指南：一个 React Native 框架 - 一个包含构建生产就绪应用所需的所有 API 的工具箱。

使用 React Native 框架（例如 Expo）现在是创建新应用的推荐方法。

在这篇博文中，我们想详细介绍它们是什么，以及它们对于您作为开始新项目的 React Native 开发者意味着什么。

今天，我们发布 React Native 0.74！此版本添加了 Yoga 3.0、新架构下默认启用的无桥模式、批处理 onLayout 更新（新架构）以及 Yarn 3 作为新项目的默认包管理器。

我们还在删除已弃用的 API，包括删除 PropTypes 和对 PushNotificationIOS 的重大更改。在 Android 上，SDK 23 (Android 6.0) 现在是最低支持版本。

亮点​

• Yoga 3.0
• 新架构：默认启用无桥模式
• 新架构：批处理 onLayout 更新
• 新项目的 Yarn 3

重大更改​

• Android 最低 SDK 版本提升 (Android 6.0)
• PushNotificationIOS 的 API 更改（已弃用）
• 删除已弃用的 PropTypes
• 删除 Flipper React Native 插件
• 其他重大更改

今天，我们发布 React Native 0.73！此版本增加了对使用 Hermes 进行调试的改进、稳定的符号链接支持、Android 14 支持和新的实验性功能。我们还在弃用旧的调试功能，并发布新架构的下一个支柱：无桥模式！

亮点​

• 调试改进
• Metro 中稳定的符号链接支持
• Android 上的 Kotlin 模板
• Android 14 支持
• 新架构更新
• 已弃用的调试功能

重大更改​

• Babel 包重命名
• 其他重大更改
• React Native CLI 更改
• 已弃用 @types/react-native

今天，我们发布 0.72！

此版本为 Metro 添加了高度请求的功能、更好的错误处理以及其他开发者体验改进。这项工作的大部分内容都是根据您在 2022 年社区调查 中的反馈确定的优先级 - 感谢所有参与者！

亮点​

• 新的 Metro 功能
• 开发者体验改进
• 移动新架构更新

重大更改​

• 已弃用组件删除
• 包重命名