macOS App 公證怎麼做？2026 遠端 Mac 發布清單

先選發布渠道：直接分發與 App Store 審核不是同一條路

如果 App 要直接提供給使用者下載，本文的檢查流程以 Developer ID 簽名和公證為主；若目標是上架 App Store，則應依照 App Store 的提交與審核流程處理。公證不能替代商店審核，也不代表 App 已符合商店上架要求。Apple 對不同 Mac App 分發方式的說明可供確認渠道差異。

這個區分會影響你準備的檔案、簽署身份與交付方式。不要因為 Xcode 能產生封存檔，就直接假定產物已經符合直接分發條件；也不要把 App Store 用的提交步驟套到 Developer ID 公證流程。

可先依下列方式判斷：

• 直接交付安裝包或下載連結：檢查 Developer ID 簽名、公證與最終交付檔。
• 透過 App Store 發布：按商店分發流程準備與提交，不把公證當作審核結果。
• 客戶尚未決定渠道：先確認交付方式，再建立封裝與發布工作；不要提早把某一套流程當成兩種渠道通用。

第一階段：出發前確認團隊、身份與憑據

遠端 Mac 上的 macOS App 公證能否順利完成，首先取決於存取權限，而不是連線畫面能否打開。開始前確認開發者團隊、專案存取、簽名憑據和發布責任人；若帳號沒有建立或使用簽名身份的權限，應先停止發布準備，不要以「Xcode 可以開啟」當作權限已齊全的證明。

Apple 的Developer ID 憑證說明列出直接分發所用的簽署身份。建立清單時，也要分清 Developer ID Application 與 Developer ID Installer：前者用於簽署 App，後者用於簽署安裝套件。實際選用哪個，應依最終交付物與專案的封裝方式判斷。

憑據管理則要採取最小權限原則：

• 可在受控遠端環境中使用的簽名資料，應限於完成建置與發布所需的帳號及權限。
• Apple 帳號密碼、API 私密金鑰、憑證私鑰與復原資訊，不應寫進程式碼、提交紀錄或共用文件。
• 若團隊無法說明憑據存放位置、誰能使用，以及如何撤銷或更新，就先不要把遠端主機設為正式發布環境。
• 離開共用或旅居場所前，確認遠端連線已登出，並依團隊規範清除不應留在工作環境中的憑據。

若首次設定公證認證資料，可使用 Apple 支援的命令列流程將憑據存放在鑰匙圈中；不要把秘密值直接貼進終端機紀錄、聊天訊息或版本控制。細節可參考 Apple 的自訂公證工作流程文件。

第二階段：完成首次簽名，檢查 App 與內含元件

在 Xcode 完成建置或封存後，先確認 App 本身及其內含的輔助工具、框架與其他可執行元件都使用預期的簽名身份。只成功啟動 App，或只產生封存檔，都不足以證明它已可直接分發。Apple 的分發簽名與 Hardened Runtime 設定說明提供了簽名設定與執行環境要求的參考。

可先在遠端 Mac 上檢查簽名資訊與驗證結果：

codesign -dv --verbose=4 "MyApp.app"
codesign --verify --deep --strict --verbose=2 "MyApp.app"

第一個命令的輸出應讓發布者核對簽名身份與 App 識別資料；第二個命令則用於檢查簽名驗證。若出現錯誤，不要直接重新打包並提交公證，先回到建置設定、簽名選擇與封裝內容，找出是哪個元件未簽署或身份不符。

接著核對 Hardened Runtime 與專案所需的權限設定。若程式依賴特定系統功能或例外權限，應由專案負責人確認必要性及設定來源；不要為了消除錯誤而加入未經審核的權限。遇到簽名或執行環境問題時，保存 Xcode 建置記錄、簽名檢查輸出及產物版本，讓其他團隊成員能依同一批證據重現檢查。

第三階段：提交公證，保存識別資料與處理紀錄

簽名驗證完成後，才將預定交付的封裝檔送交公證。Apple 提供 Xcode 與命令列等工作流程；若選擇 notarytool，可按下列形式提交，並等待處理結果：

xcrun notarytool submit "MyApp.zip" \
  --keychain-profile "notary-profile" \
  --wait

命令中的封裝檔必須是準備給使用者的對應產物，不要拿另一份測試檔的結果當作正式交付依據。命令列憑據設定方式與公證流程，請以 Apple 的macOS 軟體公證文件為準。

提交後，記錄命令輸出的提交識別資料、狀態與時間，並用識別資料查詢詳細結果：

xcrun notarytool info "SUBMISSION-ID" \
  --keychain-profile "notary-profile"

xcrun notarytool log "SUBMISSION-ID" \
  --keychain-profile "notary-profile"

跨時區協作時，這份紀錄能讓接手者知道該查哪一次提交，而不是重新上傳產物、製造多份難以辨認的結果。若狀態尚未完成，就不要把「已送出」寫成「已通過」；若被拒絕或有警告，先讀取公證記錄，確認問題來自簽名、封裝、權限或其他檢查，再修正並重新驗證。

第四階段：處理票據，再從使用者角度驗收

公證通過、票據處理完成與檔案可正常交付，是彼此相關但不能互相替代的檢查結果。Apple 的Mac 軟體封裝與分發指南說明分發產物的準備方式；公證後也應依交付格式處理票據，並驗證最後要交給使用者的檔案。

例如，對 App 進行票據處理與驗證：

xcrun stapler staple "MyApp.app"
xcrun stapler validate "MyApp.app"

若實際交付的是磁碟映像檔或安裝套件，請依 Apple 文件與交付格式選擇對應的處理對象，不要只驗證 App 內部的檔案，卻忽略使用者下載的外層封裝。

接著從乾淨的測試環境下載最終交付檔，按使用者實際操作方式開啟。核對系統是否出現預期的安全提示、App 能否啟動、主要功能是否可用，以及安裝說明是否與實際流程一致。若只有開發環境能正常啟動，或測試檔與正式下載檔不同，便不能視為發布驗收完成。

FAQ：遠端發布流程中容易混淆的幾件事

遠端 Mac 能否完成 macOS App 公證？
可以，前提是主機能執行所需的 macOS 建置與簽名流程，且團隊帳號、憑據和專案權限均已確認。遠端連線只提供操作方式，不會補足缺少的簽名權限，也不保證公證結果通過。

Developer ID 簽名與公證有何不同？
Developer ID 是直接分發軟體使用的簽署身份；公證則是將發布產物交由 Apple 檢查。簽名完成並不代表公證已通過，公證通過也不能取代封裝、票據及使用者端驗收。

如何提交 macOS App 公證？
可以依 Apple 支援的 Xcode 工作流程操作，或使用 notarytool 提交封裝檔、查詢狀態並檢視公證記錄。無論使用哪一種方式，都要保存提交識別資料，並核對送交的檔案就是預定交付的版本。

公證通過後還要驗證什麼？
檢查最終交付物是否與送交公證的產物一致，依封裝格式處理並驗證票據，再從乾淨環境下載及首次開啟。若使用者下載到的檔案、安裝提示或啟動結果與預期不同，就先暫停交付並查明差異。

按發布渠道與工作環境作最後判斷

下表用來先判斷應走哪一種發布流程；它不是對任何遠端主機或專案能否成功的保證。

再按工作環境確認遠端 Mac 是否值得承擔正式發布工作：

因此，判斷遠端 Mac 是否可用，應以自己的專案完成一次完整發布演練為準：先檢查簽名，再提交公證、讀取結果、處理票據，最後從乾淨環境安裝。若其中任何一步仍依賴未確認的帳號權限、人工憑據或無法重現的本機操作，就先保留本機備援，不要把環境可連線等同於發布可用。

對經常出差的開發者來說，隨身帶 Mac 會增加設備保管與遺失風險；只有 iPad 或輕薄本則可能無法直接完成 macOS 建置與簽名。遠端 Mac 可把發布工作留在可存取的 macOS 環境，但它仍依賴穩定連線、妥善的權限管理與專案本身通過檢查。若你準備用 NodeMini 測試自己的發布流程，可先查看遠端 Mac 的使用方式，再按預計連線地點了解香港遠端 Mac 方案，並以短期實際驗收決定是否適合正式交付；環境介紹本身不代表公證成功。