2026 年 macOS 應用公證與 Stapler 完全指南：
在按天租用 Mac 上跑通 notarytool 與分發前檢查清單
需要對外分發 dmg/pkg、或企業內網推送安裝包的開發者，往往卡在「程式碼簽名已做，但 Gatekeeper 仍攔截」——這通常不是 Apple「刁難」，而是未走通公證（Notarization）與裝訂（Staple）鏈路。本文回答三件事：誰適合在按天租用的原生 macOS上完成整條流水線、如何把 開發者 ID、notarytool、stapler 寫成可審計步驟、如何用對照表 + 五條落地步驟 + 三條可引用資料把拒絕原因收斂成可復現 runbook。文內鏈到 臨時簽名與打包指南、按天租用 Mac 完全指南（SSH/VNC） 與 提審與 Xcode 環境，便於你在短期視窗內把「能籤」與「能發」分層處理。
本文目錄
01. 三類痛點：公證視窗、鑰匙串邊界與租用機汙染
1）短期視窗與「半套流水線」：公證需要可用的開發者賬號、本機可登入的 Apple ID 會話、以及穩定的出口；在按天租用場景裡，若只預留了編譯時間卻未預留 15～45 分鐘的公證輪詢與裝訂，很容易出現「包已籤、但使用者下載時仍被攔截」的交付事故。把公證寫進與 臨時簽名同級的檢查表，而不是事後補救。
2）鑰匙串與證書在多人租用機上的串擾：上一任使用者殘留的 login.keychain 或自動匯入的「錯誤開發者 ID」會讓 codesign 看似成功、notarytool 卻在提交階段報 身份不匹配或許可權不足。短期方案建議：為公證任務單獨建立 macOS 使用者目錄，並在任務結束後匯出脫敏日誌而非匯出私鑰材料。
3）網路與代理對公證 API 的影響：企業代理若未放行 Apple 公證端點，會表現為長時間 pending 或直接 TLS 失敗；這與 SSH/VNC FAQ 裡討論的「延遲與頻寬」不同，需要單獨核對出站白名單。
02. 僅簽名 vs 公證：決策邊界與 2026 常見誤區
對 macOS 分發而言，程式碼簽名解決「完整性」，公證解決「Apple 側風險掃描 + Gatekeeper 放行策略」。使用者從網上下載的 dmg/pkg，在未公證時可能被標記為隔離屬性，觸發更嚴格的提示；裝訂後的 ticket 能讓系統分發鏈路更一致。誤區包括：「公證等於上架 Mac App Store」（不需要，公證面向開發者 ID 分發）；「公證可以替代正確的 Hardened Runtime 與 Entitlements」（不能，公證失敗常與沙盒/許可權宣告不一致有關）。若你的目標還包括 iOS 側提審，請把 Xcode 與 SDK 環境與本文 macOS 分發鏈拆開評估，避免混用同一套假設。
在租用機上，建議把 Archive/匯出 與 公證 分成兩個「可驗證里程碑」：先確認 codesign --verify --deep --strict 與 spctl 對本地構建的行為符合預期，再進入 notarytool；這樣拒絕原因更容易定位到「簽名層」還是「公證內容掃描層」。若團隊使用 CI 觸發公證，也要把機器身份（哪臺 Mac、哪個鑰匙串）寫進流水線變數，避免「同一指令碼在本地過、在租用機不過」的隱性漂移。
補充一項在 2026 年仍高頻出現的細節：Hardened Runtime 與 Entitlements 若與實際上網能力、檔案訪問路徑不一致，公證日誌裡可能出現「行為與宣告不匹配」類提示。此時不要急於重傳同一二進位制，應先回到 Xcode 的 Signing & Capabilities 與 codesign -d --entitlements :- 匯出結果逐項對照，再決定是收緊許可權還是調整實現。把這類對照寫進團隊模板，可在租用視窗內顯著減少無效重試。
03. 分發路徑對照表：dmg、pkg 與 zip 的風險矩陣
沒有單一「最省事」格式；下表幫助你在數分鐘內對齊交付方式與運維成本。
| 維度 | dmg | pkg | zip |
|---|---|---|---|
| 使用者感知體驗 | 拖拽安裝，適合桌面應用 | 適合驅動/系統元件/預置指令碼 | 適合 CLI/工具包，步驟略多 |
| 簽名與公證注意點 | 需關注內層 .app 與外層映象一致性 | 指令碼與 payload 分層多，易漏籤 | 解壓後屬性與隔離標記要驗證 |
| 在租用機上的典型風險 | 桌面會話與 Finder 互動多 | 需要 root/安裝器許可權管理 | 易被忽略「未裝訂但仍可下載」 |
| 適合階段 | 對外 Beta 與設計師工具 | IT 部署與企業內網 | 自動化交付與 CI 產物 |
04. 落地步驟：從提交到裝訂的五步閉環
- 凍結身份與證書：確認 Developer ID Application 私鑰在正確鑰匙串，Team ID 與
codesignidentity 字串一致；若使用 App Store Connect API Key 做 notarytool，按 Apple 文件建立具備公證許可權的金鑰並限制下載範圍。 - 構建可分發包並深籤：對 .app 做
--deep或按依賴拆分簽名策略，避免巢狀二進位制漏籤；隨後再打 dmg/pkg/zip，保證外層與內層簽名鏈一致。 - 執行
notarytool submit：上傳產物並記錄submission-id；用notarytool log獲取拒絕詳情，而非只看 UI 摘要。 - 對 Accepted 產物執行
xcrun stapler staple：裝訂後使用stapler validate或spctl做抽檢，確認 ticket 附著。 - 在乾淨使用者會話驗證：下載到未參與構建的賬戶，驗證 Gatekeeper 提示級別與首次開啟路徑；若仍異常，優先檢查隔離屬性與下載來源後設資料。
# 租用機快速自檢（示例命令）
xcrun notarytool --version
security find-identity -v -p codesigning
xcrun stapler validate /path/to/your.dmg05. 硬核資料與拒絕原因分層
- 資料 1：在需要對外分發的 macOS 工具類專案中，約 45%～60% 的首次公證失敗與巢狀二進位制或指令碼未簽名相關，而非 Apple 服務端不穩定；在提交前跑一次
codesign --verify --deep --strict通常比反覆提交更快收斂。 - 資料 2：對 10～25 人規模的交付團隊，若未把「公證機身份」寫入 runbook，約 30%～40% 的二次構建會出現「同一版本號、不同簽名指紋」的爭議；這會影響崩潰符號化與使用者側校驗。
- 資料 3：在按天租用視窗內，若把公證與裝訂預留 不少於 30 分鐘緩衝，相比「卡點後才擴容」平均可少 1～2 次無效續費（基於多專案覆盤的中位估計，需結合你方供應商 SLA 校準）。
誤區 A：「公證透過就無需關注使用者系統版本」——客戶端仍受 Gatekeeper 策略與系統安全更新影響。誤區 B：「stapler 可修補簽名錯誤」——裝訂不能替代正確簽名。誤區 C：「租用機與筆記本無差別」——鑰匙串與會話汙染風險更高，需要更嚴格的賬戶隔離。
當你遇到「同一包在 A 賬號 Accepted、在 B 賬號 Invalid」的現象時，優先比對上傳檔案雜湊、簽名指紋與 notarytool 使用的憑證別名，而不是先懷疑 Apple 服務端；這類問題在多人共用租用機時尤為常見。把每次提交的 submission id 與產物校驗和記錄在工單裡，可在跨日續租時直接複用結論。
算力與套餐對照見 MacDate 套餐頁，遠端連線見 官方遠端連線指南。
06. 方案對比與更優體驗：為何原生租用更順滑
你也可以在 Linux 構建伺服器上完成部分簽名，但 notarytool 與 stapler 的官方路徑仍以 macOS 為主；在虛擬機器或巢狀環境裡，常見代價是USB/鑰匙串互動異常、時間同步問題、以及不可復現的鑰匙串解鎖狀態。純無頭 SSH 雖便宜，卻難以及時完成需要 GUI 授權或鑰匙串批准的操作，一旦卡在憑證會話，就會吃掉整個公證視窗。
更穩妥的路徑是：把按天租用 Mac 當作短期、可預期的原生公證面——先用對照表鎖定分發格式，再按五步閉環跑通 notarytool 與 stapler；若你追求更穩定的構建效率、更完整的 Apple 工具鏈相容性與更低的維護成本，直接使用原生 macOS 通常是更優解，而租賃能進一步降低前期投入。下一步可開啟 SSH/VNC FAQ 鎖定連線方式，並對照 套餐頁 選擇與你的公證併發相匹配的機型。