Apple 的 TN3181 無效隱私清單排查說明指出，相關通知可能提供出錯檔名及 Archive 內的路徑。本週先按這條路徑定位 PrivacyInfo.xcprivacy，判斷它屬於 App 主目標、Swift Package 還是第三方 SDK，再回到來源修正、重新封存並驗證；不要不分來源地刪除或覆蓋清單。
這篇適合收到 App Store Connect 隱私清單無效通知、需要確認檔案位置的獨立開發者。
如果你正在整合第三方 SDK，或要在遠端 Mac 上建立可複核的提交驗收流程，以下步驟也能幫你避免修錯目標。
先從錯誤路徑辨認清單來源
錯誤通知的路徑是排查入口，不是單純的錯誤描述。先記錄檔名和完整路徑，再到本次提交所使用的 Xcode Archive 中比對。Apple 說明無效隱私清單會導致提交遭拒；不要把它和 App Store Connect 的隱私標籤混為一談。兩者檢查的內容不同，處理方式也不同。
Apple 的隱私清單檔案布局說明可用來核對清單在 App 或套件產物中的位置。判斷時，請追到錯誤路徑實際落在哪個 bundle，而不是只看專案導覽器裡有沒有同名檔案。
可以先整理這些證據：
- 通知中的檔名、路徑和驗證結果。
- Archive 的建置版本，以及它是否就是準備提交的那份。
- 路徑所屬的 App、套件或 SDK 名稱。
- 對應 target、Package.swift 或依賴版本資訊。
提醒：原始碼內有清單，不等於 Archive 一定包含清單。反過來說，Archive 中存在同名檔案，也不代表它的鍵和值符合 Apple 規則。
App 主目標：檢查檔案是否進入正確的建置產物
如果路徑指向 App 本身，先分開處理兩種聲明：App 對受管 API 的使用，以及 App 收集的資料。它們有各自的欄位與判斷依據，不應把 SDK 的內容全部貼進 App 清單，或為了讓驗證通過而填入未確認的聲明。
在 Xcode 專案中確認 PrivacyInfo.xcprivacy 是否加入實際建置的 App target，並檢查檔案是否按預期複製到產物。Apple 的隱私清單新增指南說明如何將清單加入 App 或第三方 SDK；完成設定後，仍要以 Archive 內的檔案位置作最後確認。
再逐項核對清單原文。資料收集聲明依據實際資料用途填寫，可參考 Apple 的隱私清單資料使用說明。不要因為通知提到隱私清單，就順手修改 App Store Connect 的隱私標籤；先確認錯誤路徑確實指向哪份檔案。
Swift Package：把資源設定納入檢查
Swift Package 的常見落差是：套件原始碼裡看得到 PrivacyInfo.xcprivacy，Archive 中卻沒有對應資源。原因可能是檔案沒有列入套件 target 的資源設定；單靠檔案所在資料夾，不能推定它會自動打包。
檢查 Package.swift 中目標的 resources 設定，確認清單作為資源納入正確的 target。Apple 的Swift Package 資源打包說明介紹資源的宣告方式。設定調整後，重新建置並在新 Archive 中確認實際位置；不要以套件目錄中的檔案取代封存產物驗收。
若套件由其他團隊維護，還要比對目前使用的套件版本。修正本地資源設定前，確認清單確實屬於該套件，避免同時改動 App 主目標和依賴內容，讓錯誤來源變得更難追蹤。
第三方 SDK：依賴內的錯誤不等於 App 清單錯誤
當通知路徑落在 framework 或 XCFramework 內，先記下 SDK 名稱與版本，並確認它是直接依賴還是由另一個套件帶入。接著查看 SDK 發布者提供的清單與版本說明，判斷是否已有修正版。若清單由 SDK 提供，應優先向發布者確認處理方式，而不是把 SDK 的聲明搬到 App 主清單。
Apple 的清單新增指南同時涵蓋 App 與第三方 SDK。實際修復仍要依錯誤檔案的歸屬決定：主 App 的檔案回到 App 專案處理；SDK 內的檔案則核對 SDK 版本及發布者提供的修正。單一 SDK 的問題不代表所有 App 都會遇到同一狀況。
遇到清單無效時，也不要只憑錯誤文字猜測原因。用通知路徑、Archive 內檔案與依賴版本逐一對照，並保存對應資料，方便與 SDK 發布者確認。
清單存在仍無效：核對鍵、值與使用理由
如果路徑正確、檔案也在 Archive 中，下一步才是檢查格式和內容。Apple 的TN3181列出無效清單的排查方向；逐項比對實際清單與通知指出的問題，不要為了消除錯誤而任意新增欄位。
特別要分清資料收集聲明和 Required Reason API 聲明。後者要依 App 或 SDK 實際使用的 API，對照 Apple 當前列出的允許理由；Apple 的Required Reason API 說明提供適用 API 與理由資訊。沒有使用證據時，不要自行挑選理由代碼；如果錯誤來自第三方依賴，應一併核對發布者提供的版本資料。
把目前提交所用清單原文、通知內容和對照結果保留下來。這樣你能指出是哪個鍵或值未通過驗證，而不是只記錄「改過隱私清單」。
建立新 Archive，再完成提交前驗證
來源修正後，重新建置並產生新的 Xcode Archive。打開 Organizer，選取這次要提交的封存檔，按通知中的路徑重新定位清單。確認檔案內容與修正一致，再執行 Xcode 的提交流程與驗證。Apple 的Xcode 發佈與 Archive 說明可供核對封存及分發步驟。
不要把舊 Archive、目前原始碼和新驗證結果混在一起。建議建立一份簡短紀錄，列出建置版本、使用的依賴版本、清單所在路徑、修正內容及驗證結果。若提交問題牽涉封存包內檔案，避免直接修改或移除；Apple 的程式碼簽章說明指出簽章與封裝內容有關。需要任何例外處理時，先依 Apple 對重新簽署的說明評估，不要把直接改包當成一般修復步驟。
提交前可勾選的驗收清單
- [ ] 已從通知記錄完整檔名與 Archive 路徑。
- [ ] 已在本次提交所用的 Archive 中找到同一份清單。
- [ ] 已確認檔案屬於 App target、Swift Package 或第三方 SDK。
- [ ] 已依清單來源核對 target、套件資源設定或 SDK 版本。
- [ ] 已按 Apple 文件檢查鍵和值，未猜填 Required Reason API 理由。
- [ ] 修正後已建立新 Archive，並對新封存檔執行提交前驗證。
- [ ] 已保留建置、依賴、路徑與驗證結果的對照紀錄。
依錯誤來源選擇修復路徑
| 通知指向的位置 | 優先檢查項目 | 修復後的驗收依據 |
|---|---|---|
| App bundle | App target、清單內容及產物位置 | 新 Archive 中的清單與 App 專案設定一致 |
| Swift Package 產物 | Package.swift 的 target 資源設定 |
套件資源確實出現在新 Archive |
| framework 或 XCFramework | SDK 名稱、版本及發布者提供的清單 | 依賴版本與清單修正來源可追溯 |
| 檔案存在但驗證仍失敗 | 無效鍵值、資料用途或 API 理由 | 依 Apple 文件修正後，新 Archive 通過提交前驗證 |
常見問題
錯誤路徑找不到檔案時，是否代表 App 不需要隱私清單？
不一定。先確認你開啟的是通知所指的 Archive，而不是其他建置留下的舊檔案；再比對 App、套件及 SDK 的產物位置。找不到檔案只能說明目前檢查的封存內容與通知路徑不吻合，不能直接推論該元件不需要清單。按 Apple 的清單布局文件確認所屬 bundle，再回頭檢查建置設定。
修正 SDK 清單後，App 主清單也要同步修改嗎？
只有在 App 自身的聲明也有錯誤時才需要修改。SDK 清單和 App 清單屬於不同元件；把 SDK 聲明複製到主清單，不能代替 SDK 本身的修正。先確認通知路徑及清單所有者，再分別處理，並記錄所用的 SDK 版本，避免把依賴問題與 App 自身資料用途混在一起。
清單中的 Required Reason API 理由可以先填一個再測試嗎？
不建議。理由應與實際 API 用途相符，並依 Apple 當前列出的允許理由核對。先確認 App 或 SDK 是否使用該 API，再查閱 Apple 文件；如果來源是第三方 SDK，向發布者確認其清單與版本。猜填理由即使暫時避開某個錯誤，也可能造成聲明與實際用途不一致。
重新歸檔後要保留哪些資料，方便下次複核？
保留通知內容、Archive 對應的建置版本、依賴版本、清單所在路徑、修正前後的差異，以及新 Archive 的提交前驗證結果。這些資料能協助你或 SDK 發布者重現問題，也可避免再次拿錯封存檔。若涉及簽章或封裝檔案，不要只留下手動修改後的結果，應記錄採用的修復步驟與重新驗證情況。
如果你目前靠 Windows 或 Linux 開發、再臨時借用 Mac 驗收，常見代價是無法在原環境重現 Xcode Archive、檔案往返容易對錯版本，而且臨時環境未必保留依賴與驗證紀錄。購買一台 Mac 適合長期、固定且需要本機設備的工作；若只是缺少提交驗收環境，遠端 Mac 可讓你在可連線的 macOS 主機上重新封存並核對結果。你可以先查看 OsxNode 的操作文件了解遠端使用方式；確定需要 Mac 環境時，再評估遠端 Mac 方案。
常見問題
收到無效隱私清單通知後，要從哪裡找出出錯檔案？
先查看 App Store Connect 通知中的檔名與歸檔路徑，再打開本次提交所用的 Xcode Archive，沿路徑確認檔案位於 App bundle、Swift Package 產物，還是某個 framework 或 XCFramework。不要只在原始碼目錄搜尋；通知路徑指向的是提交產物中的位置，舊 Archive 也可能與目前程式碼不同。
Swift Package 裡有 PrivacyInfo.xcprivacy，為什麼 Archive 還是找不到？
檔案放在套件原始碼目錄，不代表它會自動成為套件資源。檢查 Package.swift 中對應 target 的 resources 設定，並確認資源確實被納入該套件的建置產物。接著重建 Archive，按 Apple 文件說明檢查封存內容；若只驗證原始碼檔案是否存在，無法證明提交包內也有該清單。
第三方 SDK 的隱私清單出錯，應該改 App 還是找 SDK 發布者？
先以通知路徑辨認清單所在的 SDK 或 framework，並記下依賴名稱與版本。若錯誤檔案屬於第三方 SDK，先向發布者確認是否有更新且有效的清單或修正版；不要把 SDK 的使用聲明直接複製到 App 主清單，也不要自行改寫 SDK 聲明來掩蓋問題。只有路徑確實指向 App 自身清單時，才回到 App target 修正。
修正 PrivacyInfo.xcprivacy 後，怎樣確認提交的是修好的版本？
完成來源修正後重新執行建置並建立新的 Xcode Archive，不要沿用先前封存檔。透過 Organizer 開啟新 Archive，檢查通知所指路徑上的清單內容，再執行 Xcode 提供的提交前驗證。保留建置版本、依賴版本、Archive 與驗證結果的對應紀錄；不要直接改封存包內的檔案，否則可能破壞程式碼簽章。