Xcode 27 PrivacyInfo.xcprivacy 未進 Archive？2026 排查
📋 本文目錄
症狀：Xcode 專案裡看得到 PrivacyInfo.xcprivacy，但 Archive 找不到，或提交驗證仍有錯誤。
最快解法：先檢查最終 .xcarchive 內的 App 與依賴 bundle，再追查 target 資源設定、Swift Package 資源宣告和第三方 SDK 產物；檔案存在不代表內容有效。
適合本地建置正常、但歸檔包缺少自有 iOS 隱私清單的應用程式開發者。
也適合需要驗證 Swift Package、二進位 SDK 是否入包的行動 CI 工程師。
若你負責遠端 Mac 構建節點，本文會提供可留下稽核證據的檢查方式。
最後更新：2026 年 10 月 5 日。規則依 Apple 隱私清單文件、TN3181 無效清單排查說明、第三方 SDK 要求頁及 Xcode 官方頁面複核。Xcode 27 是工具鏈背景，不代表 Apple 已改變隱私清單規則。
Xcode 27 PrivacyInfo.xcprivacy Archive：先分清是缺檔還是驗證錯誤
不要以 Xcode 專案導覽器中的檔案作為歸檔成功證據。你要確認清單是否出現在最終 .xcarchive 裡正確的 App、Framework 或 SDK bundle，再分別判斷檔案缺失、資源未打包、bundle 位置不符，或清單內容無效。
Apple 說明隱私清單用來描述 App 或第三方 SDK 的隱私實務，且清單必須使用有效的鍵和值；它並未要求所有 App 使用完全相同的內容。實際要申報哪些資料使用與 API 理由，應依程式行為和 Apple 的資料使用說明核對。
| 你看到的現象 | 優先檢查的位置 | 最有用的證據 | 先不要做的事 |
|---|---|---|---|
| 專案內有檔案，Archive 裡找不到 | App target 的資源設定與歸檔組態 | .xcarchive 內實際搜尋結果 |
只看檔案是否出現在導覽器 |
| 套件目錄有清單，App 內沒有 | Swift Package 的資源宣告與套件產物 | 套件資源 bundle、最終 App bundle | 假設放在 Sources 就會自動打包 |
| SDK 有附清單，歸檔後不見 | SDK 二進位內容及其 bundle 結構 | SDK 原始產物與 Archive 對照 | 把 SDK 行為全部寫進 App 主清單 |
| Archive 找得到清單，但提交驗證失敗 | plist 格式、鍵值及 API 理由 | plutil 結果與 Apple 驗證診斷 |
直接修改已簽署的 Archive |
為什麼 PrivacyInfo.xcprivacy 沒有進入 iOS Archive？常見原因是檔案沒有納入目前歸檔的 target、資源複製設定沒有涵蓋使用中的組態，或你檢查的是另一個 Scheme 產物。這幾種狀況都應以 Archive 內容為準，而不是由原始碼路徑推定。
先用搜尋確認歸檔內的檔案位置：
ARCHIVE="<Archive 路徑>"
find "$ARCHIVE" -name "PrivacyInfo.xcprivacy" -print
接著記錄輸出路徑，辨認它位於 App、Framework，還是某個依賴的 bundle。若完全沒有輸出，先回到資源是否參與目前 Archive 的檢查；若有輸出，則繼續驗證位置與內容。這個結果只是「找到檔案」的證據，不是清單已通過驗證的證明。
App target 與 Swift Package：來源檔不等於歸檔資源
App 自有清單漏包時，先在 Xcode 檢查檔案是否屬於預期 target，再核對建置階段的資源處理及正在使用的 Scheme、組態。修正後，以同一個 Scheme、相同提交重新 Archive，否則你可能同時改了輸入條件，無法判斷修正是否有效。
Swift Package 則要查看 Package.swift 的資源宣告與產生的資源 bundle。Apple 的 Swift Package 資源指南說明，套件資源須依套件資源規則處理；因此，檔案僅存在於套件原始碼目錄，不能證明它已進入套件產物或最終 App。
Swift Package 的隱私清單如何確認已打進最終 App？先檢查套件是否把清單列入資源，再檢查建置後的套件資源 bundle，最後搜尋 Archive 內的 App 與相關 bundle。若套件產物已有清單、最終 App 卻找不到，回頭比對套件整合方式與 Archive 中保留的 bundle 結構，不要把問題直接歸咎於 App target。
下列命令可用來檢查清單的 plist 語法：
plutil -lint "<PrivacyInfo.xcprivacy 路徑>"
語法檢查通過只表示檔案能被解析，不代表每個鍵值都受支援、資料使用聲明正確，或 required-reason API 的理由符合實際用法。Apple 的 required-reason API 聲明文件應與程式碼實際使用情況一併核對。
第三方 SDK 與 bundle 位置：逐一對照產物結構
第三方 SDK 需要單獨驗收。先確認供應方是否提供自己的 PrivacyInfo.xcprivacy，再檢查它是否存在於二進位 SDK 的預期 bundle，並在最終 Archive 中確認原有 bundle 結構有被保留。應用整合方負責確認依賴實際入包；SDK 的程式行為及清單內容，則需與 SDK 供應方釐清。
不要以 App 主清單取代 SDK 自己的清單。Apple 對特定第三方 SDK 設有要求，但適用範圍須以官方 SDK 名單與說明為準，不能推論所有套件都適用相同要求。
產品類型不同，清單放置位置也不能用單一路徑套用。Apple 的依平台與 bundle 類型放置內容說明應作為核對依據；請按實際 Archive 的 bundle 結構判斷清單是放錯位置、沒有複製，還是歸檔了不同產品目標。
| 檢查對象 | 位置判斷方式 | 常見錯判 | 下一步 |
|---|---|---|---|
| iOS App | 依 App bundle 類型核對 Apple 文件與 Archive 結構 | 在來源目錄找到檔案就當作已入包 | 核對 target、資源處理及最終 App |
| Framework | 依 Framework bundle 類型檢查其自身內容 | 只檢查外層 App 根目錄 | 比對 Framework 原始產物和歸檔內容 |
| Swift Package | 檢查套件資源宣告及套件產生的 bundle | 將套件原始檔等同於套件資源 | 逐層檢查套件產物與最終 App |
| 二進位 SDK | 檢查 SDK 提供的 bundle 與 Archive 中保留的結構 | 把 SDK 清單責任移到 App 主清單 | 與供應方確認清單及 SDK 版本 |
遠端 Mac CI 的產物比對
如何確認遠端 Mac CI 產生的 Archive 含有 SDK 隱私清單？使用同一提交，在本機和遠端 Mac 分別記錄 Xcode 版本、Scheme、建置組態、依賴解析結果及 Archive 搜尋結果。若來源提交相同而產物不同，再逐項比對解析後的依賴版本與資源設定；若依賴版本不同，先固定解析結果再重建，避免把工作區差異誤判為 Xcode 行為。
把每次驗收結果留在 CI 記錄中，至少包括提交識別、使用的 Xcode、依賴解析資訊、Archive 路徑搜尋輸出、plist 語法檢查結果，以及提交驗證診斷。路徑和專案名稱可使用佔位符；不要把帳戶、簽署憑據或專案機密寫入可公開的建置日誌。
注意：不要在已簽署的 Archive 內直接補檔或改清單。這會改動簽署後的產物；應回到原始建置來源修正，再重新歸檔與驗證。
清單已存在但驗證失敗：把檔案問題和內容問題拆開
隱私清單檔案存在，但提交驗證仍報錯，接下來查什麼？先確認錯誤指向的是檔案路徑、plist 格式、未接受的鍵值，還是 required-reason API 聲明。再依 Apple 的 TN3181 排查流程對照診斷資訊與 Archive 內實際清單，不要只因為 plutil -lint 通過就結案。
以下判分只用來安排排查優先次序，不是 Apple 的官方驗證分數。每一項符合記 1 分：最終 Archive 已找到清單；清單位於對應產品 bundle；plist 語法通過；鍵值與 API 理由已依官方文件核對。達到 4 分才進入提交驗證；少任何一項，就先補足對應證據。
依證據選擇修正路徑
- 若 Archive 完全找不到自有清單，先修正 App target 或資源處理設定，再用同一 Scheme 重建。
- 若 Swift Package 原始碼有清單、套件產物沒有，修正套件資源宣告並檢查套件產物。
- 若 SDK 原始 bundle 有清單、Archive 沒有，核對整合流程是否保留該 bundle；仍無法確認時向 SDK 供應方查證。
- 若檔案存在但所在 bundle 不符合產品類型，依 Apple 文件調整來源與打包方式，不要把其他產品的路徑照搬過來。
- 若語法檢查失敗，先修正 plist 格式；若語法通過但 Apple 仍指出內容問題，按診斷核對鍵值、資料使用聲明與 required-reason API 理由。
- 若本機與遠端 Mac 結果不同，先固定提交、Xcode、Scheme 和依賴解析結果，再比較兩邊的 Archive 證據。
遠端 Mac 能提供可重現的 macOS 歸檔環境，但不能替你判斷清單是否準確，也不能取代最終產物驗收。當本地機器與 CI 的環境差異難以控制，除了檢視建置節點的方案，也可先參考 Mac mini 伺服器方案的成本項目及裸機 macOS 方案說明，再按使用期間與維運責任選擇。
如果目前方案依賴工程師手動維持本機環境、CI 與開發機的依賴版本容易漂移，或故障時缺少可重跑的 macOS 節點，使用 MacDate 租用遠端 Mac 可讓你另設專用歸檔環境，再以提交、依賴與產物證據完成驗收。若你只偶爾建置，先比較租用與現有方案；若需要長期固定負載或實體介面，則應一併評估自購 Mac。需要臨時或階段性建置節點時，可查看 MacDate 遠端 Mac 節點選項。