今天我們很高興發佈 React Native 0.78！

此版本在 React Native 中搭載 React 19，以及其他相關功能，例如 Android 向量繪圖的原生支援，以及 iOS 的更佳棕地整合。

重點​

• React 19
• 朝向更小、更快的版本
• 選擇加入 Metro 中的 JavaScript 記錄
• 新增 Android XML 繪圖支援
• iOS 上的 ReactNativeFactory

每年，React Native 社群的核心貢獻者都會與 React Native 團隊齊聚一堂，共同塑造此專案的方向。

去年也不例外，只有一個小小的例外。我們通常在 React Universe Conf (前身為 React Native EU) 前一天，在弗羅茨瓦夫 Callstack 總部會面。在 2024 年，我們從過去的經驗中學習，舉辦了為期兩天的峰會，以便我們有更多非結構化的時間在一起。

這項年度傳統已成為貢獻者分享見解和表達疑慮的寶貴機會，也讓核心團隊能夠分享他們的計畫，並從 React Native 生態系統的主要貢獻者 (包括合作夥伴公司、個別函式庫作者和朋友) 收集回饋意見。

我們將峰會分為兩個軌道，涵蓋以下主題

• 版本
• 全新架構之後的下一步是什麼？
• 原生模組的 Web API 規格
• LeanCore 2.0
• Nitro 模組 - 透過將屬性公開為 jsi::Values 來解除封鎖檢視組件
• 樹狀結構外平台與 CocoaPods
• 桌面上的 React Native

在此部落格文章中，我們想讓您先睹為快本次聚會的成果。

版本​

我們就 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、最近的 Nitro 模組來實現橋接原生平台功能的相同目標。我們需要更好的文件說明如何做好這一點。
• 棕地文件 – 在峰會期間，將 React Native 整合到原生應用程式的官方文件相當過時。從那時起，團隊就遵循了 Android 和 iOS 的最新且更簡單的文件。
• Metro web 的 Tree-shaking – 核心 Metro 團隊願意合併 Expo 團隊在此領域的工作。

原生模組的 Web API​

本次會議專門討論 Microsoft 的 RFC，該 RFC 圍繞著將 Web API 子集引入 React Native 的想法。它旨在透過利用熟悉的 API 來增強 React Native 的可擴展性並吸引更多 Web 開發人員。開放存取大量現有的開放原始碼 Web 函式庫，這些函式庫沒有明確的 React Native 支援。

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 等屬性。理想情況下，React Native 組件應具有盡可能小的 API 表面，該表面不與任何特定平台相關聯。

隨著樹狀結構外平台的成長並被生態系統更多地採用，需要有一條路徑來減少 React Native 核心的組件和 API 表面，從而減輕 React Native 核心團隊的負擔，並使樹狀結構外平台和函式庫維護者更容易保持最新狀態。

額外的好處是，這將使初學者應用程式開發人員更容易上手 React Native，因為他們需要學習的重複組件和「陷阱」更少。在有更好的社群替代方案的情況下，可以引導開發人員並鼓勵他們使用可用的社群替代方案。

在會議期間，我們討論了

• Lean Core 的高階動機以及對相關各方 (開發人員、函式庫維護者、Meta) 的好處
• 彙整檢視某些真實世界生產 React Native 應用程式中正在使用的組件
• 從核心中移除候選組件的標準
• 執行 Lean Core 2.0 的明確行動計畫，包括
  • 棄用的高階流程
  • 處理 Meta 在內部使用具有更好社群替代方案的組件的情況，

作為下一步，核心貢獻者團隊將研究收集更多遙測和資料、評估社群替代方案，並彙總一份 RFC，詳細說明建議的變更。

Nitro 模組 - 透過將屬性公開為 jsi::Values 來解除封鎖檢視組件​

最近，Marc Rousavy 推出了 Nitro 模組，作為建立原生模組的替代方法。Nitro 模組利用實驗性的 C++ Swift Interop，並整合了一系列增強功能，可以在某些情況下提高效能。但是，在本次會議期間，我們討論了 Nitro 模組和現有 TurboModules 之間涉及的各種權衡。

雖然 Nitro 模組提供了一些效能優勢，但它們也存在需要解決的限制和考量。例如，使用實驗性互通功能可能會引入 TurboModules 中不存在的複雜性或相容性問題。我們的討論重點是這些權衡以及將 Nitro 模組的一些改進向上游化到 React Native Core 的可能性，這可以讓開發人員從更高效能的模組中受益。

樹狀結構外平台與 CocoaPods​

樹狀結構外平台展現了 React Native 的完整功能，我們可以在行動裝置、桌上型電腦甚至 VR/XR 裝置上執行的不同平台之間共用一個 JS 程式碼庫。目前建立這樣的平台並非易事，實際上沒有關於應如何建立、開發和維護的指南。此外，React Native Core 在某種程度上與 Android 和 iOS 平台相關聯。未來，我們的目標可能是所有平台都受到同等對待，並透過相同的 API 與 C++/JS 核心整合的場景。

在本次會議期間，不同平台的維護者討論了問題、他們遇到的困難以及應如何解決以統一建立和維護新樹狀結構外平台的流程。

本次會議的另一個方面是討論 CocoaPods 以及與管理原生相依性相關的未來計畫。最近，CocoaPods 團隊宣佈他們已轉為維護模式，並且不會發佈新的重大改進或功能。可以使用各種替代方案，在本次會議期間，我們討論了它們的優缺點，以及遷移的外觀。

桌面上的 React Native​

來自 Microsoft 的 Steven 和 Saad (react-native-windows 和 react-native-macos 的維護者) 主持了一個會議，以傾聽和收集貢獻者關於桌面平台的回饋。討論的主題包括探索如何提高 React Native for Desktop 的採用率 (例如在 Visual Studio 中擁有專用工作流程，或將桌面公開為 Nx 的一部分)，以及如何支援 Expo，這一直是提高採用率的持續痛點。

macOS 和 Windows 之間社群模組的可用性存在很大差異，這主要是因為 iOS 程式碼大多與 macOS 相容，而 RNW 需要客製化實作。在為 Windows 版 React Native 的全新架構工作時，團隊看到了 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。全新架構也包含新的 原生模組和 原生組件系統，可讓您編寫型別安全程式碼，並直接存取原生介面，而無需橋接器。

此版本是我們自 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 樣式屬性

重大變更​

• 移除了對 react-native-community/cli 的相依性
• 歸功於原生函式庫合併，Android 應用程式縮小約 3.8Mb
• 更新至最低 iOS 和 Android SDK 需求

今天我們很高興發佈 React Native 0.75！

此版本搭載了多項功能，例如支援 % 值的 Yoga 3.1、全新架構的多項穩定化修正，以及介紹建議使用者使用 React Native Framework。

重點​

• Yoga 3.1 和版面配置改進
• 全新架構穩定化
• 使用框架

重大變更​

• TypeScript 中的 Touchables 無法再用作 Generic 運算式中的類型
• 最後一個支援 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 功能
• 開發人員體驗改進
• 移動全新架構更新

重大變更​

• 已棄用的組件移除
• 套件重新命名