一套程式碼上架雙平台:Capacitor 實戰經驗

「做一個 App 要多少錢?」——這個問題的隱藏成本,是很多企業主沒想到的:iOS 跟 Android 是兩個世界,原生開發等於養兩組工程師、寫兩份程式、修兩倍的 bug。對大部分的商業 App 來說,這筆帳划不來。我們的解法是 Capacitor:用網頁技術寫一套程式碼,包成原生 App,同時上架 App Store 跟 Google Play。我們自己的多個產品都是這樣做的,這篇把實戰經驗——包括不那麼光彩的部分——誠實講一遍。

Capacitor 是什麼?先講人話

簡單說,Capacitor 是一個「容器」:你的 App 本體其實是一個網頁應用,Capacitor 把它裝進一個真正的原生 App 外殼裡,並提供橋樑讓網頁去呼叫手機的原生能力——相機、推播、生物辨識、健康資料等等。對使用者來說,它就是從商店下載的 App,有圖示、有推播、可以離線開啟;對開發團隊來說,九成以上的程式碼只寫一次。

跟純網頁(PWA)比,它能上架商店、能用完整原生能力;跟原生開發比,它省下整整一倍的開發與維護人力。這個定位對「功能以表單、清單、內容、購物流程為主」的商業 App 來說,幾乎是甜蜜點。

能力邊界:什麼時候不該用

誠實說,Capacitor 不是萬靈丹。以下情況我們會勸你考慮原生:

• 重度圖形與動畫:遊戲、影音剪輯、AR 這類吃 GPU 的應用,網頁層的效能天花板明顯。
• 長時間背景作業:需要 App 關閉後持續在背景跑的功能(持續定位、背景錄音),原生的控制力好得多。
• 極致的平台原生手感:如果你的產品定位就是要跟系統內建 App 一樣的操作質感,每個轉場都要原生,那就直接原生。

反過來說,會員、預約、電商、內容訂閱、企業內部工具——我們實際交付過的這些類型,Capacitor 都完全夠用,使用者根本分不出來。效能實話是:清單捲動、頁面切換這些日常操作,只要前端寫得節制(圖片壓好、不要無限制堆疊套件),流暢度不會是客訴來源;會出問題的通常是「把桌機版網頁直接塞進去」這種偷懶做法,那不是框架的錯。

審核眉角:蘋果不是針對你,但你要懂規則

上架的坑,九成在 Apple。幾個我們真實踩過、現在列入上架前檢查清單的:

1. 「不能只是網站的殼」:Apple 明文拒絕單純把網站包一層的 App。你要有原生整合的誠意——推播、原生分享、生物辨識登入之類,審核觀感會完全不同。
2. 數位內容必須走內購:App 內賣訂閱、虛擬內容,必須用 Apple 的內購機制,不能引導去外部刷卡,違者直接退件。這條牽扯到的伺服器端驗證,我們在App 訂閱內購的伺服器端驗證那篇有完整的實作筆記。
3. 帳號能註冊就要能刪除:App 內要提供刪除帳號的入口,這是硬規定,很多第一次上架的團隊都栽在這。
4. 第三方登入的配套:提供 Google 或 LINE 登入,就必須同時提供「Sign in with Apple」。
5. 審核用測試帳號要真的能用:給審核人員的測試帳號,要能走完完整流程。我們遇過因為測試環境剛好在維護而被退件的,冤枉但只能認。

雙平台上架的難度,三分在程式,七分在讀懂規則。程式寫得再好,不懂審核規則一樣卡關一個月。

維護才是重點:一套程式碼的真正紅利

很多人算成本只算開發期,但 App 的成本大頭在上架之後:改需求、修 bug、追作業系統改版。每年 iOS 跟 Android 各有一次大版本更新,原生雙軌開發等於每年兩次適配工作都要做兩遍,長期下來這筆維護帳比開發費更驚人。一套程式碼的紅利在這裡才真正兌現——一個功能改一次、測一次、兩個平台同步發版。我們的交付標準是自動化測試加 CI/CD(程式碼一提交就自動跑測試、自動建置),因為跨平台 App 最怕「改了 A 壞了 B 還沒人發現」,這套紀律不是加分項,是必需品。

總結我們的建議:先誠實評估你的 App 是不是圖形重度型,不是的話,Capacitor 大概率是成本效益最好的選擇。如果你正在評估做 App、或已經被雙平台維護成本壓得喘不過氣,歡迎看看我們的客製化系統與 SaaS 服務與過往作品,或直接跟我們聊聊你的產品構想——包括「你這個需求其實不用做 App」這種答案,我們也會誠實告訴你。