客製化 APP 開發框架選型完整指南：Flutter、React Native、原生、No-Code 老闆視角 4 維度決策與報價區間

你確定你要做的是 APP，而不是 PWA？

過去一年，我們在報價現場碰過 30 多位老闆，第一句話都是「我要做一個 APP」。等問到第三題——你的功能要不要離線、要不要推播、要不要刷臉登入——有八成的人開始猶豫。再追一句「你的使用者每週會打開幾次？」現場通常就安靜了。問題不在 APP 本身，而在於選錯框架的代價，真正爆發的時機是在第 18 個月那次系統升級的早上，工程師打開信箱告訴你：「老闆，這個版本不能再加功能，要重寫。」

2026 年 Flutter 的跨平台市佔達到 46%，React Native 是 35%，兩者合計超過 80%，原生開發在新案中已退到 14% 以下。這份數字來自 tech-insider 對 2026 跨平台市佔的整理，但市佔不是你該選哪個的理由。你該關心的，是這四種路徑——Flutter、React Native、原生、No-Code——在你公司未來 3 年的維運成本、人才供給、上架風險裡，誰能撐得住。

這篇文章真正的受眾，是給「付錢的人」看的決策框架，並非給工程師看的技術比較。我們會用 4 個維度——團隊現況、平台需求、效能門檻、上線速度——把四個選項放在同一張桌子上，告訴你哪一條路通往 80 萬，哪一條路通往 800 萬，又是哪一條路第 2 年會逼你打掉重練。讀完，你至少能在會議上聽懂 PM 跟工程師為什麼吵架。

為什麼客製化 APP 框架選錯，3 年後一定回頭重寫

框架選錯的痛點，不是寫程式階段感受得到的。寫的時候大家都能跑、都能上架，畫面看起來也漂亮。痛點是在「擴充」跟「維運」這兩個時間軸後段才會浮現。第一個常見場景：原本用 No-Code 起家的 MVP，使用者突破 5,000 人後，後端反應慢到沒辦法看，老闆才發現平台不能匯出原始碼，整套要在新平台從頭刻一遍。

第二個場景：兩年前用 React Native 0.68 寫的 App，現在要升級到新版才能用 iOS 18 的新權限模型，結果整個 native module 全部要改寫。第三個場景：當初堅持原生雙平台開發，現在每加一個新功能要 iOS 工程師跟 Android 工程師各做一次，估時兩倍、bug 兩套、回歸測試兩套，老闆的薪資成本根本止不住血。

這三種劇本聽起來很像是工程師的問題，其實是老闆的「策略性錯誤」。在報價單還沒簽下去之前，框架選型就決定了你未來 3 年的維運費基準線。關於整體報價的差異，我們在 APP 報價 8 萬 vs 80 萬功能差別 那篇拆得很細，可以搭配本篇看。

Flutter、React Native、原生、No-Code 四個選項一句話對位

先把這四條路放在一句話內講清楚，你才有辦法跟團隊溝通。

這四個選項沒有絕對誰好誰壞，差別是你的公司「能不能接住它的維運邏輯」。Flutter 漂亮但 Dart 工程師難找；React Native 主流但跨版本升級會卡；原生最穩但兩倍人力；No-Code 最快但長期受平台綁。

4 個維度決策框架：團隊、平台、效能、上線速度

先說一個前提：我們不會給你一張「萬用排行榜」，因為決策真正在意的是「哪個方案最符合你公司目前接得住的能力」，而非單看哪個分數最高。

維度 1：團隊現況

你公司現在有沒有前端工程師？有幾個？他們熟 React 還是 Vue？這直接決定 React Native 的學習曲線。如果你公司是傳產要外包，那這題答案是「沒有」，這時候 Flutter 跟 No-Code 反而更實在，因為它們的外包池在台灣相對好找。Dart 雖然小眾，但 Flutter 社群在 2026 年已經足夠成熟。

維度 2：平台需求

你要上 iOS 還是 Android？兩個都要？要不要 Web 也共用？要不要桌機？這四題會直接刷掉一些選項。如果你只要 iOS，原生 Swift 是最快的；如果你要 iOS + Android + Web 全部共用一份程式碼，Flutter 是現階段最完整的。React Native 雖然有 Expo Router 支援 Web，但 Web 端體驗仍不如 Flutter Web 順。

維度 3：效能門檻

如果你的 App 是內容瀏覽、表單填寫、訊息推播這類，三種框架感受不出差別。但如果你要做 60FPS 的遊戲畫面、即時影像處理、AR 濾鏡、需要呼叫 Core ML 或 NNAPI 的 AI 推論——這時候原生跟 Flutter 才會拉開差距。React Native 在 2024 後的新架構靠 JSI 跟 Fabric 大幅追上效能，根據 DEV Community 的 New Architecture 報告，冷啟動快 43%、記憶體少 26%，但仍非原生等級。

維度 4：上線速度

如果你 3 個月內必須有可用 MVP，No-Code（FlutterFlow / Bubble）是唯一現實答案。Flutter / React Native 用熟練團隊大約 4-6 個月。原生雙平台同步開發通常要 6-9 個月。沒考慮上線速度只考慮「最好的技術」，是創業者最常犯的浪漫病。

老闆視角的真實費用對比：8 萬到 800 萬的 4 種路徑

我們把 2026 年台灣外包市場上看到的真實報價，整理成這張表。注意：費用會因為功能、團隊在台灣 / 越南 / 印度、是否含維運合約而差很多，這裡用「中等複雜度商業 App、上架 iOS + Android、含後台 + 基本推播」為基準。

Flutter 派的論點與適用情境

Flutter 的核心優勢是「畫面一致」。它不呼叫系統原生元件，而是用自己的 Skia / Impeller 引擎重畫每一個畫素，所以同一份程式在 iOS 跟 Android 上看起來幾乎沒差別。這對品牌設計師來說是天堂——你想要的圓角、陰影、動畫，兩個平台保證一樣。

但這個優勢也有副作用。第一，App 體積會比 React Native 大一些，因為帶著渲染引擎。第二，原生平台特有的細節（例如 iOS 26 新的「即時動態」整合）需要等 Flutter 套件補上，通常落後 3-6 個月。第三，Dart 語言在台灣就是比 JavaScript 小眾，急著找人會找不到。

Flutter 最適合的 3 種情境

第一，品牌很在意 UI 統一的消費型 App（電商、訂閱、會員），特別是設計團隊投入很深。第二，預計同時需要 Web 跟 桌機版的工具型 App，Flutter Web 跟 Desktop 在 2025 年後已可生產用。第三，內部企業工具，因為對外裝機量小，效能不挑剔，跨平台維運省人。

React Native 派的論點與適用情境

React Native 在 2024 年 0.76 版預設啟用新架構（New Architecture）後，整個生態有一波重生。JSI 取代舊有的 Bridge，原生模組呼叫快 30 倍；Fabric 渲染器把動畫從 30-45 FPS 拉到 55-60 FPS。對既有 React Native 老案來說，遷移是大工程，但對新案來說，這個架構讓 React Native 在效能上不再被 Flutter 海放。

它最大的甜蜜點是「公司本來就有 React / Next.js 團隊」。同一批工程師可以橫跨 Web 跟 App，組件可以高度共用，TypeScript 也順著用。Meta、Shopify、Discord、Bloomberg 都還在大量用，社群熱度沒衰退。

它的真正問題不在效能，而在「升級稅」。React Native 過去歷史上幾乎每個大版本都會破壞性更新，第三方 native module 經常跟不上，升級一次少則 2 週多則 2 個月。這對外包客戶來說，等於每隔 1-2 年要付一筆額外帳單。React Native 官方架構頁 有列出 2026 年的支援策略，外包合約簽訂前建議要把升級條款寫進去。

React Native 最適合的 3 種情境

第一，已有 React 前端團隊的科技公司或新創，內部消化最順。第二，內容導向、表單導向、API 串接重的商業 App，這類型 React Native 表現最穩。第三，需要快速 A/B 測試 UI 的成長型產品，Hot Reload 跟 OTA 更新（CodePush / Expo Updates）對快速迭代友善。

原生開發什麼時候才真的必要

先說一句很多工程師不想聽的話：90% 的商業 App 不需要原生。原生的價值在那 10% 的特殊情境。在那 10% 之外硬上原生，就是浪費老闆的錢。

哪 10% 真的需要？第一，金融跟醫療這類受嚴格法規約束的領域，部分審計合規會要求最小化第三方依賴。第二，需要深度整合裝置硬體：相機 RAW 處理、LiDAR、AR Kit / AR Core 的進階特效、即時影像 AI 推論。第三，遊戲跟需要 120FPS 的高互動 App，Unity 跟原生 Metal / Vulkan 才能保證體驗。

第四個容易被忽略的情境：你公司就是平台型公司，平台月活躍用戶超過 100 萬，那原生的長期穩定性、Crash 率、可控性遠勝跨平台。對中小企業老闆來說，你大概率不會是這 10%。

No-Code / Low-Code 能撐多遠：FlutterFlow、Bubble、Glide 實戰邊界

No-Code 在 2026 年已經成為嚴肅的開發路徑，早已超越玩具的層次——但仍有清楚的天花板。FlutterFlow 底層產的就是 Flutter 程式碼，可以匯出原始碼接著用真工程師接手，這是它跟 Bubble 最大的差別。Bubble 是純平台綁定，做出來的東西無法匯出。

根據 DEV Community 對 No-Code 邊界的整理，FlutterFlow 在複雜狀態管理跟即時功能上會碰到瓶頸；Bubble 在使用者突破數千後通常需要架構重整。Glide 則更輕，本質是「給試算表加上 App 殼」，適合內部工具但不適合對外公開產品。

一句話總結 No-Code 的策略價值：你可以用它來「試錯」，但不要用它來「長大」。MVP 階段省下的開發費，在你真的需要客製化的那天會以「重新做一次」的代價回到你身上。

找外包時要問的 7 個問題（含維運合約）

框架選定後，下一個風險是「外包合約怎麼簽」。我們在 找外包做 APP 9 大踩雷 跟 軟體維運合約怎麼簽 兩篇講得很細，這裡只挑跟「框架選型」直接相關的 7 個關鍵題。

第 1 題：原始碼歸屬與版本控管

結案後原始碼是你的還是廠商的？放在誰的 Git 帳號？這題不問清楚，你的 App 不算你的。No-Code 平台這題尤其要追到底，Bubble 等平台是「沒辦法給」，FlutterFlow 至少能匯出。

第 2 題：第三方套件清單

跨平台框架的 App 通常會用 30-100 個第三方套件。其中哪些是付費的？哪些是開源但已停止維護？這份清單要在合約附件列出來，未來升級才知道哪幾個會卡。

第 3 題：升級條款

如果 1 年後 iOS 28 出來、Android 18 出來、React Native 出大版本，你要付多少升級費？是包進維運合約還是另外計費？這個條款空白等於「未來無上限風險」。

第 4 題：上架責任分配

Apple App Store 審核被拒怎麼辦？是廠商免費調整，還是要按次計費？2024-2026 年蘋果對「實質網頁包殼」的 App 審核越來越嚴，沒寫清楚審核責任，第一次被拒就會吵架。

第 5 題：交付件清單

除了 App 程式碼，後台原始碼、API 文件、資料庫 schema、CI/CD 設定、簽章金鑰、Apple / Google 開發者帳號權限——這些每一項都要列在交付件，缺一項你都換不掉這家廠商。

第 6 題：人員指派與離職風險

負責你案子的工程師有幾個？合約期間如果關鍵工程師離職，廠商有沒有承諾繼任者？這條尤其在小型工作室合約裡常被忽略。

第 7 題：終止條款與帳號交接

如果未來想換廠商，30 天內可不可以拿到全部交付件？Apple Developer Account 怎麼轉？這條沒寫，分手會變勒索。

一張決策樹：你的 APP 該選哪個框架

看完上面的維度跟費用，把這張決策樹貼在跟 PM、工程師開會的白板上，能省下你 80% 來回討論的時間。

真實踩坑：3 個 APP 框架選型翻車案例

案例 1：Bubble 起家的訂閱平台，使用者破 5,000 後卡死

一家本土訂閱制美容服務商，初期用 Bubble 做了會員 App 跟訂閱後台，6 個月內上線、月費才幾百美元。會員突破 5,000 後，後台查詢開始延遲到 3-5 秒，行銷活動推播當天直接服務不可用。最後不得不在 Bubble 上掛了個保命方案，再花 180 萬整套用 React Native + Node.js 重寫，原本省下來的開發費全部還回去，外加 4 個月品牌空窗期。

案例 2：原生雙平台堅持派，3 年燒掉 1,400 萬

一家做生活風格內容的新創，創辦人是工程背景出身，堅持「品質要對得起品牌」，從一開始就上 iOS + Android 原生雙團隊。三年下來，每個新功能都要做兩次、QA 兩次、上架兩次，總燒了 1,400 萬。問題是這個 App 99% 的功能就是內容瀏覽 + 留言 + 推播，完全是 Flutter 或 React Native 的甜蜜點。後來公司現金見底，反而被 No-Code 起家、後來轉 Flutter 的競品超車。

案例 3：React Native 0.68 老案，升級費比重寫貴

一家中型電商 2022 年用 React Native 0.68 做的 App，2025 年要上 iOS 18 的新權限模型，發現用的 native module 一半停止維護、一半要付費升級。原廠商估升級費 90 萬，自己找新廠商評估「重寫到新架構」是 120 萬。最後選擇重寫，因為升級完還是會卡舊架構，明年再痛一次。

這三個案例的共通點：沒有人在第一天「選錯框架」的當下感受到痛，痛都在 18 個月後。所以決策階段的這個選擇——對你來說 1 小時討論可能不夠，但對你公司 3 年的損益表來說，可能值 100 萬。Vibe Coding（AI 拼程式）做出來的 App 可不可以直接上線？我們在 Vibe Coding App 能不能上線 有針對 2026 年的工程師視角誠實檢驗，可以一起看。

選定之後：你要準備的 3 個內部動作

框架選定其實是真正的開始，並非終點。在發外包之前，老闆要做的事情有三件：

第一，寫一份「3 年路線圖」，把你預期的功能演進排出來——不需要精準，但要讓廠商知道你不是只做 MVP 就停。沒有路線圖，廠商會用最便宜的方式幫你蓋一個一次性 App。

第二，跟內部人員確認誰是這個 App 的「產品負責人」。真正關鍵的角色，是業務 + 行銷 + 老闆共同認定的那一個人，而非工程師。沒有產品負責人，需求一變再變，框架選得再對都救不了。詳細的外包流程可以參考 中小企業外包流程指南。

第三，預留 15-20% 的緩衝預算給「上線後 3 個月」。所有的 App 上線第一個月都會出小狀況，這筆錢不留，你會被廠商按 hourly 計費吃到飽。如果你想找一家不只接案、還會把長期維運跟你站在一起的團隊，恆遠數位行銷的 客製化開發服務 跟 AI 顧問 可以一起評估，幫你把「框架選型 + AI 模組 + 維運」放在一個合約內談清楚。語言選型的細節，也可以參考 程式語言選型完整指南。

常見問題

最後總結一句：客製化 APP 的框架選型，本質上是商業題，而非技術題。你的選擇真正決定的，是未來 3 年你的損益表上多了一條 100 萬還是少了一條 500 萬，程式長什麼樣反而是其次。建議你把這篇收藏起來，下次跟工程師、PM 或外包廠商開會前，重看一次第 3 段跟第 4 段，會省下你很多無謂的爭論。

如果你已經選定 React Native + Expo 路線

上面講的是框架選型的『商業視角』。如果你已經選定 React Native + Expo 這條路，工程團隊接下來會撞到 3 道關卡——入門期、開發期、上架期。我們為這三道關卡各寫了一篇實作教學，按開發 lifecycle 順序看下來會比較有完整圖像：

1. 入門期：Expo Go 撞牆了怎麼辦？4 個訊號告訴你該轉 Development Build（什麼時候從 Expo Go 升級到 Dev Build、完整切換 SOP）

2. 開發期：Expo SDK 56 + New Architecture 升級實戰（Fabric / TurboModules / Hermes V1 七步無痛遷移）

3. 上架期：Expo EAS Build + EAS Update 上架實戰（git push 到 TestFlight 自動化 + OTA 灰度發布 SOP）