App開發流程與費用：從想法到上架，原生還是跨平台怎麼選

很多人找開發團隊，第一句話是「我想做一個 App，要多少錢？」其實決定一個 App 成敗和預算的，往往不是程式碼，而是前面幾個決定：解決什麼問題、第一版做多少、用什麼技術、上線後誰來管。這篇文章依照 App 開發流程，從想法一路講到上架 App Store 和 Google Play，以及上線後的維護。

重點

第一個 App 最好小而精：先用 MVP 只把一個核心問題解決好；點餐、預約這類業務 App 用跨平台開發通常就夠了，使用者只是偶爾使用的，網站或 PWA 往往更合適。隱私法規和商店審核要從設計階段就考慮進去，App 要發布在您公司自己的開發者帳號下，程式碼和資料掌握在自己手裡，並為上線後的維護預留預算。

先想清楚問題，再定 MVP 和原型

開發 App 的第一步不是列功能，而是想清楚要解決什麼問題，再據此確定 MVP，並用原型驗證。動手之前，先寫下三件事：

給誰用、解決什麼問題：「老客戶想點幾下就能再次下單」是問題；「做一個有菜單、點數和聊天功能的 App」只是功能清單。
為什麼非得是 App：使用者為什麼要下載、為什麼會再打開？官網、LINE 官方帳號或 WhatsApp 做不到的是什麼？
怎麼算成功：回購、少接電話、預約不必人工處理……選上線後真正能統計的指標。

接著確定 MVP（最小可行產品）：能把核心問題解決好、讓真實使用者用起來的最小版本。把一兩條核心路徑寫出來，例如「註冊 → 瀏覽 → 下單 → 付款 → 收到通知」，其餘功能放進「以後再做」清單。MVP 不是半成品，而是範圍小、但在範圍內做到精緻。

寫程式之前，先用 Figma 等工具把核心路徑做成可點擊的原型，請幾位目標使用者在手機上點一遍，看他們在哪裡猶豫。在原型階段改一個畫面，比寫完程式再改便宜得多。斷網、付款失敗、拒絕授權這些情況，也要在原型階段設計好。

原生、跨平台，還是網頁、PWA 就夠了？

多數業務 App 用跨平台開發就夠了；高度依賴圖形、相機或影音處理的，選原生比較穩妥；使用者只是偶爾使用的，網頁、PWA 或小程式往往就夠了。三種方式的差別如下：

原生開發：iOS 用 Swift，Android 用 Kotlin，兩個平台各寫一套。能最完整地呼叫手機功能和系統新特性，代價是要維護兩套程式碼。
跨平台開發：用 Flutter、React Native 等框架，iOS 和 Android 共用大部分程式碼，Flutter 官方文件（英文）對它的定位就是「用單一程式碼庫打造多平台應用程式」。常見的業務 App 用跨平台通常就夠了；高度依賴圖形、相機或影音處理的，原生比較穩妥。
網頁、PWA 或小程式：不用下載安裝，也不必經過應用程式商店審核。PWA（漸進式網頁應用程式）是可以加到手機主畫面的網頁應用；使用者主要在中國大陸、習慣在微信裡下單預約的，微信小程式往往更容易推廣。缺點是呼叫手機功能受限，iOS 對 PWA 的支援也不如 Android。

可以這樣判斷：使用者是經常用，還是一年只用幾次？需不需要推播通知、離線使用、藍牙或背景定位？如果這幾個問題的答案大多是否定的，先做一個開得快、適合手機瀏覽的網站或 PWA，往往更穩妥；網站用 Wix、WordPress 還是客製化，見〈Wix vs WordPress vs 客製化網站比較〉。

後端、管理後台和 API：使用者看不到的另一半

大多數業務 App 只是整個系統露在外面的那一部分，背後還需要後端、管理後台，以及與金流、物流和現有業務系統的 API 串接：

後端：伺服器和資料庫，負責帳號、訂單、內容和推播通知。代管式雲端服務能加快 MVP 上線，自建後端對資料和長期成本更能掌控。
管理後台：團隊每天管理商品、訂單、使用者和推播的網頁系統。管理後台很容易在規劃時被漏掉，要及早定義角色和權限：誰能看客戶資料、誰能操作退款。
API 與系統串接：金流、地圖、物流、簡訊，以及您已經在用的購物網站、ERP、CRM、會計軟體。每一項串接都取決於對方的 API 文件、開通審核和呼叫限制，定案之前就要確認。業務系統本身還沒建好的，可以先看〈ERP 軟體建置該客製化還是買現成 SaaS〉。

還要及早決定資料放在哪個地區的伺服器，這關係到隱私法規和存取速度。面向中國大陸使用者的專案，不少海外服務無法穩定使用，Android 推播一般還要串接各手機廠商的推播通道。要在 App 內販售虛擬商品或訂閱方案的，先查清楚各應用程式商店目前的付款規則，不同地區不同，而且經常調整。

隱私法規與資料保護

App 的隱私保護要從設計階段做起：只蒐集必要的資料，弄清楚適用哪些法律，先取得同意再追蹤，在應用程式商店如實申報，並允許使用者刪除帳號。隱私既是法律義務，也是商店的審核要求，一開始就設計進去，比上線後返工省事得多：

只蒐集需要的資料：每個表單欄位、每項權限（定位、聯絡人、相機）都要對應一個說得清楚的功能。
弄清楚適用哪些法律：有歐盟使用者就適用 GDPR。歐洲資料保護委員會（EDPB）的中小企業資料保護指南（英文）寫明，公司即使不在歐洲經濟區，只要向區內的人提供產品或服務，也要遵守；處理個人資料要有合法依據，並告知使用者資料怎麼使用。台灣有《個人資料保護法》，香港有《個人資料（私隱）條例》，面向中國大陸使用者則適用《個人信息保護法》；其他國家和地區也有各自的隱私法律。
先同意，再追蹤：在歐盟，非必要的分析、廣告類 SDK 一般要在使用者同意後才能執行；中國大陸的應用程式商店通常也要求首次啟動時顯示隱私政策，使用者同意後再初始化第三方 SDK。在 iOS 上跨 App 追蹤使用者，還要透過蘋果的「App 追蹤透明度」彈出視窗取得許可。
在商店如實申報：蘋果要求填寫「App 隱私權」資訊，Google Play 要求填寫「資料安全性」表單，都要提供隱私權政策，申報內容必須與 App 實際行為一致。
允許刪除帳號：只要 App 支援註冊，蘋果《App 審查指南》第 5.1.1 條（簡體中文）就要求在 App 內提供帳號刪除功能；Google Play 的帳戶刪除規定除了應用程式內的路徑，還要求提供一個網頁連結，讓使用者在 App 以外也能要求刪除帳號和相關資料。

測試、上架審核和開發者帳號

App 上架前要過三關：實機測試和小範圍封閉測試，蘋果和 Google 的上架審核，以及用您公司自己的開發者帳號發布。

測試：用實機測試，涵蓋新舊機型、大小螢幕和支援的系統版本，再透過蘋果的 TestFlight 和 Google Play 的測試群組做小範圍測試。依照 Google Play 的測試規定，2023 年 11 月 13 日後建立的個人開發人員帳戶，必須先完成至少 12 名測試人員連續參與至少 14 天的封閉測試，才能申請正式版權限；這項規定只針對個人帳戶。

上架審核：蘋果依《App 審查指南》（簡體中文）、Google Play 依開發人員計畫政策審核。蘋果審查指南第 4.2 條寫明，App 應包含功能、內容和使用者介面，而不僅僅是一個重新包裝過的網站。常見的退件原因有：閃退、商店資訊不完整、缺少隱私說明、沒有刪除帳號功能、沒提供測試帳號給審查人員，以及只是把網站「套殼」。排時程時要為退件和重新送審預留空間。

上架中國大陸市場：Google Play 在中國大陸無法使用，Android 版要分別提交到華為、小米、OPPO、vivo、應用寶等商店。在中國大陸上架（含 App Store 中國大陸區）要先完成 App 備案，需要中國大陸的主體；當地的 Android 商店通常還要求軟體著作權等資料，以各商店規則為準。

用自己的開發者帳號：App 應發布在您公司自己的開發者帳號下，而不是開發公司的帳號。蘋果開發者計畫按年收費，Google Play 開發人員帳戶是一次性註冊費；兩邊的機構帳號都需要鄧白氏編碼（D-U-N-S）並通過身分驗證，建議及早辦理。網域、伺服器、程式碼儲存庫和簽署憑證，也要掌握在自己手裡。

影響開發費用和時程的因素

App 的開發費用和時程主要取決於五個因素：平台和使用者角色的數量、功能複雜度、系統串接、設計與法規要求，以及您這邊的配合速度。所以問「開發一個 App 需要多少錢」時，可靠的團隊會先問清楚需求再報價：

平台和角色：iOS、Android、網頁、管理後台各是一份工作量；使用者端、員工端加上管理後台，其實是三個產品。
功能複雜度：即時聊天、即時定位、影音、離線同步、複雜的預約規則，都是工作量較大的功能。
系統串接：每串接一個外部系統就多一份工作，沒有完善 API 的舊系統更費時。
設計與法規：標準元件比大量客製動畫快；多語言、當地付款方式、資料移轉、中國大陸備案和嚴格的資安要求都會增加工作量。
您這邊的配合：回饋和決策是否及時，文案、圖片和商品資料能否準時到位。

上線也不是預算的終點。蘋果和 Google 每年都會發布新系統，商店要求也隨之更新；第三方套件要升級、修補資安漏洞，伺服器有持續費用；真實使用者的使用情況，會告訴您下一步該做什麼。

怎麼向開發團隊提需求

向開發團隊提需求，最好準備一份書面需求說明，寫清楚問題、核心路徑、平台、要串接的系統和限制條件，團隊才能給出有意義的評估。建議包括：

要解決的問題、目標使用者和衡量成功的指標。
核心使用路徑、MVP 功能清單和「以後再做」清單。
平台、目標國家或地區和語言。
需要串接的現有系統和資料，以及誰會使用管理後台。
您喜歡的 App，以及具體喜歡它哪一點。
限制條件：期望上線時間及原因、預算範圍、由誰拍板。

也問問開發團隊：工作怎麼分階段？程式碼、設計稿和各類帳號歸誰？需求變更和上線後的維護怎麼安排？

常見問題

原生開發還是跨平台開發比較好？

點餐、預約、會員、企業內部工具這類業務 App，跨平台開發是合理的預設選擇，一套程式碼同時涵蓋 iOS 和 Android。如果依賴複雜圖形、相機或影音處理，或需要第一時間用上系統新功能，原生開發比較合適。

開發一個 App 需要多少錢？

沒有統一價格，取決於平台數量、畫面和使用者角色、系統串接、設計和法規要求，以及上線後的維護。把 MVP 需求寫清楚，並請團隊依階段拆分報價，是取得可靠報價的最好方法。

一定要用自己的蘋果和 Google 開發者帳號嗎？

強烈建議。用自己的帳號發布，商店頁面、使用者評論和後續更新都由您掌控，以後更換開發團隊也不必搬移 App。蘋果開發者計畫按年收費，Google Play 是一次性註冊費；機構帳號需要鄧白氏編碼。

我們為全球客戶設計和開發 iOS、Android App，以及背後的後端和管理後台，以中文、西班牙語或英語溝通。可以看看我們的軟體與 App 開發服務，或直接聯絡我們，聊聊您的想法。

說明：本文為一般性資訊，不構成法律意見。商店政策和各地法規會更新，具體情況請諮詢律師或專業的資料保護顧問。