macOS 27 Mac App 公證前怎麼驗收？2026 清單

macOS 27 Mac App 公證前驗收，應以最終交付物為準：直接分發時核對 Developer ID 簽名、公證結果與使用者側啟動；透過 Mac App Store 發布，則走商店提交與發布驗收，不要照搬直接分發流程。先在隔離的建置環境驗收，再把通過的流程用於正式發布。

適合直接向使用者分發 Mac App、需要核對簽名與交付檔案的獨立開發者。
使用 DMG 或 PKG 的小團隊，可依下方分支分開檢查封裝與安裝結果。
沒有本地 Mac，或需要固定發布環境的開發者，可據此評估遠端 Mac 是否適合承載重複驗收。

最後更新於 2026 年 11 月 6 日；核對 Apple 的 macOS 軟體公證指南、notarytool 公證工作流程說明、應用程式分發說明及 macOS 27 發布說明。Apple 更新政策或平台支援資訊後，應重新核對相應條件。

macOS 27 Mac App 公證前驗收：先判定發布渠道

Apple 將直接分發與 Mac App Store 分成不同發布路徑。對直接交付的 Mac App，公證驗收要對上實際交給使用者的構建；商店分發則應核對商店提交及實際發布鏈路。Apple 的分發說明可用來界定兩者適用範圍。

先回答一個判斷問題：使用者最後拿到的是開發者直接提供的檔案，還是透過 Mac App Store 取得的版本？渠道不同，後續要查的提交對象與發布證據也不同。

直接分發：檢查簽名、執行環境與提交結果

Apple 的公證指南說明直接分發 macOS 軟體時的簽名與公證要求；Hardened Runtime 文件則說明該執行環境的相關條件。驗收時，不宜只看 Xcode 是否顯示建置成功，而應逐項確認：

• 簽名身份：確認最終 App 使用預定的 Developer ID 簽名，並檢查簽名狀態和應用識別資訊。簽名成功不等同公證完成。
• Hardened Runtime：確認發布構建符合直接分發所需的執行環境設定；若有例外權限，核對其是否為應用實際功能所需，並保留設定依據。
• 提交及回覆：以 notarytool 提交預定的軟體交付物，保存回傳狀態、提交識別資料及可取得的日誌。依 Apple 的公證工作流程文件核對團隊採用的工作流程。
• 構建一致性：將驗收的構建識別資料與發布檔案對照。重新建置、重新簽名或重新封裝後，不能直接把舊提交結果視為新檔案的驗收證明。

這些資料能回答「哪個構建送交公證、服務如何回覆、正式發布的是哪個檔案」。若只留下成功截圖，卻無法對應到交付檔，後續就難以複查。

DMG 與 PKG：驗收對象不同

DMG 和 PKG 都可能出現在直接分發流程，但它們是不同的交付物。Apple 的Mac 軟體封裝與分發說明可作為核對封裝流程的依據。團隊驗收時，應分別記錄實際提交的檔案、服務結果與使用者操作結果。

DMG 交付

• 比對送交公證的磁碟映像與使用者實際下載的映像，避免以 App 內部的驗收結果代替鏡像檔驗收。
• 確認票據處理針對的是要發布的交付物，並保存處理結果。
• 從最終 DMG 掛載 App，檢查能否在目標環境正常啟動。若只在建置目錄啟動過，尚未驗收使用者取得的映像。

PKG 交付

• 分開記錄安裝包本身的簽名與公證結果，不要把它們當成安裝後 App 狀態的證明。
• 從最終 PKG 執行安裝，核對預期安裝位置及安裝後 App 的簽名狀態。
• 從安裝位置啟動 App，將結果與該次 PKG 的提交資料及構建識別資料一起保存。

驗收邊界：DMG 的掛載與啟動測試，不等於 PKG 的安裝驗收；反過來，PKG 安裝成功也不能證明使用者直接下載的 DMG 已完成公證檢查。

Mac App Store：轉驗商店提交與實際發布

Mac App Store 版本不應機械套用 Developer ID 直接分發的公證步驟。Apple 的應用程式分發文件界定了商店與直接分發的差異。商店渠道的發布驗收，應聚焦於提交的構建是否正確、審核與發布流程是否完成，以及實際可取得的版本是否符合預期。

專案仍可保留構建識別資料、商店提交狀態及下載後的啟動驗證結果，但不要把「沒有獨立執行直接分發公證流程」誤判為商店發布缺項。商店版本與網站下載版本若並行，應各自保存渠道和構建記錄，避免混用驗收證據。

macOS 27 目標環境：把平台支援與公證結果分開

Apple 的 macOS 27 發布說明指出，macOS 27 僅支援 Apple silicon。這是目標系統的平台條件，不代表某個 App 已通過公證，也不代表它必定能正常啟動。

因此，驗收記錄至少要能分辨以下資訊：

• 建置環境：記下實際使用的 macOS 與 Xcode 版本，並核對所需工具鏈是否符合專案發布要求。
• 目標環境：記下測試系統及目標架構；若產品宣稱支援的系統或架構超出目前已核實範圍，先依 Apple 當前資料確認，不要自行推定。
• 啟動證據：在目標環境使用最終交付物測試啟動，保存可識別構建版本的記錄；有安裝流程的產品，也要從實際安裝位置啟動。

「公證服務接受」回答的是提交物的公證狀態；「目標系統啟動成功」回答的是應用在指定環境是否能開始執行。兩者應分開記錄，不能互相代替。

可複查的發布流程：用分支條件決定驗收方式

以下條件分支可作為專案內部 gate。按團隊政策補足測試範圍；這不是 Apple 官方評分標準。

• 若應用直接交給使用者，就核對 Developer ID、Hardened Runtime、提交結果和最終 App 的啟動；否則先確認實際分發渠道，再選相應流程。
• 若使用者下載的是 DMG，就以最終映像檔為驗收對象，核對票據處理、掛載後 App 的啟動及檔案一致性；否則不要以 DMG 清單代替 PKG 安裝檢查。
• 若交付的是 PKG，就分開驗收安裝包、安裝後 App 及實際啟動；否則回到該渠道的實際下載物進行測試。
• 若透過 Mac App Store 發布，就核對商店提交與發布鏈路，不另行照搬直接分發流程；若同時提供站外版本，則為站外版本另建直接分發驗收記錄。
• 若構建、簽名或交付物有變更，就重新確認對應的提交結果及啟動證據；若檔案未變更，也要能以識別資料證明本次發布與已驗收構建相符。

對每個分支，可在團隊內用 0／1／2 分做簡單狀態標記：0 代表沒有證據，1 代表已有記錄但尚未對上最終交付物，2 代表證據已與發布檔及目標環境核對。這套分數只是內部追蹤方式，不是 Apple 認證或官方門檻；任何關鍵項目未達團隊設定的發布門檻，就先不要放行。

遠端 Mac 流程：每一步都留下不同證據

遠端 Mac 可以承載重複的建置、簽名與公證驗收。關鍵不在於主機位於本地或遠端，而在於憑證使用權限、工具鏈、網路連線與最終證據是否可控。可按以下順序建立流程：

• 在隔離的建置環境準備專案，記錄 macOS、Xcode 及目標架構；此步證明「在哪裡建置」。
• 建置發布版本並完成 Developer ID 簽名，檢查簽名狀態及 Hardened Runtime 設定；此步證明「哪個構建已簽名」。
• 依渠道和交付格式封裝，再核對送交公證的檔案與預定發布檔案；此步證明「提交的是哪個對象」。
• 透過 notarytool 完成提交及結果核對，保存狀態與可取得的日誌；此步證明「公證服務如何回覆」。
• 對最終 DMG 或 PKG 執行相應的票據、掛載或安裝檢查，再於目標 macOS 環境啟動 App；此步證明「使用者取得的版本是否可用」。
• 將上述記錄與發布版本識別資料一同歸檔，確認之後能重現從建置到驗收的對應關係。

若需要評估固定的遠端發布環境，可先查看 OrbVPS Mac 租用常見問題，再依團隊的工具鏈、憑證政策與測試方式判斷是否合適。跨地區工作亦可參考 OrbVPS 香港 Mac 租用資訊；是否選用仍應以實際環境需求為準。

常見驗收問題

公證成功是否代表 App 一定能啟動？

不代表。公證回覆應與指定提交物對應；啟動測試則要在目標系統使用最終交付物執行。若 App 只在開發目錄啟動，或公證後又替換了封裝檔，仍欠缺使用者實際取得版本的驗收證據。

更換 DMG 或重新產生 PKG 後，能否沿用原有結果？

不能只因內部 App 看起來相同就沿用。更換封裝檔後，應確認提交對象、票據處理和最終檔案的對應關係；對 PKG，還要重新核對安裝後的 App。凡是無法證明與原驗收檔一致的版本，都應按新的交付物重新檢查。

遠端 Mac 能否完成簽名與公證？

可以將遠端 Mac 用於建置、簽名、提交公證及記錄結果，但需先確認工具鏈、憑證存取與團隊安全政策可接受。它無法取代目標系統啟動測試，也不能讓本來不支援的架構自動變成受支援；最終仍要以實際交付物核驗。

按交付物放行，不以單一「成功」狀態代替驗收

直接分發應核對 Developer ID、Hardened Runtime、公證結果及最終檔案；DMG、PKG 和 Mac App Store 各有不同的驗收焦點。若目前依賴開發者個人 Mac，常見限制是環境難以固定、憑證和發布責任集中在單一設備，以及重複測試時不易還原同一建置條件；改為自行購買 Mac，則需承擔硬體投入、維護與閒置成本。

若只是需要一個固定 macOS 環境反覆完成發布驗收，可評估按需租用 OrbVPS 遠端 Mac，先確認工具鏈、存取管理與專案政策是否吻合；若工作負載長期固定、需要實體介面，或有嚴格的本地憑證政策，自購設備可能更合適。最終選擇應服從專案的安全要求與發布頻率，而不是把遠端環境當成驗收本身。

常見問題