最近在看 React Native 的東西，然後發現一個...嗯，蠻有趣的現象。
就是很多人，包括一些老手，對 Expo 的印象好像還停在好幾年前。就覺得那是給新手、或是做些簡單小 App 用的。真要做複雜的、商業級的專案，好像非得用 Bare React Native 不可。
老實說，這個想法在以前完全沒錯。幾年前你要是在 Expo 專案裡想接個 Firebase，或是一些比較特別的硬體功能，大概就只有 `eject` 一條路，然後專案就...回不去了。但現在真的不一樣了，Expo 這幾年進化得有點誇張，那些舊的限制，說真的，很多都已經是過去式了。
甚至，你知道嗎，從 React Native 0.74 版開始，官方文件直接把 Expo 當作推薦的起手方式了。這點超重要的，但好像很多人還沒意識到這個轉變。
一句話答案
如果你現在要開一個新的 React Native 專案，除非有非常、非常特殊的理由，不然直接從 Expo 開始，大概率是最好的選擇。開發體驗跟部署速度真的會讓你覺得...嗯，回不去了。
那些還在流傳的迷思，我們一個個來看
就是因為這些印象，很多團隊在評估技術的時候，可能就直接跳過 Expo 了。我覺得有點可惜，所以想整理一下幾個最常見的迷思，跟現在的真實情況。
迷思一：「Expo 沒辦法處理複雜的 Native 功能」
這大概是最大，也最根深蒂固的一個誤解了。
以前的現實： 的確。需要動到硬體溝通、背景任務、或是一些有特殊 SDK 的功能，以前真的只能靠 Bare React Native。開發者得自己去跟 Xcode 和 Android Studio 奮鬥，寫一堆原生程式碼，然後再「橋接」回 JavaScript。就像原文提到的，以前有些專案要做像是 `[SpotOn]` 那種寵物圍籬，需要用到超寬頻（`[UWB]`）和進階的藍牙低功耗（`[BLE]`）功能，那時候選 Bare 是對的。還有像 `[Merryfield]` 的發票掃描，對圖片處理要求很高，也得用 Bare。但那些都是當時的「最佳解」，不是現在。
現在的現實： Expo 現在給你一整套工具，讓整合 Native 功能變得很...順暢。
- Expo Modules API： 這東西讓你可以很無痛地整合原生模組，不管是藍牙、背景處理、還是讀取手機裡的各種感應器，都不再是 Bare 的專利了。
- Custom Development Clients： 這大概是最重要的更新之一。它讓你可以自己包一個「客製化版的 Expo Go」，把你需要的原生程式碼包進去，但又可以繼續享受 Expo 快速開發的流程。你不需要 `eject`，等於是給你開了一個可控的「逃生門」，彈性超大。
- Config Plugins： 有時候你只是想改一下原生的設定檔，比如 `Info.plist` 或 `AndroidManifest.xml`，以前可能就要 `eject`。現在用這個 Config Plugins，直接在 JavaScript 裡寫設定就好，Expo 會在 build 的時候幫你處理好。
所以，說真的，現在就算專案有複雜的 Native 需求，我們也很有信心直接用 Expo 開局。
迷思二：「Expo 會犧牲 App 的效能」
這個也蠻常聽到的。大家會擔心 Expo 多了一層抽象，會不會讓 App 跑起來卡卡的，尤其是在做一些動畫或大量運算的時候。
以前的擔心： 合理。在舊的架構下，JS 和 Native 之間的溝通確實是一個潛在的效能瓶頸，大家會覺得要榨出極限效能，就必須直接寫 Native Code 優化。
現在的現實： React Native 自己都已經改朝換代了。新的架構（就是大家常聽到的 Fabric 和 TurboModules）已經是現在的主流，而 Expo 是完全支援、而且是第一時間就支援的。所以你用 Expo 開發，天生就享受了新架構帶來的好處。加上 Expo 內建的那些 API，像是相機、地圖之類的，都已經被官方優化過了，自己亂寫反而還比較容易踩到效能的雷。
國外那些大家聽過的大公司，像是 `[Brex]`（企業信用卡服務）或是 `[Flexport]`（貨運物流平台），他們的 App 都是用 Expo 做的，而且用起來超級順。這點我覺得比說再多理論都有說服力。
迷思三：「用 Expo 就等於被綁死，沒辦法客製化」
這個迷思比較偏向 UI/UX 跟 build process 的層面。
以前的印象： 感覺用了 Expo，就只能用它提供的那些元件跟設定，很難做出真正有品牌特色、獨一無二的 App。
現在的現實： 這點其實從以前到現在都是個誤解。UI 這塊，Expo 從來就沒有限制你。你要用什麼樣的 UI library、要做多複雜的動畫，完全是你的自由。它跟 Bare React Native 在畫面呈現上是 100% 自由的。
然後在 Build 流程的客製化上，就像前面提到的 `Config Plugins`，已經給你很大的空間去調整原生設定。除非你的需求是那種「非標準」的專案結構或是有很奇特的打包腳本，不然 Expo 提供的彈性，老實說，99% 的專案都夠用了。
等等，那到底什麼時候才需要用 Bare React Native？
講了這麼多 Expo 的好話，好像 Bare React Native 已經可以被丟進歷史的垃圾桶了。嗯...也沒那麼絕對啦。
在某些特定情況下，Bare 還是有它的價值的。我自己是覺得，大概就這兩種情況吧：
| 情境 | 為什麼可能還是選 Bare React Native |
|---|---|
| 維護現有的老專案 | 這很直觀。如果你的團隊已經有一個用 Bare 寫的、跑了很久的專案，那繼續用 Bare 維護當然最有效率。沒必要為轉而轉，除非你剛好要做大型重構。 |
| 極度非標準的專案結構或 Build 需求 | 這比較少見。比如說，你的專案需要一個非常客製化的目錄結構，或是你的打包流程需要整合一些很特別的內部工具...那種情況下，Bare 提供的完全控制權可能還是比較適合。基本上就是，當你需要打破所有規則的時候。 |
但說真的，對一個全新的專案來說，這些情況發生的機率很低。從 Expo 開始，如果真的、真的遇到了那個 1% 的極端情況，你永遠都還有 `eject` 這個最後的選項。但一開始就選擇 Bare，等於是放棄了 `EAS` 這些能讓你事半功倍的服務，我覺得有點不划算。
開發體驗的巨大轉變：EAS 才是本體
前面聊的都比較偏「能不能做到」，但我覺得 Expo 帶來的最大改變，其實是「開發體驗」。
這就要提到 Expo Application Services (EAS)。這是一整套的雲端服務，基本上把 App 開發後期最煩人的事情都包了。
- EAS Build： 你再也不需要在自己的電腦上裝 Xcode 或 Android Studio 了。程式碼推上去，雲端會幫你把 `ipa` 跟 `apk` 檔 build 好。這對 Windows 開發者想 build iOS app 來說，根本是救贖。
- EAS Submit： Build 好的檔案，可以直接透過指令送到 App Store Connect 跟 Google Play Console，連上傳都不用自己手動來。
- EAS Update： 這就是大家說的 OTA (Over-the-Air) update。一些 JS 層面的改動或 bug fix，可以直接推送到用戶手機上，不用重新上架審核。這在搶修線上問題的時候，真的，救命用的。
以前這些事情，在 Bare 專案裡都要自己想辦法串，或是用第三方服務。現在 Expo 把它變成一個非常流暢的官方體驗。光是這點，就能省下團隊大量的時間和精力。
不只國外，我最近看台灣像 `iThome 鐵人賽` 這些技術社群，分享用 Expo 處理開發、打包、上架的文章也越來越多，感覺大家慢慢都意識到，它真的不再是以前那個只能做小東西的玩具了。
所以，結論是...？
我自己是覺得，Expo 的演進有點像是一個...嗯...一個典範轉移吧。
以前我們在「開發速度」和「功能完整性」之間，好像必須做個取捨。選 Expo 就是要快，但可能會犧牲彈性；選 Bare 就是要功能，但得接受比較繁瑣的開發流程。
但現在，這個選擇題已經不存在了。你可以同時擁有 Expo 帶來的開發速度和 `EAS` 的便利，又不用擔心被 Native 功能卡死。
對我來說，現在開新專案，思考的順序已經反過來了。不再是「這個專案能不能用 Expo？」，而是「有沒有什麼理由，讓我非得放棄 Expo 不可？」。大部分時候，答案都是否定的。
聊了這麼多，蠻好奇大家的想法。你之前對 Expo 的印象也是停留在「玩具」階段嗎？或是有用 Expo 做過什麼讓你印象深刻的複雜專案？在下面留言分享一下吧！
