Apple notarytool 企業 CI 怎麼搭？2026 部署指南

症狀：CI 顯示上傳完成，發布工作卻仍不知道公證是否通過、交付檔能否放行。

最快解法：Apple notarytool 企業 CI 應把建置與簽署、公證提交、狀態檢查、票據處理及最終驗收拆成可追溯步驟；需要 Xcode 或 stapler 的階段在 macOS 驗證，Notary API 只替代部分提交與查詢操作。

本週建議動作：先選一個實際發布產物跑完這條流程，保存每步的輸入、輸出與負責人，再決定要不要調整現有 Mac CI。

適合負責 Mac App Store 外發布、需要採用 Developer ID 與公證的團隊。
也適合負責 CI 平台與憑證治理、要界定簽署和認證權限的 IT 團隊。
如果你負責發布驗收，本文可用來核對公證結果、日誌、票據與最後交付檔。

Apple notarytool 企業 CI：先界定產物與公證範圍

Apple 公證適用於 Mac App Store 外分發的 macOS 軟體；Mac App Store 的上架流程不是同一條公證路徑。先確認你要交付的是應用程式、安裝套件，還是磁碟映像，再把該格式的實際發布檔列為檢查對象。Apple 對公證流程及 Developer ID 分發的說明，分別見公證與發布指引及 Developer ID 文件。

第一步先定義放行物件：不是某次 CI 工作「成功」，而是能追溯到程式碼版本、建置任務、簽署身分與匯出檔的發布產物。Apple 說明可使用 notarytool 自訂公證流程，並檢查提交狀態及日誌；這些檢查不會代替團隊自己設定的放行門檻。自訂公證工作流程文件

準備階段也要確認工具邊界：若要建置或使用 Apple 的 macOS 工具，就不能只因考慮 Notary API，便假設整條發布流程可脫離 Mac。你可以先把目前的企業 Mac 基礎設施資料納入環境盤點，但實際承載能力仍要以自己的流程驗證。

簽署階段：讓產物有完整的追溯鏈

把正式發布要用的產物送進檢查流程。以 Apple 文件界定簽署條件，並確認產物採用適用的 Developer ID 簽署方式、啟用 Hardened Runtime，以及簽署所需的時間戳設定；Hardened Runtime 的配置應對照 Apple 說明，不要只根據專案範本或開發版設定推定已符合發布條件。

簽署與建置紀錄至少要能相互核對：程式碼提交版本、CI 工作識別、簽署身分，以及匯出的發布檔。若開發版簽署和正式分發所需條件不同，就不能因開發測試成功而省略發布檔檢查；你應以實際要分發的產物進行公證與驗收。

提醒：Xcode Organizer 可供手動操作或檢視發布流程；腳本化 CI 則應把檢查結果與輸出檔留在可追溯紀錄中。選哪條路徑，應看團隊是否需要自動重跑、審計及明確的放行條件，而不是把操作介面和自動化能力視為同一件事。

認證與提交：隔離憑證，再保存 submission ID

公證憑證不要直接寫進 CI 腳本、程式碼庫或會長期保存的建置產物。按團隊採用的認證方式配置憑證，限制只有需要提交或查詢公證的工作可以讀取；把建立者、權限審核者與輪換負責人寫進內部作業規範，並檢查工作日誌有沒有輸出敏感值。若使用 App Store Connect API 金鑰，金鑰建立與權限應依照 Apple 的 API 金鑰文件確認，不要把不同認證路徑混成一種設定。

提交時使用符合公證流程的實際歸檔或容器，保存 Apple 回傳的 submission ID，後續以該識別碼查詢狀態和日誌。xcrun notarytool submit 負責提交；帶有 --wait 的命令可等待結果，但流水線仍應把最終狀態記為獨立檢查項，而非將「上傳完成」視為公證完成。Apple 的自訂流程文件及 Notary API 提交流程說明可用來核對相應操作。

評分是依自動化與流程追溯需求所作的部署判斷，不是 Apple 對工具的官方排名。Apple 提供的 Notary API 提交說明與網頁提交文件列出 API 對應的提交方式；採 API 前，應照文件確認認證與回應處理，不能推論它會代替 Xcode 建置或 Mac 上的簽署工作。

流程疑問：依症狀查對應步驟

Apple notarytool 怎樣接入 macOS CI？
讓 macOS CI 先產出已簽署的正式交付檔，再提交、保存 submission ID，並以狀態及日誌結果決定是否繼續。最後將適用的票據處理和交付檔檢查納入放行條件。

CI 裡的公證憑證怎樣保存才安全？
由 CI 機密管理機制提供憑證，只授權需要提交或查詢的工作讀取；不要將憑證硬編碼到腳本。定期檢視執行權限、日誌輸出及憑證輪換責任，避免認證資料隨建置紀錄外流。

狀態顯示 Invalid 時，應先檢查哪些紀錄？
依 submission ID 取得 Apple 回傳的日誌，定位失敗項目，再核對實際產物的簽署和 Hardened Runtime 設定。保留日誌、建置版本和簽署身分，讓排查結果能連回該次發布，而不是只保留 CI 的錯誤摘要。

公證獲接受後，還要不要用 stapler？
依交付格式判斷。Apple 的工作流程文件說明票據處理與支援邊界；ZIP 不能直接 stapling，不能將「公證獲接受」當成所有格式都已完成票據處理。

Notary API 能完全取代 Mac CI 中的 notarytool 嗎？
不能據此推論整條 Mac CI 可以取消。Notary API 可處理部分提交和狀態查詢；凡是依賴 Xcode 建置、簽署或 stapler 的步驟，仍須在相應的 macOS 環境驗證。

驗收階段：讀取日誌，處理票據並檢查交付檔

狀態獲接受後，再核對 Apple 回傳的公證日誌是否與該次 submission ID、建置版本及發布檔相符。若結果失敗，保留 submission ID、原始日誌、建置識別、簽署身分與被提交的檔案資訊；這些紀錄才能協助你判斷問題落在簽署、產物內容，還是提交過程。

票據操作要按格式處理，而不是對每一種壓縮檔都執行同一命令。Apple 說明可對適用產物使用 stapler；ZIP 檔本身不能直接 stapling。對適用的交付物執行 stapling 後，仍要驗證票據及最終檔案，並確認驗收所檢查的正是實際分發物。

放行前：依實際工作決定 Mac CI 承載方式

若建置或簽署依賴 Xcode，或交付流程需要在 macOS 上執行 stapler，就把這些步驟放在經驗證的 Mac 環境中；否則也要先確認是否仍有其他 macOS 工具或產物驗收依賴，不能只因提交和查詢採用 Notary API，就移除 Mac 環境。

若現有流程需要把提交與狀態查詢納入腳本，且團隊能治理 API 認證、回應及紀錄，就評估 Notary API；否則先以 notarytool 完成可追溯的命令列流程，再決定是否替換部分操作。

若發布檔、submission ID、日誌、票據和責任人都能對上，才把這次流程視為完成驗收；若有任何一項缺失，就**先補齊證據，而不是只依賴 CI 綠燈放行。

遠端 Mac 是否適合承載其中的建置或簽署工作，要以實際交付資料、權限設計及完整流程測試判斷；本文不對安全性、效能或服務能力作未驗證承諾。你可先查閱 VPSMAC 技術支援資料與租賃價格頁面，再按可核實的交付條件評估。

若目前用個人 Mac 分散建置，可能遇到環境不一致、簽署權限分散及發布紀錄難以集中核對；若改用一般雲端伺服器，也不能因此假設它能執行依賴 macOS 或 Xcode 的步驟。需要額外 Mac CI 環境時，租賃真實 Mac 可作為評估選項，但按需租用不會自動解決憑證隔離或放行治理。先列出哪些工作必須使用 Xcode、notarytool 或 stapler，再對照 VPSMAC 可核實的交付資料；若環境符合你的流程，才進一步評估按需租用。