症狀：App Store Connect 的新版年齡分級問卷出現社交媒體能力問題，但產品團隊只知道「有沒有社群」的模糊答案。
最快解法：不要按 App 分類猜選項，先檢查使用者生成內容是否能被資訊流重新分發、放大或互動；若未滿 13 歲停用社交能力，還要完成年齡範圍判斷與測試。

誰應該先看這份驗收清單

如果你準備在 2026 年 9 月後提交新版、更新 App，或為替代應用程式市場分發申請公證，這份清單可以用來提前清除元資料阻塞風險。

如果你的產品包含評論、社群、公開內容、推薦流，或需要限制未滿 13 歲使用者的互動功能，產品、工程與上架營運人員應一起完成核對。本文是產品與技術驗收框架，不取代個別地區的法律意見。

最後更新於 2026 年 8 月 14 日；資料核實自 Apple Developer News 的 Time Allowances 公告、App Store Connect 發布說明、年齡分級定義 與 Declared Age Range API 文件。

先用功能場景決定問卷路徑

Apple 已確認，從 2026 年 9 月起，提交新版本或更新至 App Store，或為替代應用程式市場分發申請公證時，必須回答 App 是否具備社交媒體能力。目前官方公告只寫「從 9 月起」，沒有公布統一適用的具體日期。

先把線上版本的真實功能放進下表，不要先看產品名稱、主分類或行銷定位：

線上功能場景 問卷判斷方向 你要留下的證據
純本地工具、單向閱讀、私有工作區，沒有公開內容傳播 通常不選社交媒體能力，但仍須核對隱藏入口 功能清單、權限設定、版本說明、操作截圖
有公開 UGC，但沒有推薦流、轉發、按讚或可見互動 分開判斷 UGC 與 Social Media，不要把兩者混為一談 UGC 顯示範圍、搜尋規則、分享權限
有公開資訊流、推薦、留言、按讚、轉發或內容放大 應如實申報社交媒體能力 資訊流規則、互動流程、舉報與封鎖測試
對未滿 13 歲停用社交功能 需要年齡範圍判斷，不能只靠問卷文字 API 回傳、功能閘門、低年齡測試紀錄

Time Allowances 的 Social Media 分類，不等於 App Store 用來發現應用程式的主分類。 Apple 說明，Social Media 分類取決於 App 是否具備社交媒體能力；Entertainment 或 Games 則會參考 App Store Connect 的主要或次要分類。

第一步：把「有內容」與「能放大內容」分開

工具型 App 最容易在這一步誤判。使用者可以上傳一張圖片，不代表一定有社交媒體能力；但如果圖片會出現在公開推薦流、熱門搜尋、社群頁面，或其他人可以按讚、留言、轉發，就已經接近 Apple 對社交媒體能力的描述。

你應逐項檢查以下邊界：

  • 是否有公開評論、動態、貼文或作品牆。
  • 是否有推薦流、熱門排序、搜尋曝光或「你可能喜歡」。
  • 是否能按讚、反應、留言、轉發或引用其他使用者內容。
  • 是否有第三方元件在灰度測試中開啟社群入口。
  • 舊版本是否留下深層連結、公開 API 或未移除的互動頁面。
  • 管理員、測試帳戶與一般帳戶看到的內容是否不同。

Apple 對 Social Media 的描述包括透過社交資訊流或類似發現方法，重新分發、放大或與使用者生成內容互動；例子包括轉發、按讚、留言、反應，以及透過社群、搜尋或分享工具讓內容被更多人看見。

場景案例：
一個筆記 App 沒有「社群」按鈕，但公開筆記會被推薦到首頁，其他使用者也能收藏與留言。這不是單純的私有工作區。你應以實際內容曝光與互動流程申報，而不是因為產品名稱叫「筆記工具」就選否。

工具型產品的優點與風險

較容易維持非社交路徑的條件：

  • 內容只在本人或受邀工作區內可見。
  • 沒有公開推薦與熱門排序。
  • 沒有轉發、按讚或公開留言。
  • 分享只產生一次性連結，且不形成可瀏覽的內容池。

仍需重新檢查的風險：

  • 第三方評論套件被開啟。
  • 舊版本使用者仍可進入公開頁面。
  • 後台有推薦功能，但問卷負責人不知道。
  • 網頁版有社交能力，iOS 或 macOS 版本卻沿用同一 App 記錄。

第二步：有 UGC 的產品要完成「三方對照」

Apple 的 User-Generated Content 與 Social Media 是不同能力。前者著重使用者建立的內容是否被廣泛分發；後者進一步關注內容是否透過資訊流或相似的發現工具被重新分發、放大或互動。年齡分級頁面也把兩者列為不同能力項目。

請讓產品、審核營運與開發各自填寫一次，再對照差異：

核對角色 必答問題 常見落差
產品負責人 使用者內容會被誰看見？是否有推薦？ 只看設計稿，忽略已上線的灰度功能
開發負責人 低年齡帳戶是否仍能讀取資訊流或互動？ 只封鎖按鈕，沒有封鎖 API 回傳
上架營運 App Store Connect 答案是否與最新版本一致？ 沿用舊版本問卷，沒有重新查看功能變更

如果選擇包含社交媒體能力，Apple 已確認它會被放入 Time Allowances 的 Social Media 分類，並產生最低 13+ 年齡分級。若社交能力對未滿 13 歲使用者停用，整體問卷答案仍可能產生低於 13+ 的評級；但 13 歲以上使用者仍可能被歸入 Social Media 分類。

因此，不能用「最低功能的平台」代表整個 App。年齡分級屬於 App 層級資訊，會套用至不同平台；如果 iOS 有公開資訊流，而 macOS 只有私有工作區，你仍要以官方規則核對同一 App 記錄的申報口徑。

第三步：未滿 13 歲門控要驗證程式碼，不只驗證問卷

選擇「社交媒體能力對未滿 13 歲停用」時，最常見的錯誤是只在 App Store Connect 勾選選項，卻沒有讓 App 真正執行限制。

Apple 說明，這條路徑至少需要使用 Declared Age Range API 檢查使用者的年齡範圍，並只提供適齡的使用者生成內容。API 回傳的是使用者或家長、監護人所申報的年齡範圍，不是精確生日；相關資料也可能在特定情況下透過付款方式或政府身分文件確認。

測試分支 預期行為 必須保存的紀錄
未滿 13 歲 不顯示社交資訊流，不可留言、分享或互動 年齡範圍、功能閘門、API 回應
13 至 15 歲 按產品規則開放適齡內容與功能 帳戶情境、內容分級、畫面截圖
達到門檻年齡 開放已申報的社交能力 功能前後差異、事件紀錄
家長或監護人撤回同意 即時收回受限制功能或重新要求授權 撤回時間、通知、伺服器狀態
無法取得年齡範圍 不應直接當作成年人放行 錯誤分支與安全回退行為

在 Xcode 的目標設定中啟用 Declared Age Range capability，系統會加入 com.apple.developer.declared-age-range entitlement。Apple 的 Declared Age Range Sandbox 測試文件提供未滿 13 歲、13 至 15 歲、16 至 17 歲及 18 歲以上等測試情境，並說明回傳 lowerBound、upperBound 與年齡聲明欄位的方式。

不要把 API 當成精確生日服務。 你的程式應依年齡範圍與產品政策建立功能閘門，並為「拒絕分享」、「資料不可用」、「同意撤回」設計明確的回退狀態。

第四步：在 App Store Connect、平台與分發方式之間對齊

App Store Connect 的年齡分級問卷不是單純的宣傳欄位。Apple 會根據你對內容描述、App 內控制項與能力的回答，產生全球及地區年齡分級；未完成必要年齡分級的 App 不能在 App Store 發布。

提交前應核對三個層面：

  1. App Store Connect 答案：負責人已儲存新版問卷，並截取完成畫面。
  2. 實際功能：生產環境、TestFlight 版本與替代分發版本沒有不同的社交入口。
  3. 分發申請：若要申請替代應用程式市場分發公證，不能只檢查 App Store 版本。

若 iOS、iPadOS、macOS 之間有功能差異，請將差異寫進內部申報紀錄。特別是 macOS 網頁容器、iPad 外接流程或跨平台共用 API，容易讓產品文件寫「沒有社交功能」，但線上版本實際仍能讀取公開資訊流。

中段 FAQ：提交日期、評級與測試判斷

App Store 新版年齡分級問卷何時必須完成？

Apple 的已確認表述是 2026 年 9 月起，提交新版本、更新，或為替代分發申請公證時必須回答社交媒體能力問題。直到 2026 年 8 月 14 日，官方引用頁面仍未公布適用所有團隊的具體生效日，因此不要自行把某個社群傳聞日期當作正式期限。

有留言功能是否必然是社交媒體能力？

不必然。私有工作區內的留言，與公開資訊流上的留言，風險不同。你要看內容是否能被重新分發、放大或讓大量使用者透過搜尋、推薦與社群頁面看見。只用「有沒有留言」作為單一判斷條件，容易把 UGC、Messaging and Chat 與 Social Media 混在一起。

年齡分級答案會不會改變現有評級？

可能會。Apple 會根據問卷答案重新產生年齡分級；社交媒體能力在未停用未滿 13 歲使用者時，官方說明最低分級為 13+。但地區評級、其他內容描述與你是否選擇較高分級覆寫，也會影響最後結果。不要只比較前後一個數字，應保存每個答案與評級明細。

Declared Age Range API 的測試重點是甚麼？

測試重點不是取得精確生日，而是確認不同年齡範圍、家長同意與撤回狀態會觸發正確功能限制。Sandbox 可模擬年齡範圍與同意狀態；你應把 API 回應、畫面狀態、功能請求與後端權限一併記錄。

第五步：用可勾選清單完成三重驗收

App Store Connect

  • [ ] 已在 App Store Connect 開啟正確的 App 記錄。
  • [ ] 已重新檢查 UGC、社交媒體、訊息與年齡保證等能力。
  • [ ] 已儲存新版問卷答案，並保存完成畫面。
  • [ ] 已核對全球與地區年齡分級結果。
  • [ ] 已由產品負責人確認答案描述的是目前線上功能。

程式碼與產品行為

  • [ ] 未滿 13 歲帳戶不能讀取社交資訊流。
  • [ ] 未滿 13 歲帳戶不能留言、分享、轉發或放大內容。
  • [ ] 年齡範圍無法取得時有安全回退，不會直接放行。
  • [ ] 家長或監護人撤回同意後，限制功能會被收回。
  • [ ] 舊版本、深層連結與第三方元件沒有留下繞過入口。

測試環境與提交紀錄

  • [ ] 在實際支援的系統與 Xcode 環境驗證。
  • [ ] 使用 Sandbox 帳戶完成各年齡範圍分支。
  • [ ] 分別記錄拒絕分享、低於門檻、達到門檻與撤回同意。
  • [ ] iOS、iPadOS、macOS 版本差異已寫入驗收紀錄。
  • [ ] 產品負責人與程式碼負責人共同簽字，不把任務單獨交給上架營運。

如果主力 Mac 不適合切換系統、Xcode 或測試帳戶，先閱讀 雲端 Mac 測試環境的使用方向；你也可以比較 Mac mini 雲端算力方案，再決定使用本地專用設備，或按專案週期啟用隔離的雲端 Mac。若團隊主要在香港工作，可進一步查看 香港 Mac 雲端算力方案。

本地專用 Mac 與雲端 Mac，應按驗收風險選擇

本地專用 Mac 的優勢是固定裝置、實體測試方便，適合長期維護同一產品；缺點是切換系統、安裝不同 Xcode 或建立多組測試帳戶，可能污染主力開發環境。

雲端 Mac 的優勢是能把問卷驗收、Sandbox 測試與版本切換放在隔離環境；缺點是需要穩定網路連線，且實體裝置、通知與某些硬體功能仍可能需要本地設備配合。這不是所有團隊都應租用的方案。若你每天長時間使用固定環境，或必須直接連接特殊硬體，本地設備通常更直接。

選擇 適合情境 主要代價
本地專用 Mac 長期維護、固定硬體、持續回歸測試 設備成本、系統切換與環境維護
隔離雲端 Mac 短期問卷驗收、多版本 Xcode、臨時測試帳戶 依賴網路，實體硬體測試能力有限
目前主力 Mac 直接測 只有單一版本、風險低、環境可控 可能污染日常環境，回退成本高

對這次 App Store 年齡分級問卷 2026 的準備，最重要的不是立刻購買設備，而是先把申報答案、功能閘門與 Sandbox 紀錄串成一條可追溯流程。若目前方案會讓你在主力機上反覆更換 Xcode、登入不同測試帳戶，或無法保留乾淨的測試狀態，按專案週期使用 MACCOME 的雲端 Mac，通常比直接改動生產環境更容易控管。