React Native 的入口變了：官方現在先推薦 Framework，而不是先自己拼原生底座
我讀完 React Native 的官方 README 和最新 Getting Started 之後，最大的感受不是它還能不能用，而是新專案的入口已經改了：官方先推 Framework，尤其是 Expo，再談要不要走不依賴框架的路線。
React Native 的入口變了：官方現在先推薦 Framework，而不是先自己拼原生底座
我最近重新看 React Native，最大的感受不是它「還能不能用」，而是它的官方入口已經變了。
以前很多人談 React Native，第一個畫面常常是「React 開發者把同一套 UI 跑到 iOS 和 Android」，接著就開始討論原生模組、橋接、效能、相依套件，最後把討論帶回一個很熟悉的問題：到底要不要直接回到原生。
但我讀完官方 README 和最新的 Getting Started 之後，看到的是另一個更清楚的訊號：React Native 不是要你一開始就自己拼出一套原生底座，而是先把你帶進一個完整的 Framework 體驗。 官方甚至明白寫出，對新專案來說，最佳體驗是透過 Framework；如果沒有特殊限制，官方也更推薦像 Expo 這類 Framework 先把導航、原生整合、路由、常用能力先鋪好。
這個轉向很重要，因為它直接影響了我怎麼判斷 React Native 的定位。
我先講結論：React Native 仍然值得看，但它現在更像「以 React 為核心的跨平台產品框架」
如果把 React Native 只理解成「一套可以寫 iOS 和 Android 的 UI library」，我覺得已經太小看它了。官方 README 的描述很直接：它把 React 的宣告式 UI 帶到 iOS 和 Android，讓你使用原生 UI 控制項，同時保有對原生平台的完整存取能力。
換句話說，它不是在模仿原生，而是在用 React 的開發方式，去包裝原生平台的能力。
這也是我認為它還有價值的原因。
它真正解的問題，不只是「少寫一份前端」，而是：
- 讓熟悉 React 的團隊可以更快建立 App。
- 讓產品團隊把精力放在功能與節奏，而不是每次都從原生工程細節開始。
- 讓跨平台共用邏輯變成預設，而不是補救。
- 在需要時，仍保留進入原生層的路徑。
所以我現在看 React Native，不會再只問「能不能跨平台」，而是會問：這個團隊是不是需要一個以 React 為中心、但又能碰到原生能力的產品框架？
如果答案是肯定的，那 React Native 依然很有份量。
官方文件最值得注意的地方：新專案先選 Framework
這是我覺得最值得寫成文章的地方。
React Native 的 Getting Started 文件，開頭就把話講得很白：如果你已經懂 React，你可以用 React Native 做原生 App；同時，原生開發者也可以用它來讓不同平台的功能保持一致。
但接下來它沒有把你直接推去裸機式的原生設定，而是明說：最好的起點是 Framework。
這代表什麼？代表 React Native 社群和官方現在都更重視「把常見產品能力當成基礎設施」這件事。你不應該把第一次導入的成本花在重建一套路由、模組治理、平台設定、啟動流程，而是應該先從一個已經把這些底層事情包好的入口開始。
我認為這是非常成熟的產品思維。
因為真正吃掉團隊時間的，通常不是第一個畫面，而是：
- 導航和頁面管理怎麼設計
- 原生套件怎麼整合
- Android 與 iOS 的差異怎麼收斂
- 開發環境怎麼統一
- 新人進來要先補哪些基礎知識
React Native 官方現在的答案很明確：先用 Framework，把這些常見問題預先處理掉。
而這也把 Expo 推到了非常前面的位置。
為什麼我會把 Expo 視為 React Native 的最佳入口
官方文件在 Getting Started 裡面直接把「用 Expo 新建專案」放在最前面，而且提供的第一個命令也很明確：
npx create-expo-app@latest我喜歡這種寫法，因為它沒有假裝跨平台開發是一件零成本的事。
Expo 提供的不是單一功能，而是一整套可開始工作的框架能力，包括：
- file-based routing
- 常用原生模組的標準庫
- 與原生程式碼互動的擴充能力
- 更完整的開發體驗
這樣的設計很像在告訴團隊：先把業務跑起來，再決定要不要往更底層走。
我很認同這個順序。
因為很多專案一開始就衝去裸機架構，最後不是做不出來，而是太早把自己拖進架構討論。等到功能還沒成形，團隊就先在原生設定、套件相依、環境差異、iOS 與 Android 的差異裡消耗掉大量精力。
Expo 先把這些事情標準化，反而讓 React Native 回到它原本最強的地方：
- 用 React 的方式組 UI
- 用一致的開發習慣推進產品
- 把跨平台共用邏輯做成常態
如果你問我 React Native 現在最像什麼，我會說它越來越像一個以 React 為語言、以 Framework 為預設的產品交付環境。
但 React Native 不是萬用解：它的限制也很真實
我不想把 React Native 寫成一個萬能工具，因為那不真實。
官方 README 也很誠實地列出它的前提：
- React Native App 支援的目標版本是 iOS 15.1 以上、Android 7.0 API 24 以上。
- 你可以在 Windows、macOS 或 Linux 上開發，但如果要建置和執行 iOS，仍然受限於 macOS。
- 如果你要的是完全自由的原生掌控，官方也保留了不使用 Framework 的路線。
這些限制不是缺點，而是成本提醒。
尤其是 iOS 只能在 macOS 上建置這件事，對跨平台團隊影響很大。它表示你不是只要會 React 就結束了，你還是得面對平台限制、簽章、模擬器、原生工具鏈這些現實。
所以我現在看 React Native，不會把它理解成「省掉原生工程」，而是更準確地理解成：
它讓你把原生複雜度延後、收斂、模組化，而不是消滅它。
這個差別很重要。
如果你的產品只需要極少量頁面、對效能或平台行為有極強要求，原生也許更直接。
如果你的產品需要快速試錯、頻繁疊代、團隊又有 React 能力，那 React Native 就很適合拿來做主幹。
我會怎麼開始一個 React Native 新專案
如果是我自己，我不會一開始就把焦點放在「先把原生工程弄通」。我會先決定團隊要走哪條入口。
路線一：一般新專案，先用 Expo
這是我會優先建議的路線。
官方文件已經把它放在最前面，原因很清楚：你能更快開始做功能，而不是先忙著處理基礎設施。
最基本的起步方式是：
npx create-expo-app@latest我會接著做三件事：
- 先確認專案能正常啟動。
- 先做一個最小可驗證畫面，確認跨平台 UI 流程沒問題。
- 再逐步加入導航、資料流、登入、原生能力。
這樣的好處是，你可以很快回答一個最關鍵的問題：這個團隊的產品節奏，適不適合用 React Native + Framework 的模式往前走。
路線二：真的有特殊限制，再走不使用 Framework 的路線
官方也沒有把這條路封死。
如果你的 App 有很特殊的原生依賴，或者你就是需要自己掌控 Android Studio、Xcode 和整個原生工程，官方文件也提供了「不使用 Framework」的路線。
但我會把這條路視為有明確理由時才走的選項，而不是預設。
因為不使用 Framework，通常代表你要自己承擔更多事情：
- 原生環境設定
- 平台相依調整
- 原生模組整合
- 導航和常見產品能力的自行組裝
這些都不是不能做，而是你要清楚知道成本已經轉回團隊手上。
我的原則很簡單：
能用 Framework 快速驗證價值，就先不要把自己丟進原生細節的深水區。
React Native 真正強的地方，不是「同一份 UI」，而是「同一套思維」
我認為很多人低估了 React Native 的價值，因為他們只看到跨平台輸出，看不到思維統一。
React Native 最有用的地方，在於它讓團隊可以用相近的方式思考：
- UI 是可組合的
- 狀態是可管理的
- 頁面是可拆分的
- 平台差異是可隔離的
- 產品功能是可快速驗證的
這和純原生團隊最大不同，不在於語言，而在於交付節奏。
當你用 React Native 開發時，很多決策都會更像 Web 團隊：
- 元件如何拆
- 資料怎麼傳
- 狀態怎麼管理
- 哪些功能共用，哪些功能平台分流
這讓它很適合有 React 背景的團隊，因為團隊能把既有的開發習慣帶進 App 領域，而不用重新發明一套工作方式。
但它也不是沒有代價。
一旦你要碰到真正複雜的原生功能，你還是要懂平台。
所以我會把 React Native 看成一個讓你用 React 做 App，並在必要時回到原生能力的中間層。
這個中間層，正是它的價值所在。
誰適合先試 React Native
如果你符合下面幾種情況，我會認為 React Native 很值得先試：
1. 團隊已經有 React 經驗
這幾乎是最直接的受益族群。
你的前端團隊不用完全重學一套心智模型，就能進入 App 開發。
2. 產品需要快
如果你的產品會快速改版、快速驗證、快速上線，那跨平台共用能力會非常有吸引力。
3. 你想把前後端與 App 的節奏拉近
當 UI 與商業邏輯的拆分方式更接近，團隊通常更容易協作。
4. 你不想一開始就把成本壓在原生工程上
這是很多新創或中小團隊的真實需求。
先把產品做出來，再決定哪些地方值得下沉到原生，通常更符合資源現實。
反過來說，如果你的產品一開始就有非常高的原生特化需求、硬體整合需求，或者你所在的團隊本來就是原生優先，那 React Native 就不一定是最佳答案。
我覺得這種誠實的判斷，比盲目選型重要得多。
我怎麼總結 React Native 這個專案
如果只用一句話，我會說：
React Native 不是過時了，而是它的官方姿勢變成熟了。
它不再強迫你用某種單一方式把所有事情都自己做完，而是先提供一個更務實的起點：Framework first。
這個變化很有意思，因為它代表 React Native 的重點已經從「證明我能跨平台」轉成「讓團隊更穩定地做出產品」。
對我來說，這才是值得寫成文章的地方。
它不只是一個 GitHub repo，還是一個開發哲學的訊號：
- 先把產品做出來
- 先用標準化框架降低風險
- 真的需要時，再往原生底層走
如果你現在正在評估 App 技術選型，我會建議你重新看一次 React Native 的官方 README 和 Getting Started。
你可能會發現，它真正想解的問題，已經不只是「跨平台」，而是如何讓跨平台變成一個可持續、可交付、可擴張的產品做法。
參考資料