macOS App 公證不等於整條發布流程都必須在 Mac 上完成。本文依照制品準備、Developer ID 簽名、公證提交、票據裝訂與最終驗證的時間線，判斷哪些工作可放在 Linux CI，哪些工作仍應交給真實 Mac，並提供混合部署的驗收條件。
macOS App 公證不等於整條發布流程都必須在 Mac 上完成。本文依照制品準備、Developer ID 簽名、公證提交、票據裝訂與最終驗證的時間線，判斷哪些工作可放在 Linux CI，哪些工作仍應交給真實 Mac，並提供混合部署的驗收條件。
症狀： Linux CI 可以把檔案送到公證服務，但這不代表它能獨立完成 macOS 軟體的建置、簽名、票據裝訂與最終驗證。
最快解法： 只做提交與查詢時可評估 Apple Notary API；只要涉及 Xcode 建置、Developer ID 簽名、stapler 或本機驗證，就保留真實 Mac，通常採用通用 CI 編排加遠端 Mac CI 的混合方案。
這篇文章適合以 Linux CI 為主、準備增加 macOS 軟體發布能力的平台工程師；也適合要把簽名、公證和制品分發改成無人值守流程的 macOS 開發者，以及正在判斷長期租用或按需使用遠端 Mac 的技術負責人。
「公證」不是單一上傳動作。完整發布鏈路至少要分成制品生成、簽名、公證提交、狀態查詢、票據裝訂與最終驗證。Apple 的公證流程文件也把簽名、提交及分發前檢查視為不同責任，不能因為 API 能接受上傳，就推論 Linux 能取代整台 Mac。Apple 公證流程說明
對團隊而言，最重要的判斷不是「能否呼叫公證服務」，而是交付物在每一站是否仍然可被下一站正確使用：
| 階段 | 主要輸入與輸出 | 通用 CI 可負責的部分 | 是否建議保留真實 Mac |
|---|---|---|---|
| 制品生成 | 原始碼、Xcode 工程、待簽名 App 或封裝檔 | 編排、測試、制品傳遞 | 涉及 Xcode 或 macOS 專屬封裝時，建議使用 |
| Developer ID 簽名 | 待簽名 App、權限設定、簽名身份 | 觸發任務與保存結果 | 是，尤其涉及鑰匙圈與巢狀程式碼 |
| 公證提交 | 已簽名且符合格式的制品 | 可透過 API 提交、查詢、保存日誌 | 不一定；API 路徑可由非 macOS 節點評估 |
| 票據裝訂 | 公證成功的最終制品 | 傳遞檔案與重試 | 需要 Apple 命令列工具時，應使用 |
| 最終驗證 | 實際要交付的 App、安裝包或磁碟映像 | 保存驗收結果 | 建議使用 Mac 執行本機驗證 |
這張表的核心限制很清楚：Linux 可以成為編排中心，但不應自動被視為 macOS 發布節點。
如果輸入是 Xcode 工程，建置階段通常要處理 macOS SDK、Apple 工具鏈、簽名設定，以及工程內可能存在的腳本或原生相依套件。此時，遠端 Mac 不只是「把檔案上傳給 Apple」的跳板，而是產生可重複制品的建置節點。
驗收時不要只看 CI 工作是否顯示成功，而要保存一份可重新取得的待簽名或待提交制品，並記下其雜湊值、建置提交版本與產出格式。Apple 對 Mac 軟體封裝格式及分發準備有獨立說明，團隊應按照實際 App、安裝包或磁碟映像類型逐項核對。Apple Mac 軟體封裝文件
若制品已由其他可信任的 Mac 建立，Linux CI 可以負責保存、傳遞及觸發後續流程；但這是「已有合格輸入」的例外，不是 Linux 能自行取代 Xcode 建置環境的證明。
公證不會替制品補上 Developer ID 簽名。流水線必須先確認主程式、嵌套框架、Helper、外掛及其他巢狀程式碼的簽名狀態，並檢查權限設定是否與實際分發方式一致。Apple 的分發簽名說明可作為簽名責任的基準。Apple 分發簽名程式碼說明
建議把簽名節點分成三種方案比較：
最低驗收證據應包含簽名驗證結果、實際執行帳戶，以及鑰匙圈存取狀態。帳戶名稱、Team ID、密鑰、憑證名稱與路徑都應使用 CI 的秘密變數或占位符保存，避免把可識別憑據寫入日誌。
提醒： 公證提交成功只代表服務端接受了某個制品的處理請求，不代表簽名層級、分發封裝、票據裝訂或使用者端啟動條件已全部通過。
已有 Mac 節點、希望快速接入既有 Shell 或 Xcode 流程時，可以先評估 notarytool。它適合由 Mac 節點直接提交制品、等待結果並取得公證日誌；實際參數與認證方式仍應以寫作時的 Apple 技術說明為準，而不是沿用社群腳本中的舊參數。
如果團隊的主要編排節點是 Linux，且希望在不啟動圖形化 Mac 工作階段的情況下完成提交和查詢，則可評估 Apple Notary API。Apple 官方文件列出提交制品及取得提交日誌的介面，這使非 macOS 節點可以承擔服務端互動，但不會因此取得 codesign、stapler 或 Xcode 的本機能力。Apple Notary API 概覽 提交軟體介面 取得公證日誌介面
Linux CI 中可以完成哪一段？
若輸入已是合格的已簽名制品，Linux CI 可以負責封裝傳遞、呼叫 Apple Notary API、輪詢結果、保存提交識別資料與公證日誌。若還要從原始碼建置、處理 Developer ID 簽名、執行票據裝訂或做 Mac 本機驗證，則應把相應工作移到遠端 Mac。
因此，notarytool 與 Apple Notary API 不是簡單的優劣關係，而是執行位置的選擇：前者偏向 Mac 節點內的工具鏈整合，後者偏向通用 CI 的服務端編排。兩條路徑都要設計認證保存、狀態等待、日誌留存、失敗重試和人工接管，不能把 API 回應成功當作整條流水線成功。
公證狀態成功後，流水線仍要根據分發格式處理票據裝訂與驗證。能否查詢成功狀態是一回事，能否把票據附加到最後要交付的 App 或封裝檔，又是另一回事。這也是完整 macOS 發布流程通常仍需真實 Mac 的主要原因之一。
應將驗收對象固定為最終分發檔，而非中間歸檔或暫存壓縮檔。建議依序保存：
其中第 3 項可以由通用 CI 透過 API 保存；第 4、5 項若依賴 Apple 命令列工具，則應在 Mac 節點完成。Apple 也提供自訂公證工作流的說明，可用來核對提交、查詢及後續處理的責任邊界。Apple 自訂公證工作流
公證失敗時怎樣退出？
先保留提交識別資料與服務端日誌，不要直接刪除制品或無限重試。若失敗原因涉及格式、簽名或封裝，回到對應階段修正；若只是暫時性傳輸或編排錯誤，才由 CI 執行受控重試。這樣才能區分「服務端拒絕制品」與「流水線沒有正確保存狀態」。
第一次落地時，建議使用一次完整的雙節點試運行：通用 CI 負責原始碼觸發、任務編排、制品傳遞與結果留存；遠端 Mac 負責需要 macOS 工具鏈的建置、簽名、票據裝訂及本機驗證。試運行不應只測一次成功提交，還要測試制品傳遞中斷、Mac 重啟、任務重試、秘密變數隔離，以及人工接管入口。
可按以下條件作出部署判斷：
stapler 處理或 Mac 本機驗證，則選專用遠端 Mac；不要把這些工作包裝成 Linux API 任務。對正在評估硬體與維運成本的團隊，VNCMac 的遠端 Mac 方案可以先作為隔離試運行節點；先以真實制品完成簽名、公證、裝訂及驗證，再決定是否需要長期保留。若需求已經確定是固定團隊自有設備，也可同步比較Mac 租用與購置選項，但不要在尚未驗證重啟恢復與憑據隔離前，直接把節點定義為生產環境。
如果目前方案是純 Linux CI，常見缺點是無法自然承接 Xcode 建置、Developer ID 簽名及票據裝訂，最後還要以人工 Mac 補尾；如果改用共享 Mac，則容易遇到鑰匙圈狀態、執行帳戶和併行任務互相污染；若只依賴服務端提交，則仍缺少最終分發檔的本機驗證。對需要臨時發布節點或正在試驗遠端 Mac CI 的團隊，先租用 VNCMac 的真實 Mac 做完整閉環，通常比立即購置硬體或維持一套未驗證的混合架構更容易控制風險；但長期高頻重負載、必須接觸實體周邊或需要固定本地網路的團隊，仍應先評估自購 Mac 是否更合適。