Apple 將「Missing Compliance」列為構建缺少出口合規資訊的狀態，並提供問卷與材料關聯流程。Apple 的構建狀態說明可核對這項定義。
症狀 → 最快解法： 構建已上傳但 TestFlight 顯示 Missing Compliance → 先盤點完整 App 的加密來源，再走「通常無需材料、需要進一步判斷、需要提交材料」三路判斷；確認屬於豁免範圍後，才在最終構建的 Info.plist 配置 ITSAppUsesNonExemptEncryption。
誰該看這篇：
如果你上傳 TestFlight 構建後無法繼續分發，或使用 HTTPS、Keychain、登入 SDK、支付 SDK、端對端加密功能卻不知道如何申報，這篇適合你。
如果你透過遠端 Mac 或持續整合反覆上傳，也可以把文中的盤點與驗收步驟納入發布流程；它不是把問卷當成簽名錯誤或單純上傳失敗來處理。
SECTION 01先確認 Missing Compliance 的真正範圍
Missing Compliance 針對的是這個已上傳構建的出口合規資訊不完整，不是 Invalid Binary、簽名失敗，也不等於 Apple 仍在後台處理構建。先到 App Store Connect 的構建詳情查看狀態，再進入 TestFlight 的出口合規處理區域；Apple 的測試版構建合規流程說明了問卷回答與已批准材料的關聯方式。
不要只搜尋業務程式碼裡有沒有 AES 或 RSA。申報對象是上傳的完整 App，盤點範圍至少包括：
- 你自行撰寫的加密、通訊協定與安全儲存程式碼；
- Apple 作業系統提供的網路、Keychain 或其他安全 API；
- 靜態連結與動態連結的二進位檔；
- 登入、支付、分析、推播、通訊及端對端加密 SDK；
- SDK 內實際打包、啟用或由條件編譯帶入的加密功能。
你可以先建立一份依版本保存的依賴清單，欄位包括 SDK 名稱、版本、二進位檔來源、是否包含自行實作的標準演算法、實際啟用功能與分發地區。再保存問卷答案截圖、供應商技術文件及最終 Archive 的檢查紀錄。這些資料不是用來取代 Apple 或主管機關的判定，而是避免下一次上傳時重新猜測。
如果你需要先確認遠端 Mac 的存取與發布環境是否適合這類驗收，可參考 MACNOX 的遠端 Mac 使用入口，再把帳號權限、構建產物與合規紀錄分開管理。
SECTION 02系統加密能力與一般工具 App
只有 HTTPS 和 Keychain，通常怎樣處理？
若 App 只透過 Apple 系統提供的網路安全能力連線，或使用 Keychain 等作業系統安全功能，而沒有額外嵌入系統外的加密演算法，通常可按 Apple 的出口合規問卷判斷為不需要上傳出口合規文件。這裡的關鍵是「只使用系統能力」，而不是看到 HTTPS 就直接選擇某個答案。
例如，一個一般工具 App 可能使用系統網路框架建立 HTTPS 連線，並用 Keychain 保存登入憑證。這種情況與把 OpenSSL、加密通訊函式庫或自研安全通訊協定打包進 App 不同；兩者不能因為都出現「登入」或「HTTPS」而歸為同一類。Apple 對加密出口規則的官方說明應作為問卷判斷的起點。
你的申報結論應同時有三項證據：
- 專案依賴清單沒有系統外的加密實作，或已確認相關功能未被打包；
- 最終二進位檔與第三方 SDK 文件沒有顯示額外的標準或非標準加密能力；
- 問卷答案、版本號與構建識別資料已留存，之後可以對應到同一個 Archive。
這並不代表可以把 ITSAppUsesNonExemptEncryption 隨意設成 NO。如果你只檢查 Swift 或 Objective-C 業務程式碼，卻漏看動態函式庫，下一個構建仍可能再次出現問詢。
SECTION 03第三方標準加密與安全 SDK
第三方登入或支付 SDK 使用加密時，要看哪些材料？
第三方 SDK 自行包含標準加密實作時，不能因為你的業務程式碼沒有直接呼叫演算法，就自動選擇豁免。你需要向 SDK 供應方確認二進位檔組成、實際啟用的功能、使用的演算法類型，以及 SDK 是否只是呼叫 Apple API，還是把自己的加密函式庫一併帶入。
支付 SDK 可能需要保護交易資料，登入 SDK 可能建立安全通道；但「有安全功能」本身不足以決定問卷答案。以下表格把應採取的路線分開：
| 加密來源情況 | 主要識別證據 | 問卷與材料方向 | 構建驗收方式 |
|---|---|---|---|
| 只使用 Apple 系統加密能力 | 原始碼、依賴清單與二進位檢查均未發現額外實作 | 依問卷確認豁免範圍，通常不需上傳出口合規文件 | 檢查最終 Info.plist，重新上傳後確認不再重複要求相同資訊 |
| 第三方 SDK 內含標準加密 | 供應商文件、二進位組成及實際啟用功能顯示系統外實作 | 不能只憑「未直接呼叫」判斷，依問卷結果準備相應資料 | 以同一版本的 Archive、上傳紀錄及 TestFlight 狀態交叉核對 |
| 自研協定或非標準演算法 | 自研安全通訊、特殊演算法或主要安全產品功能 | 先準備正式分類、聲明或其他主管機關要求的材料 | 等待材料審核或批准後，再將批准資訊關聯至構建 |
| 主要提供安全通訊或安全儲存 | App 的核心功能本身就是加密服務 | 不應用修改 plist 的方式繞過問卷，需按實際功能判斷 | 將問卷、批准材料、構建版本與分發地區一起留檔 |
美國出口管制的分類與豁免不能由一般技術文章代替法律意見；涉及分類時，應核對美國 BIS 的加密常見問題資料。如果 App 在法國分發，也不要把美國問卷答案當成法國程序已完成。法國主管機關對密碼學工具的監管說明需要按你的功能、角色與分發方式另行復核。
注意： CCATS、法國加密聲明，以及 Apple 審核可能要求的程式碼或說明，解決的是不同層次的問題。它們不能互相替代；有疑義時，應諮詢具備出口管制經驗的專業人士，而不是用
Info.plist改值掩蓋不確定性。
SECTION 04自研加密與非標準演算法
什麼情況下不應只修改 Info.plist？
如果你自行設計了未被公認標準組織採納的演算法、自研安全通訊協定，或 App 的主要賣點就是安全通訊、安全儲存、檔案加密，應先準備正式分類或申報材料，再處理構建設定。修改 Info.plist 只能表達你對構建加密狀態的配置，不能把實際存在的加密功能變成不存在。
Apple 的出口合規總覽可用來確認 App Store Connect 的材料關聯與問卷入口；至於是否屬於某個國家或地區的豁免，仍要依實際功能、分發地區與適用規則判斷。
你可以將這類專案拆成四份文件：
- 功能說明： 加密保護什麼資料、在哪個流程啟用、使用者能否自行控制；
- 技術說明： 演算法、協定、函式庫來源及是否為自研；
- 分發範圍： App Store、TestFlight、企業部署與各地區分發的差異；
- 申報狀態： Apple 問卷結果、主管機關材料、批准代碼及適用版本。
這種分類方式也能避免把「申報完成」誤寫成「法律上所有地區都已獲准」。Apple 的問卷結果只處理其平台流程；BIS 或法國主管機關的要求，仍需依其規範個別確認。
SECTION 05Info.plist、TestFlight 與新構建驗收
ITSAppUsesNonExemptEncryption 要設定為 YES 還是 NO？
這個鍵的選擇取決於 App 是否使用 Apple 定義範圍外的加密，而不是取決於你是否使用了 HTTPS。Apple 的ITSAppUsesNonExemptEncryption 鍵說明可用來核對鍵名與其用途。
| 最終構建中的設定 | 代表的申報意思 | 你應採取的動作 |
|---|---|---|
NO |
你已確認 App 不使用需要額外申報的非豁免加密 | 保存盤點證據，重新 Archive 並上傳新構建 |
YES |
App 使用了需要進一步判斷或申報的加密能力 | 先完成問卷與材料判定，不要只依賴 plist 消除提示 |
| 未配置 | App Store Connect 可能在構建或 TestFlight 流程中要求你補充合規資訊 | 回到最終產物檢查，確認實際上傳的 plist 是否含有正確值 |
如果你的專案已取得 Apple 可接受的出口合規批准代碼，ITSEncryptionExportComplianceCode 可用於把批准資訊帶入構建配置；它不是把未知加密功能標成豁免的捷徑。代碼、帳號識別資料與內部 SDK 名稱不應出現在公開截圖或遠端終端機紀錄中。
為什麼配置了 Info.plist，新構建仍然要求填寫？
最常見的原因不是 App Store Connect「沒有讀到」設定，而是你檢查的是專案原始設定，不是實際上傳的 Archive。Xcode 的 Build Settings、不同 Target、環境變數、加工腳本或重新簽名流程，都可能讓最終產物與原始設定不一致。
請按以下順序處理：
- 鎖定失敗構建： 記下版本號、構建號與 App Store Connect 顯示的狀態，不要只看本地 Xcode 訊息。
- 盤點完整依賴： 檢查 App 自有程式碼、系統 API、靜態庫、動態庫與第三方 SDK，確認是否有系統外加密。
- 檢查 Archive： 在
.xcarchive的最終 App 產物中查看實際Info.plist，不要只看專案編輯器或某個 Target 的設定。 - 確認鍵值與 Target： 檢查
ITSAppUsesNonExemptEncryption的布林值是否套用到上傳的 App Target；若有批准代碼，也核對其對應版本與材料。 - 重新 Archive： 修改後必須產生新的 Archive，不要重複上傳舊的
.ipa或舊 Archive。 - 重新上傳： 依Apple 的構建上傳說明完成上傳，保存上傳工具輸出的脫敏紀錄。
- 核對 TestFlight： 進入新構建的合規區域，確認是問卷人工處理、配置後不再重複問詢，或仍須等待材料審核。
即使配置正確，新構建也不會替舊構建自動補上資料。你必須以新 Archive 對應新上傳紀錄，再判斷 TestFlight 是否可以繼續分發。若只是想確認狀態變化，也不要把「上傳成功」誤認為「合規已完成」；兩者在 App Store Connect 中是不同的驗收點。
Missing Compliance 後，TestFlight 還能否讓內部測試者安裝？
通常不能把缺少出口合規資訊的構建直接當成可正常分發的 TestFlight 版本。你應先在構建詳情中完成問卷、關聯已批准材料，或按照實際情況補上正確配置，再確認構建是否進入可測試狀態。內部測試權限、簽名成功與出口合規完成是三件不同的事，不能互相替代。
SECTION 06遠端發布環境的安全收尾
當你在遠端 Mac、CI 或持續在線的打包機上處理合規資訊，驗收不應只看瀏覽器裡的綠色狀態。至少要保存以下四類脫敏紀錄：
- 依賴清單與 SDK 文件版本；
- 最終 Archive 中的
Info.plist； - 上傳工具與 App Store Connect 的構建狀態；
- TestFlight 合規處理與重新構建後的結果。
三種結論要分開記錄：第一，問卷人工處理即可；第二，確認豁免後可透過構建配置減少重複問詢；第三，必須等待材料審核，不能先以修改 plist 的方式發布。這樣做也能把加密合規與簽名資產、API Key、Bundle ID 的權限檢查分開，降低發布腳本把敏感資料寫入日誌的風險。
如果你不想為了單次合規驗收而購買一台長期閒置的 Mac，可以先比較 MACNOX 的遠端 Mac 方案是否適合你的工作週期；但若你的團隊需要長期高負載、實體 USB 裝置或現場真機除錯，自購硬體可能更直接。遠端方案的優勢在於可按需取得 macOS 與 Xcode 環境，缺點則是依賴遠端連線、需要嚴格管理帳號與憑據，且不能替代所有實體硬體測試。
最後，App Store Connect Missing Compliance 的處理重點不是找到一個能消除提示的欄位，而是讓「實際加密來源、問卷答案、最終 Archive 與 TestFlight 狀態」彼此一致。完成一次脫敏的 Archive、上傳和分發驗收後，再把同樣的檢查納入你的遠端 Mac 發布流程；這比每次看到 Missing Compliance 才臨時猜答案更可靠。