行動開發新手遇到平台權限問題時常見的隱藏成本與避錯提醒

2025 年全球智慧型手機用戶大約在 50 億 這個量級（各家研究口徑不同，但都差不多是「一半以上人類」在滑），所以你做的 App 體驗爛掉，基本上不是「小問題」，是直接在品牌臉上刮一刀。

先講結論：原生（Native）跟跨平台（React Native／Flutter／Kotlin Multiplatform Mobile）都不是銀彈；真正的成本在於 平台權力（Apple/Google 隨時改規則）會讓你在 iOS 26 的 Liquid Glass 這種大改版時，被迫加班補洞，尤其跨平台通常會慢一拍甚至慢好幾拍。

你的 App 要不要吃新 OS 功能：像 Live Activities 這種，跨平台常常晚幾個月
UX 要不要像原生：iOS 用戶跟 Android 用戶的「操作節奏」真的不一樣
你能不能接受框架等更新：社群套件會停更，GPU 開銷也可能噴出來
你到底要省什麼：省人力？省時間？還是只是省「心安」

別再問誰死了，平台才是老大

Apple 與 Google 透過 iOS/Android 的 API、設計系統與商店規則控制節奏，任何跨平台框架都必須追著跑；你忽略這個「平台權力」，成本會在大改版時用 bug、延遲與重工的形式還給你。

你看過那種 LinkedIn 標題戰嗎：「Native 已死」跟「Cross-platform 已死」輪流上台，像兩個人在酒吧吵架，吵到最後也沒人付錢。點閱率很爽啦，但現實是——如果真有銀彈，早就統一世界了。

平台的動機很單純：先顧自己。Apple 要的是一致的 iOS 體驗、黏住開發者、黏住用戶；Google 也差不多，只是手法不一樣。你在中間想「我們能不能用一套程式碼搞定兩邊」？可以，但你得接受：平台每次翻桌，你也要跟著把桌子撿回來。

平台不會為了你的工程效率讓步；它只會為了自己的品牌與生態讓步。

iOS 26 的 Liquid Glass：跨平台最怕的那種改動

iOS 26 引入 Liquid Glass 視覺效果與互動細節，Apple 在 Xcode 26 提供暫時的相容模式可選擇退出，但官方意圖是在 iOS 27 移除這個退出選項，這會讓跨平台框架面臨一段時間的缺件與怪 bug。

這段真的很殘酷：Apple 還算「客氣」給你一個暫時的相容模式，但你別把它當長期避風港。那種感覺很像房東說「你可以先欠房租三個月」，然後你真的以為房租不用付。嗯，會出事。

所以到 iOS 27 那一刻，如果退出被拿掉：

你要嘛讓 App 看起來像上一代（對，會被用戶感覺到）
要嘛趕快補到跟上新設計（通常要寫原生橋接或等框架更新）

講到「看起來像上一代」，我突然想到一堆公司做品牌改版，Logo 換了、官網換了，但 App 還停在兩年前的 UI，然後行銷還在說「我們很重視使用者體驗」。嗯。

回來。Liquid Glass 這種改動，會把跨平台「能不能跟上」的問題放大到你沒法裝死。

Flutter、React Native、KMM 到底在 Liquid Glass 上會卡哪裡

Flutter 依賴自家渲染引擎追求一致外觀，但 Liquid Glass 這種平台級效果只能近似模仿，且缺少官方 Cupertino 支援時容易依賴社群套件；React Native 因使用 UIKit 元件較貼近 iOS，但完整整合仍可能需要橋接 UIGlassEffect；KMM 主要共享商業邏輯並採原生 UI，需決定共享 UI 的界線。

Flutter：我知道很多人愛它那個「我畫我自己的」的掌控感。畫面一致、跨平台像同一個人寫的。爽。

但 Liquid Glass 這種東西，平台說「這裡要像玻璃一樣折射、混色、動態反應」，Flutter 的引擎就算再努力，也常常只能做到「差不多像」。差不多在 demo 很夠用，上線後就開始有人問：「為什麼別的 App 那個效果比較順？」

還有一個很煩的點：社群套件。你會看到有人做 Cupertino 相關的 package，然後 issue 區一堆「GPU overhead」或「掉幀」的回報。再加一個風險：作者哪天不做了。就沒了。

就這樣。

React Native：它走的是「用原生 UI 元件」的路線，所以跟 iOS 的距離比較近。你用 UIKit 元件，基本上比較不會像套皮一樣。

但你要吃到完整 Liquid Glass？你還是可能得橋接 UIGlassEffect 這類能力。橋接不是罪啦，問題是你當初選跨平台的其中一個理由，通常就是「不要一直寫原生」。結果最後還是寫。只是你寫得更分裂。

KMM（Kotlin Multiplatform Mobile）：它比較像「不要硬逼 UI 一樣」，主要共享 business logic，UI 多半還是走原生（Android 用 Jetpack Compose，iOS 用 SwiftUI / UIKit）。

原文提到它在 2025 年 5 月到 stable。OK，這至少是個里程碑。

但你如果用共享 UI（Compose Multiplatform），iOS 可能會有那種「怎麼有點 Android 味」的感覺，尤其你沒做自己的 design system 的話。這不是技術對錯，是用戶習慣問題。iOS 用戶就是會對某些滑動、返回、動效的節奏很敏感。

真正的成本不是寫程式，是等、補、還有重做

跨平台的「框架稅」通常落在效能、外觀一致性、原生橋接與重複工作上；原生的「原生稅」則是 iOS/Android 幾乎兩套人力與長期維護成本。選擇技術棧前要先定義你要付哪一種稅。

我很討厭那種會議：大家說「我們要不要用跨平台省成本」，講得像去 Costco 買一包衛生紙一樣輕鬆。然後沒人講「省的是哪一段成本」。

跨平台常見的現實：

等套件成熟：新 OS 功能出來，你可能要等幾個月才有穩定支援（Live Activities 就是例子）
最後還是寫原生：要整合到「像系統內建」那種程度，橋接跑不掉
修 bug 的定位更繞：是你的 code？是框架？是某個 plugin？還是 iOS 新版行為變了？

原生也不是什麼天堂。原生就是兩套：

兩套 UI
兩套 release 節奏
兩套「誰又把某個 API 用錯」的火災現場

你以為你在選技術，其實你在選未來兩年的生活品質。

跨平台不是免費午餐；原生也不是免費加班券。

UX 別硬做成一樣，iOS 跟 Android 用戶真的會翻臉

iOS 與 Android 的設計系統（如 Liquid Glass 與 Material You）刻意維持差異以保護各自生態，用戶也多半長期留在同一平台；因此 UX 需要在設計初期就決定哪些要共享、哪些要平台原生，而不是上線後才用補丁修補「不像原生」的感覺。

這個點很多團隊會裝沒看到：以為「兩邊長一樣」就叫一致體驗。錯。那叫偷懶。嗯我講得有點兇，但真的。

iOS 用戶習慣某些導航節奏、控制元件的觸感、動效的速度；Android 也有自己的節奏。你把兩邊硬壓成同一套 UI，最後就是：

iOS 用戶覺得「這什麼怪東西」
Android 用戶覺得「這又在裝什麼 Apple」

而且大多數人根本不會每天換手機平台。他們是忠誠的。你去挑戰他們的肌肉記憶，回饋通常不會很溫柔。

分眾決策建議：你是哪種團隊就走哪條路

技術選型應以產品需求、團隊能力與平台變動風險為準：若需要第一時間支援新 OS 功能或硬體層（如 BLE），優先原生或至少原生模組；若目標是快速驗證 MVP 且 UX 可接受妥協，可用跨平台；若想兼顧共享與原生體驗，可用 KMM 共享邏輯並保留平台 UI。

規則：下面是「If This Then That」的分眾建議，拿去對照你現在的狀況，別拿去當宗教。

如果你是新創要拼 MVP：你要的是「三個月內上線驗證」那種速度，功能別太貼系統、不要追第一時間 OS 新玩具。
那可以考慮 React Native / Flutter，但請先寫下：哪些畫面允許不像原生，哪些地方不行。先寫。拜託。
如果你是電商或內容平台：你要的是穩定迭代、A/B 測試、支付、推播、會員、分析工具一堆。
通常可以走「跨平台 + 原生補洞」的混合路線，重點是把橋接的範圍管住，不要最後變成三套。
如果你是金融、醫療、企業內部系統那種很怕出包的：不是說跨平台不行，是你要能承擔「平台一改就連環炸」的風險。
多數情況會偏向原生，或至少把登入、交易、關鍵流程做得很貼平台，錯一次就很難看。
如果你有 BLE、硬體整合、即時相機/音訊處理：別鬧。真的。
至少那些 layer 走原生，跨平台要做就做上層，不要硬扛底層。
如果你是大公司、兩邊都有成熟團隊：你可以用 KMM 共享商業邏輯、資料層，UI 保持原生。
但你要有人能把架構收斂，不然共享邏輯也會變成共享痛苦。
如果你只有 1～2 個 mobile 工程師：你其實在選的是「能不能活下去」。
跨平台可能讓你先活著，但你要提早安排「平台大改版時誰來救火」。不要等到 iOS 27 才想起來。

優缺點攤開來看，不要只聽誰講得大聲

原生與跨平台各自的代價可以用「外觀貼平台程度、性能、重複工作量、跟上 OS 新能力速度、依賴第三方套件風險」來比較；選擇前先列出你不能退讓的兩到三個指標，避免把技術選型變成情緒投票。

選項	你會爽的地方	你會崩潰的地方
原生 iOS + 原生 Android	新 OS 功能、系統元件、設計語言改版通常第一時間吃得到；效能與除錯路徑比較直，不用猜是不是框架在搞你。	兩套人力、兩套 UI、兩套維護；產品一改需求，兩邊都得改，工時就是那麼實在地噴出去。
React Native	靠 UIKit/原生元件，比較容易做出「看起來像 iOS/Android」的質感；共享一部分程式碼，MVP 速度常常不差。	遇到平台大改或要吃特殊效果時，橋接逃不掉；第三方模組品質參差，升版有時像踩地雷。
Flutter	渲染一致，UI 控制感強；跨平台畫面比較「同一套」，做品牌一致性很直覺。	平台級新視覺（像 Liquid Glass）只能近似；依賴社群 Cupertino 套件時，要承擔 GPU 開銷與停更風險。
KMM	共享 business logic，UI 仍可維持原生節奏；適合把「重複的資料層/規則」抽出來省工。	共享 UI 的界線很考驗團隊紀律；iOS 端若用共享 UI 可能出現「不像 iOS」的觀感，設計系統要補得很勤。