主應用顯示 Universal Binary，但 CI 裡的程式碼產生器仍以 x86_64 執行，這是遷移驗收最容易漏掉的失敗症狀。

最快解法：不要等 Rosetta 後續支援完全退出；立即在隔離的 Apple Silicon 節點盤點整條依賴鏈，完成原生 arm64 建置、測試、簽名與重啟復測。仍要交付 Intel 版本時，保留獨立兼容流水線，但不要再讓 Rosetta 成為生產工具鏈的預設執行路徑。

本文最後更新於 2026 年 9 月 20 日；日期與 Rosetta 支援狀態核對自 Apple 軟體平台更新公告、macOS 27 Release Notes 與 Rosetta 技術文件。

這篇適合維護含原生庫、外掛或命令列工具的 macOS 應用開發者，也適合負責遠端 Mac CI 的 DevOps 工程師。若你仍要向 Intel Mac 使用者交付軟體，發布負責人也能用本文建立 Apple Silicon 主線與 Intel 兼容線的雙軌驗收標準。

先確認支援邊界

截至 2026 年 9 月 14 日，macOS 27 已正式發布。Apple 已確認，macOS 27 是面向一般 Intel 應用提供 Rosetta 通用支援的最後一個大版本；後續只會為特定舊遊戲保留有限能力。這不代表 macOS 27 現在已無法執行所有 Intel-only 應用，實際結果仍取決於應用、外掛、底層函式庫與啟動方式。

因此，macOS 27 上能否繼續執行 Intel 應用，不能只看作業系統版本。你的驗收對象至少包括主程式、App Extension、Plug-in、Framework、動態函式庫、靜態函式庫、命令列工具、背景 Daemon，以及建置輔助程式。Apple 對 Apple Silicon 與 Rosetta 的架構說明，可參考官方 Apple Silicon 文件。

要先分清三種狀態：

  • 純 arm64：只能在 Apple Silicon 原生執行，適合原生 CI 主線。
  • x86_64：在 Apple Silicon 上通常需要 Rosetta；在 Intel Mac 上原生執行。
  • Universal Binary：同一檔案內含多個架構切片，但不代表所有子依賴、外掛或建置工具都已經不需要 Rosetta。
看到 Universal Binary 時，不能直接把整條流程標記為原生完成。主程式可以是 Universal Binary，卻在啟動時載入 x86_64 外掛；建置也可能由 Intel-only 程式碼產生器完成。你必須記錄每個檔案的架構與實際呼叫位置，不能用主程式的檔案標記代替整條流程的證據。

盤點依賴與執行程序

先從全新複製的專案開始，不要直接相信既有 Runner 的環境。對應用包、Framework、XCFramework、Plug-in、SDK、腳本與工具逐項執行：

file /path/to/binary
lipo -archs /path/to/binary
uname -m
arch
file 用來確認檔案類型，lipo -archs 用來查看切片；uname -m 和 arch 則只能反映目前 Shell 或程序的執行架構。把結果放進依賴清單，並增加以下欄位：
  • 來源與版本：自建、套件管理器、第三方 SDK 或供應商交付。
  • 呼叫位置：Build Phase、Package Script、測試啟動器、發布腳本或背景任務。
  • 目前架構：arm64、x86_64 或 Universal Binary。
  • 處理責任人：升級、從原始碼重建、替換或暫時保留。
  • 阻塞級別與退出條件：何時可以重新驗收，何種失敗必須停止上線。
**專案中的 x86_64 二進位依賴應該怎樣找？**不要只搜尋檔名。你應該遞迴掃描產物與依賴目錄，再用 file、lipo 查看實際切片；對已安裝的工具則記錄完整路徑與執行結果。若某個工具只在互動式終端機中顯示 arm64，卻在 SSH 或 CI 帳戶中解析到另一個路徑，仍應視為未完成盤點。

特別檢查以下容易被忽略的程序：

  • 編譯器包裝腳本與自訂 Build Phase。
  • 程式碼產生器、格式轉換器與測試報告工具。
  • Homebrew 或其他套件管理器安裝的命令列工具。
  • Shell 內呼叫的固定 /usr/local 路徑。
  • 建置服務、Runner 啟動程序與背景 Daemon。

**注意：**互動式終端機、SSH 工作階段與 CI 服務帳戶可能使用不同的 PATH、Shell 初始化檔及 Keychain。你必須以 Runner 真實帳戶重跑架構檢查，不能用本機終端機的成功結果代替 CI 證據。

排除工具鏈與第三方阻塞

檢查 CI 工具是否依賴 Rosetta 時，應該看哪些證據？先在 CI 工作中輸出 uname -m、工具絕對路徑、file 結果及啟動程序資訊，再觀察編譯器包裝腳本、套件管理器、程式碼產生器與自訂 Shell 是否透過 arch -x86_64 或固定 Intel 路徑啟動。若工具只有在安裝 Rosetta 後才能完成，這條工作就不應標記為原生通過。

第三方二進位依賴要分成四類處置：

  • 可升級：供應商已有 arm64 或 Universal Binary 版本，固定版本後重新建置。
  • 可重建：有原始碼，改用 Apple Silicon 工具鏈編譯並保存產物證據。
  • 可替換：改用能在 arm64 原生執行的套件或工具。
  • 暫時無法遷移：保留隔離的 Intel 兼容任務，設定負責人與期限。
沒有 arm64 切片的 Framework、XCFramework、外掛或閉源輔助工具，若只能靠排除 arm64、強制 x86_64 或整條流程轉譯來通過，就不能算生產節點已完成遷移。這類結果應標記為阻斷，而不是「測試暫時通過」。

Xcode 的建置設定也不能只靠預設值推測，應以官方 Xcode Build Settings Reference 對照目前專案設定，檢查架構條件、排除架構、搜尋路徑與自訂腳本是否仍保留 Intel 假設。

建立原生測試證據

在獨立 Apple Silicon 節點上，以全新帳戶、全新複製及可再生快取清空後的狀態執行：

  • 原生 arm64 啟動與基本操作。
  • 單元測試、整合測試及關鍵業務任務。
  • 外掛載入、XPC 或背景服務啟動。
  • 依賴 JIT、底層指令集或進程內擴充功能的專項測試。
  • 歸檔、簽名、公證及最終產物檢查。
  • 節點重啟後重新連線與再次建置。
每項測試都要保存程序架構、建置日誌、崩潰記錄與產物架構。若 Apple Silicon 上的主程式是 arm64，但測試外掛由 x86_64 載入，應判定為轉譯路徑，不得用「功能有反應」作為原生通過證據。

同一提交應與舊 Intel 流水線對照，但兩者目的不同：Apple Silicon 任務驗證原生主線，Intel 任務只驗證仍需支援的使用者版本。不要讓舊流水線繼續承擔所有生產建置，否則你看似保留兼容性，實際上仍無法發現原生工具鏈的缺口。

清空 CI 假象與簽名鏈

CI 遷移最常見的假成功來自快取，而不是程式真的可在 arm64 上重建。檢查快取鍵是否包含執行架構、Xcode 版本、依賴鎖定檔與工具鏈版本；同時搜尋腳本中的 uname、arch、x86_64、固定路徑及架構條件分支。

驗收時必須完成全新複製、清空可再生快取、獨立 Apple Silicon 節點建置，並確認下載的依賴不是舊架構產物。簽名階段則要核對執行帳戶、Keychain、憑證權限與最終 App／Framework 的架構；建置成功但公證工具仍為 Intel-only，不能算交付鏈完成。

  • [ ] Runner 服務以 Apple Silicon 節點啟動，並保存實際程序架構。
  • [ ] 互動式終端機、SSH 與 CI 帳戶的 PATH 和工具絕對路徑一致或已明確記錄差異。
  • [ ] 主程式、Framework、XCFramework、外掛、命令列工具及 Daemon 都有 file 或 lipo 證據。
  • [ ] 原生 arm64 建置不依賴 Rosetta、arch -x86_64 或歷史快取。
  • [ ] 全新複製後可完成測試、歸檔、簽名與公證。
  • [ ] 重啟節點後，Runner、Keychain、依賴下載與建置任務仍可恢復。
  • [ ] Intel 兼容任務已獨立，並且不再是所有生產建置的預設路徑。
  • [ ] 每個未遷移依賴都有負責人、期限及可驗證的退出條件。

以評分決定生產切換

你可以把結果分成三種，不要用模糊的「大致可用」：

通過：原生 arm64 建置、測試、簽名、發布與重啟復測均有證據；剩餘 Intel 任務只存在於明確的兼容線。

限期整改：主線可原生建置，但仍有非生產工具或少數第三方元件依賴 Rosetta；必須指定負責人、期限與回退方式，並禁止把結果標成完整遷移。

阻斷上線：關鍵外掛、程式碼產生器、簽名工具或發布腳本只能以 x86_64 執行；或者成功來自舊產物、錯誤快取與未驗證的歷史環境。此時先保留現有流程，再建立隔離的 Apple Silicon 驗證節點。

如果你的現有 Intel Mac 無法驗證 arm64 主線，遠端 Mac CI 由 Intel 工具鏈遷移到 arm64 時，最穩妥的做法不是直接替換生產 Runner，而是先複製同一提交到隔離的 Apple Silicon 節點，完成上述清單後再決定切換。你可以先查看 MACGPU 的遠端 Mac 方案，按需要建立測試節點；若要處理特定 Apple Silicon 配置，也可參考遠端 Mac 租用選項。

若目前方案是繼續依賴 Intel Mac 或讓一般雲端 Linux 主機透過 Rosetta 路徑代跑，缺點很明確：它無法證明 arm64 原生工具鏈真的可用，容易把舊快取與歷史環境當成成功，也會讓簽名、外掛載入及重啟恢復的問題延後到發布階段。對只需要短期驗證、遷移排障或臨時擴充 CI 的團隊，租用 MACGPU 的真實 Apple Silicon 遠端 Mac，通常比先購置並長期維護一台專用設備更容易隔離風險；但若你需要長期高負載、實體介面或完全掌控硬體，仍應評估自購 Mac 與自建節點。