iOS 隱私清單缺失怎麼辦？2026 歸檔排查
這篇指南適合收到 ITMS-91061 或其他隱私清單通知、需要定位問題元件的 iOS 開發者。你會依照通知和檔案路徑分辨清單缺失、格式無效或 SDK 未提供清單，再檢查最終 Archive 的內容，避免把來源碼已修好誤當成提交產物已修好。
Xcode 上傳後收到隱私清單缺失或無效通知，卻不清楚問題在 App 還是第三方 SDK？
最快的處理方式：先按 Apple 通知中的錯誤代碼和元件路徑判斷是缺少清單、格式無效，還是 SDK 沒有提供清單；修正後檢查最終 Archive，再重新驗證提交產物。
適合收到 ITMS-91061 或類似通知、要沿路徑定位責任元件的獨立開發者。
維護 CocoaPods、Swift Package 或 XCFramework 依賴的小團隊，可用本文核對 SDK 是否將清單打入歸檔。
負責遠端 Mac 或 CI 發布驗收的開發者，也可把最終產物檢查納入發布流程。
iOS 隱私清單缺失：從通知路徑判定故障類型
先看通知內容中的錯誤代碼、清單狀態與元件路徑，不要看到「privacy manifest」就直接在 App 專案新增檔案。Apple 的第三方 SDK 隱私清單要求說明了適用 SDK 的清單要求；Apple 的無效隱私清單排查說明 TN3181則提供格式與內容問題的診斷方向。
ITMS-91061 通知若指出某個嵌入元件缺少清單，先把通知中的路徑當作追蹤入口，確認它對應到哪個 framework、XCFramework 或套件。若通知指出清單無效，則檢查既有檔案的結構和值，不要把「已存在」當成「有效」。通知是定位線索，不等同於 App Review 的審核結論。
| 判斷情況 | 優先檢查位置 | 責任範圍 | 排查評級與處理 |
|---|---|---|---|
| App 自身未包含清單 | App Target 設定與最終 App bundle 根目錄 | App 專案 | 高：確認檔案加入正確 Target，並檢查產物 |
| 第三方元件缺少清單 | 通知路徑所指的 framework 或套件 | SDK 提供方及依賴版本 | 最高：核對套件來源與版本，向提供方取得修正版 |
| 清單格式或內容無效 | 出錯元件中的 PrivacyInfo.xcprivacy |
清單維護者 | 高：依 Apple 規格修正 plist 結構、鍵型別與允許值 |
| 上傳產物仍帶有舊檔案 | 本次 Archive 內的 App 與嵌入元件 | 建構輸入與依賴解析 | 最高：確認使用的是修復後依賴，再重新歸檔 |
ITMS-91061 通知應從哪裡開始查？
先抄下通知所列的元件路徑，再在本次 Archive 中找到相同元件。路徑若落在嵌入的 SDK，就先追查 SDK；若指向 App bundle 根目錄，再檢查 App Target。這樣可以避免把 SDK 的責任錯誤地移到 App 自身清單。
App Target 與實際包裝位置
PrivacyInfo.xcprivacy 是清單檔名；Apple 說明了App 或第三方 SDK 如何加入隱私清單以及隱私清單檔案的用途與結構。檔案放在來源碼目錄裡，只能證明它存在於專案資料夾，不能證明它已被建構流程納入正確的 bundle。
檢查時要區分三種狀態：檔案在磁碟上、檔案已納入相應 Target 的建構資源，以及檔案確實出現在最後產物的正確位置。Apple 的文件描述 App 與 SDK 各自的清單包裝位置；因此，App 自身清單應在 App bundle 根目錄檢查，而 SDK 清單則應在相應 framework bundle 內核對。實際路徑以通知所指元件和 Apple 對應平台的包裝規則為準。
在 Xcode 中確認檔案是否加入 App Target，並查看建構階段是否會複製或處理它。完成 Archive 後，在 Xcode 的歸檔管理介面定位產物，檢查 .xcarchive 內的 App bundle；若要核對可分發的 IPA，也可檢查解包後的 App bundle。比對時確認檔名、所在 bundle 及內容，不能只憑 Xcode 專案導覽器中的檔案圖示判斷。
第三方 SDK 的來源追查與責任界線
通知列出 SDK 路徑時，先從 Archive 找到它實際嵌入的位置，再回查該依賴是由 CocoaPods、Swift Package、XCFramework 或其他建構輸入帶入。記下套件名稱、來源與解析到的版本，並核對它是否與你預期的依賴版本一致；專案設定中的依賴名稱，未必足以證明最後打入包內的是同一份二進位檔。
如果確認清單缺失屬於 SDK 本身，優先升級至提供者已修正的版本，或向 SDK 提供方索取符合要求的版本。不要自行把 SDK 的資料收集類型、追蹤網域或必要原因 API 用途寫進 App 的清單，藉此代替 SDK 清單。Apple 對第三方 SDK 清單要求有獨立說明，App 與 SDK 各自的責任不應混為一談。
第三方 SDK 沒有 PrivacyInfo.xcprivacy 時怎麼處理？
先確認通知中的路徑與實際嵌入的版本一致，再聯絡 SDK 提供方或更新依賴。若最新版仍沒有必要清單，應評估暫停使用、替換依賴或等待正式修正；不要以 App 自身清單代填 SDK 的隱私聲明。
無效清單的格式和值檢查
清單無效與清單缺失是不同故障：缺失代表預期位置找不到所需檔案；無效則代表找到了檔案，但其格式或內容不符合 Apple 要求。遇到後者，按 TN3181 指出的線索檢查 plist 是否可解析、欄位是否使用規定的型別，以及必要鍵和值是否符合文件規格。錯誤訊息指出的鍵或值，應優先對照 Apple 的隱私清單檔案規格，不要靠猜測補欄位。
若清單申報了 Required Reason API，應逐項核對實際使用情況與允許的原因值。Apple 對Required Reason API 的申報方式有專門說明；原因必須能對應實際用途，不能為了讓上傳通過而填入不符合程式行為的理由。需要判斷追蹤或資料收集欄位時，也要按文件定義區分用途，不要把缺失錯誤和語義申報錯誤混成同一問題。
格式無效和檔案缺失是同一種錯誤嗎？
不是。前者要修正已存在檔案的格式、鍵型別或允許值；後者要找出應提供清單的 App 或 SDK，並確認清單是否進入正確 bundle。先按通知分類，才能選對修復方向。
Archive 驗收與重新提交
專案內的修正只有進入本次 Archive，才會影響提交產物。若修復後通知仍然出現，先排除舊依賴、舊建構輸入或錯誤歸檔，再重新建構；不要用來源碼已更新作為產物已更新的證據。
你可以把下列步驟納入每次發布驗收：
- 保存通知線索：記下錯誤代碼、原文與元件路徑，標明它指向 App 或嵌入 SDK。
- 確認實際依賴：從專案依賴設定追到建構解析結果，核對來源與版本，避免修正的版本並未被本次建構採用。
- 檢查 Target 與清單：確認
PrivacyInfo.xcprivacy由預期的 App 或 SDK 提供，並檢查格式和值。 - 重新建立 Archive：清除或更新造成舊依賴重用的建構輸入，然後以修復後的依賴重新歸檔。
- 檢查最終 bundle：在 Archive 中逐一核對 App 與通知所指 SDK，確認清單檔名、位置與內容符合預期。
- 重新驗證提交：將本次產物送交 App Store Connect，記錄建構結果與通知是否消失。
如何確認清單已進入最終 iOS Archive？
檢查歸檔產物內的 App bundle 與通知指向的嵌入元件，而不是只檢查來源碼目錄。Apple 的建構上傳狀態說明可用來判讀提交處理狀態；但上傳驗證完成只說明該次上傳處理結果，並不代表 App Review 已批准。審核狀態應另按 Apple 的App 與提交狀態說明確認。
若要在遠端 Mac 或 CI 上重現，使用不含真實簽署憑據的代表性專案，固定依賴解析方式，保存建構環境、Archive 路徑與檢查結果。把通知路徑、套件版本、歸檔檢查和上傳結果連成可追溯紀錄，之後才能判斷是 SDK 更新、建構輸入還是清單內容造成差異。環境連線或建構流程遇到問題時，可先查閱技術支援入口與支援中心的相關資訊。
如果你目前在 Windows 或 Linux 上開發，缺少可執行 Xcode Archive 的環境，常見替代方式各有成本：請協作者代打包會增加交接與重現難度；臨時雲端建構可能受限於可檢查的產物與環境控制；購買 Mac 則要承擔硬體投入、維護和閒置時間。需要短期復現清單問題、檢查 Archive 或完成發布驗證時，租用 VPSMAC 的遠端 Mac 可提供一台真實 Mac，並透過 VNC、SSH 或網頁主控台連線；你可先查看遠端 Mac 服務資訊，再判斷是否適合你的驗收流程。若你需要長期穩定的高負載建構，或必須直接連接實體裝置與周邊，自購 Mac 可能更合適。