Mobile App Spec Review — 比 Web 多 5 倍痛點的審查 checklist

「Web 都會寫 spec review 了、Mobile 應該差不多」 — 錯了。Mobile 多了權限、推播、deep link、offline、跨平台、OS 碎片、電量、網路、store 審核九個維度的痛。這篇給你 25 題專用 checklist。

Mobile 為什麼比 Web 難

mindmap
  root((Mobile spec<br>痛點來源))
    系統互動
      權限對話框
      推播 token
      Background lifecycle
      Deep / Universal link
    硬體
      電量
      網路切換 (4G/WiFi)
      記憶體
      相機 / 麥克風
    OS 碎片
      iOS 多版本
      Android 廠商客製
      OEM 修改 UI
    跨平台
      iOS 與 Android 一致?
      原生 vs RN vs Flutter
    Store
      Apple / Google 審核
      隱私規範
      Update 不能強制

每個維度 spec 都該想到。

25 題 Mobile Spec Review Checklist

按 9 個維度組織、每題都是必問。

A. 權限（5 題）

flowchart TD
    Trigger[App 觸發某功能] --> Q{該功能需要權限?}
    Q -->|是| Ask[彈權限對話]
    Ask --> Resp{使用者選?}
    Resp -->|允許| Use[正常用]
    Resp -->|拒絕| Fall[Fallback 流程]
    Resp -->|不要再問| Settings[引導去 Settings 開]

    style Fall fill:#f59e0b,color:#fff
    style Settings fill:#a855f7,color:#fff
  1. 首次觸發時機：什麼時候彈權限？
  2. 拒絕 fallback：使用者選「拒絕」後 UX 怎樣？App 還能用嗎？
  3. 「不要再問」處理：第三次 iOS 會自動拒絕、需要引導去 Settings
  4. 權限說明文案：iOS 強制要寫 NSPhotoLibraryUsageDescription 等、文案有寫嗎？
  5. 權限請求理由解釋：彈視窗前先解釋為什麼要、否則使用者多半拒絕

B. 推播（3 題）

  1. 三種 App 狀態：foreground / background / killed 收到推播分別怎處理？
  2. Deep link in push：點推播打開 App 後跳哪個畫面？
  3. 訂閱 token 管理：使用者改帳號、登出時 token 怎處理？
  1. Universal Link 對應 URL：哪些 URL pattern 該開 App?
  2. Fallback 當 App 沒安裝：開 App store 還是 web?
  3. 登入狀態判斷：deep link 進入時還沒登入 → 跳 login 還 → 開後再返?

D. Offline（3 題）

  1. 完全離線可用嗎：哪些功能可離線？
  2. 資料同步策略：上線後怎麼 sync 衝突？
  3. 網路恢復通知：怎麼告訴使用者「現在可以送出了」？

E. 跨平台一致性（3 題）

  1. iOS 與 Android UI 差異：原生元件不同（picker、navigation bar）— spec 有寫差異嗎？
  2. 手勢一致性：左滑返回是 iOS native、Android 沒有
  3. 平台專屬功能：iOS Face ID、Android 多視窗、各自要不要做？

F. OS 升級 / 碎片（3 題）

  1. 支援最低 OS 版本：iOS 15+? Android 9+? 怎麼決定？
  2. 新 OS 升級時影響：iOS 18 出來壞了什麼？
  3. OEM 行為差異：Samsung 的「電池優化」會殺背景、怎處理？

G. 電量 / 網路（2 題）

  1. 背景處理電量：地點追蹤、推播、健康資料 — 背景跑多少？
  2. 慢網路體驗：4G / 高鐵 / 飛行模式 fallback UX？

H. App Store 審核（2 題）

  1. 隱私 manifest：Apple 要求 PrivacyInfo.xcprivacy、有更新嗎？
  2. App Tracking Transparency：iOS 14+ 追蹤要先問、有彈嗎？

I. 更新策略（1 題）

  1. 強制更新 vs 軟更新：Critical bug 是強更還軟更？rollback 怎麼做？

三類 App 的差異

flowchart TD
    Type[App 類型] --> N[Native iOS/Android]
    Type --> Cross[Cross-platform RN/Flutter]
    Type --> Hybrid[Hybrid WebView]

    N --> N1[平台一致性?<br>需 2 份 spec]
    Cross --> C1[同 spec、但平台差異 attach]
    Hybrid --> H1[權限 webview 通過、<br>OS feature 受限]

    style N fill:#06b6d4,color:#fff
    style Cross fill:#10b981,color:#fff
    style Hybrid fill:#a855f7,color:#fff

完整實戰範例

Spec 原文（典型寫法、不全）

功能：使用者上傳大頭照
- 使用者點 profile 頁的相機 icon
- 開啟相機選擇照片
- 上傳到伺服器
- 顯示新照片

Spec Review 提的 25 個問題（節錄）

# 問題
1 「相機 icon」是 iOS 還 Android 樣式？跨平台一致？
2 點 icon 出現「相簿 / 拍照」選單還直接相機？
3 第一次點時要彈 NSCameraUsageDescription、文案？
4 使用者拒絕相機權限 → fallback 是僅相簿、還是 disable 整功能？
5 相簿權限拒絕 → 怎處理？
6 iOS 14+ 允許「選特定照片」、UX 一樣嗎？
7 照片大小限制？超過怎麼處理？
8 上傳中網路斷掉怎處理？
9 上傳中切到背景、回前景能繼續嗎？
10 推播通知「上傳完成」？
11 Offline 能不能先存、後同步？
12 Deep link 從外面開啟到 profile 頁、再點相機 → 流程相同？
13 iOS 跟 Android 旋轉照片 EXIF 處理一致？
14 上傳失敗 retry 策略？
15 iOS Face ID 需要重新驗證嗎？
16 Android 不同廠商相機 app 行為一致？
17 隱私 manifest 有更新嗎？
... ...

問完這 17 題、PM 才知道這功能其實沒寫完 spec。

三段式 Spec Review 流程（給 mobile）

flowchart LR
    S1[Stage 1<br>看 spec 完整度] --> S2[Stage 2<br>提 25 題問題]
    S2 --> S3[Stage 3<br>檢視跨平台差異]

    S1 --> Q1["功能 happy path 有寫嗎"]
    S2 --> Q2["25 題 checklist"]
    S3 --> Q3["iOS 跟 Android 各自的差異"]

    style S1 fill:#06b6d4,color:#fff
    style S2 fill:#a855f7,color:#fff
    style S3 fill:#10b981,color:#fff

QA 工具地圖

工具 用途
Firebase Analytics 看 user OS / 裝置分佈
Sentry / Bugsnag Crash 報告
TestFlight iOS beta
Firebase App Distribution Android / iOS beta
BrowserStack 跨真機測試
Charles Proxy 攔網路 debug

反模式

flowchart TD
    Anti[Mobile spec 反模式] --> A1["完全照 web spec 寫"]
    Anti --> A2["忽略權限拒絕分支"]
    Anti --> A3["推播沒 deep link"]
    Anti --> A4["不寫 offline 行為"]
    Anti --> A5["不指定最低 OS"]
    Anti --> A6["不分平台差異"]
    Anti --> A7["不寫 Store 審核要求"]

    style A1 fill:#ef4444,color:#fff
    style A2 fill:#ef4444,color:#fff
    style A3 fill:#ef4444,color:#fff
    style A4 fill:#ef4444,color:#fff
    style A5 fill:#ef4444,color:#fff
    style A6 fill:#ef4444,color:#fff
    style A7 fill:#ef4444,color:#fff

給 Mobile QA 的 5 句

  1. 每個功能至少 5 個權限 / 網路 / OS 相關問題
  2. iOS 跟 Android 不同平台、不同 spec 段落
  3. TestFlight beta 階段是 spec review 第二次機會
  4. Store 審核被拒 90% 是 spec 漏掉的事
  5. OS 升級永遠在打破你的 spec

最後

Mobile spec review 不是「跟 web 一樣多想幾個東西」、是完全不同的腦袋。每多想一個權限 / 推播 / 離線 / 平台差異的情境、上線後省一週 hotfix。從這 25 題開始、6 個月後你會變 PM 在 spec review 階段主動找的人。

延伸： - Mobile App Testing 入門（Appium vs Detox） - Spec Review Checklist