公證提交卡在 Windows 或 Linux 流水線，或你不確定發布流程是否一定要有 Mac？
最快判斷：只做公證提交與狀態查詢，可評估 Notary API，免除這部分工作對 macOS 的依賴；若現有流程已在 Mac 上使用 Xcode，先採用 notarytool。這不代表建置、簽名、票據裝訂和交付驗收都能脫離 Mac。本週先按下方里程碑盤點各環節，再決定是否值得改寫 API 整合。
適合維護 macOS App 站外分發、需要提交公證的獨立開發者。
正在評估 Windows 或 Linux 流水線能否負責公證提交的開發者。
也適合管理簽名憑據、發布流程與交付驗收的小型團隊負責人。
SECTION 01 Xcode 公證必須用 Mac 嗎：先釐清工作邊界
公證服務的互動方式不等於完整發布環境。Apple 提供 notarytool 與 Notary API 兩條公證服務路徑；其中 Notary API 可用於跨平台提交、查詢狀態及讀取記錄，但不會替你建置 macOS App，也不會自動完成簽名、票據裝訂或最終產物驗收。Apple 的 Notary API 說明將 API 定位為與公證服務互動的介面；因此選工具時，應先確認是哪個環節需要離開 Mac，而不是把「可以呼叫 API」理解成「整個發布流程都能在非 Mac 上完成」。
對你而言，最重要的區分是：公證提交與狀態查詢可以跨平台規劃；建置、簽名及票據裝訂則要按實際工具與交付要求另外驗證。某一個步驟成功，不代表整個發布物件已準備好供使用者下載。
notarytool 可以在 Windows 或 Linux 上執行嗎？
不要把 notarytool 當成可直接安裝在一般 Windows 或 Linux 主機上的跨平台命令列工具。它屬於 Xcode 命令列工具組；Apple 的安裝說明以 macOS 環境為前提，實際使用時應在 Mac 上執行，或由 Windows／Linux 流水線呼叫可存取的 Mac 執行工作。Apple 的 Xcode 命令列工具安裝文件可用來核對工具與作業環境的關係。
這不代表你的原始碼管理或其他建置任務都要搬到 Mac。你可以讓非 Mac 主機負責一般工作，再把需要 notarytool 的環節交給 Mac；代價是要維護跨主機的檔案傳遞、工作觸發、憑據保管及失敗重試。若團隊已有 Mac 發布主機，通常先沿用現有 notarytool 流程，比另建一套 API 客戶端更直接。
SECTION 02 依發布責任選擇公證路徑
Notary API 能否取代 notarytool 完成 macOS App 公證？
它能替代的是與公證服務互動的部分，不是整個 macOS App 發布工具鏈。Apple 的 API 文件描述了提交軟體、查詢提交狀態及讀取公證記錄等用途；Web 提交流程也說明了如何依 API 要求處理提交與上傳。Notary API 總覽與透過 Web 提交軟體公證的文件應一併閱讀，避免只實作提交，卻漏掉狀態檢查或失敗診斷。
你可以把 API 想成公證服務的通訊入口；它不會把 Windows 或 Linux 變成 Xcode 建置環境，也不會自動替產物完成 Developer ID 簽名。Apple 對 macOS 軟體分發準備的說明，仍將簽名與發布檢查列為需要處理的環節。Apple 的 App 分發準備文件可協助你核對公證前後的責任分界。
已有 Xcode 建置流程，何時才值得改用 Notary API？
若你的發布流程已由 Mac 負責 Xcode 建置、簽名和交付，改寫 API 通常不會消除主要的 Mac 依賴，反而會新增 API 客戶端、認證、錯誤處理及維護成本。Apple 提供 notarytool 的自訂公證工作流程說明，讓你可以把命令列工具接入既有自動化，不必因為想自動化就先假設必須直接呼叫 API。Apple 的自訂公證工作流程文件可用來判斷哪些服務互動可以整合進現有流程。
只有當發布責任確實分布在 Windows 或 Linux、而你想在那些主機上直接管理提交狀態與記錄時，才值得評估 Notary API。評估時也要把「改用 API」的維護範圍算完整：API 認證與私鑰管理、上傳資料的安全傳遞、失敗重試、狀態輪詢、記錄保存，以及後續票據裝訂仍由誰負責。
不在 Mac 上提交公證後，還需要 stapler 嗎？
如果你的交付方式要求把公證票據裝訂到產物上，仍要把 stapler 操作納入發布驗收；Notary API 的提交成功或公證通過，不應被當成票據已裝訂的證明。Apple 的自訂工作流程說明將提交、等待處理與後續裝訂視為需要分別處理的環節。你應以實際交付檔案執行驗證，而不是只看 API 回覆或流水線的綠燈。
這個界線也影響非 Mac 團隊的設計：API 可以處理公證服務端的互動，但若後續步驟要使用 macOS 工具，就得安排可用的 Mac 工作環境，或確認你採用的交付方式不需要該步驟。不要把票據裝訂的責任留在「之後再處理」的人工備註裡。
提醒：將「提交成功」、「公證通過」和「使用者收到的檔案已完成裝訂與驗收」視為不同狀態。流水線應各自留下可查核的結果，才容易定位卡在哪一段。
SECTION 03 發布環境驗證的里程碑
以下不是從建立金鑰開始的逐步公證教學，而是用來檢查你目前的責任分工。先按項目記錄執行環境、產物去向和失敗後的處理人，再決定是否需要更換互動方式。
- 建置責任：確認 macOS App 是在哪個環境建置，以及該環境是否實際提供 Xcode 與專案依賴。若 Windows 或 Linux 只負責編排工作，別把它寫成建置主機。
- 簽名責任：確認簽名發生在哪一台主機、簽名身份由誰管理，以及交接給公證服務前的檔案是否就是預定發布的產物。Apple 的分發準備文件可作為核對簽名與交付要求的官方依據。
- 提交與查詢責任：如果沿用
notarytool，確認它在 Mac 上的觸發方式及結果如何回傳；如果採 Notary API，則確認提交、狀態查詢與記錄讀取都能被流水線追蹤。Notary API 文件列出相關互動範圍。 - 憑據責任：Notary API 流程使用 JWT，並會涉及臨時上傳憑據。把私鑰放在受控的祕密儲存區，限制可讀取的工作與人員；不要把 JWT、私鑰或可重用的上傳憑據寫入建置記錄、錯誤訊息或可公開保存的工件。憑據用途與流程應以Apple 的 Web 提交文件核對。
- 裝訂與交付責任：明確指定由哪個環境執行 stapler，以及誰檢查最終交付檔案。失敗排查可參考Apple 的常見公證問題說明，不要只保存「成功」訊息而遺失診斷所需記錄。
- 重跑驗收：以實際發布產物重跑一次流程，檢查重新提交、讀取結果、裝訂與交付檢查是否都能由指定人員完成。若任一步驟仍需登入另一台未納管的 Mac，架構就尚未真正跨平台。
SECTION 04 依條件作出選擇
- 若建置、簽名與公證都已在 Mac 上完成，且只想自動化現有工作，保留
notarytool，先把觸發、結果保存與失敗診斷接入目前的流水線。 - 若只有公證服務互動必須由 Windows 或 Linux 主機負責，評估 Notary API；同時保留 Mac 或其他合適環境處理需要 macOS 工具的步驟。
- 若團隊只想減少一台 Mac，卻尚未確認建置、簽名和 stapler 的執行位置，先不要把整條發布流程改成 API。先以產物為單位驗證每個環節，再調整主機分工。
- 若 API 私鑰無法安全管理、上傳與狀態記錄無法追蹤，回退到受控 Mac 上的
notarytool流程，直到憑據管理和稽核方式就緒。
下表把工具選擇與環境責任分開；它不是「哪個工具功能較多」的排名，而是判斷你的現有發布鏈路要承擔哪些工作。
| 比較項目 | notarytool |
Notary API |
|---|---|---|
| 適合的主要場景 | 已在 Mac 上建置或簽名，想整合公證提交 | 非 Mac 流水線需要直接與公證服務互動 |
| 執行環境考量 | 依賴 macOS 上的 Xcode 命令列工具 | 可讓公證服務互動不依賴 macOS |
| 流程整合方式 | 透過命令列接入現有自動化 | 由團隊維護 API 呼叫與狀態處理 |
| 建置與簽名 | 不會替你省略這些發布責任 | 同樣不會提供 Mac 建置能力或自動完成簽名 |
| 後續工作 | 仍須按交付要求檢查票據裝訂與產物 | 仍須按交付要求安排裝訂與產物驗收 |
| 維護重點 | Mac 工具鏈、工作觸發與結果保存 | JWT、私鑰、臨時上傳憑據、錯誤處理與稽核 |
再用以下交付檢查表確認流程是否閉環：
| 驗收項目 | 可接受的結果 |
|---|---|
| 建置與簽名位置 | 有明確主機與負責人，產物來源可追溯 |
| 公證提交與處理結果 | 能保存提交狀態及診斷記錄，不只看工作是否成功 |
| 憑據處理 | 私鑰與臨時上傳憑據不出現在一般工作記錄 |
| 票據裝訂 | 已確認是否需要，並指定可執行該步驟的環境 |
| 最終交付 | 驗收對象是實際交付檔案，而非單一 API 回應 |
如果你目前依靠 Windows 或 Linux 端的零散腳本，常見代價是跨主機交接難追蹤、macOS 專屬步驟要另找環境，以及公證通過後仍可能漏掉裝訂或產物驗收。若你需要把建置、簽名或 stapler 等確實依賴 macOS 工具的工作集中在可存取的 Mac 上，可先閱讀 VPSNIX 的 Mac 使用說明，再依工作週期比較遠端 Mac 方案與租用方式。遠端租用不是公證的唯一解法：已有合適 Mac、長期固定負載或必須使用本機實體介面的團隊，可能更適合自有設備；若只是需要臨時發布環境或補上特定 macOS 工具步驟，租用 Mac 則能避免為單一環節先購置硬體。