Xcode 27 捨棄 Intel：哪些終止、哪些仍能出貨

在所有與 Intel 相關的異動中，最可能改變您手上既有二進位檔的那一項，Apple 把它歸在「新功能」而非「棄用」底下。Xcode 27 版本說明中名為 Intel Deprecation 的段落恰好只有兩則條目，而真正讓 macOS app 預設不再建置為 Universal 的那一則，落在新功能那一側。¹²

重點摘要

• 這個標題底下其實藏著三項各自獨立的異動，Apple 自己的句子把它們分得很清楚。Xcode 27 只能安裝並執行於 Apple silicon Mac。² macOS 27 SDK 仍支援將 Universal app 回溯部署至 macOS 12 以後的版本。² 而一旦某個 target 的 macOS 或 DriverKit 部署目標達到 27.0，ARCHS_STANDARD 就不再納入 x86_64。¹
• 只有第三項會改變您出貨的內容，而且改變時不會有任何診斷訊息。Apple 在同一則條目裡就給出解法：「The x86_64 architecture can be added to the ARCHS build setting if this is needed.」¹
• Xcode 26.6 無法預覽新行為。我在一個純 macOS 專案上強制指定 MACOSX_DEPLOYMENT_TARGET=27.0，ARCHS_STANDARD 依然解析為 arm64 x86_64。¹³
• 兩種稽核習慣會製造出錯誤答案。加上 -sdk macosx 會讓一個純 iOS 專案回報 SUPPORTED_PLATFORMS = macosx 與 ARCHS_STANDARD = arm64 x86_64；而在專案層級解析設定，則會讓一個預設 target 為 iOS 的專案藏起兩個 macOS target。¹⁴
• 我手上 11 個 Xcode 專案、共 44 個 target：其中 21 個為 macOS 建置，這些 target 裡最高的 macOS 部署目標是 26.5，而且沒有任何一個設定 ARCHS 或 EXCLUDED_ARCHS。¹⁴ 磁碟上全部 51 份 macOS 封存檔皆為 x86_64 arm64。¹⁴
• Intel 軟體的終點落在 macOS 28，而非 Xcode 27，而且 Apple 的句子帶著一個值得細讀的但書：「All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.」¹⁰

以上所有內容，Apple 都是以 beta 文字形式發布於 Xcode 27 beta 4 與 macOS 27 beta 4 的版本說明中。³⁶

三個句子，三種不同的異動

Apple 的 Intel Deprecation 段落只有兩則條目。把它們讀成同一項主張，會在兩個方向上都做出錯誤決定。

棄用那則講的是您桌上那台機器，語氣毫無轉圜：「Xcode 27 will only install and run on Apple silicon Macs.」² 沒有任何建置設定能改變這件事。Intel Mac 從此不再是能執行當前 Xcode 的機器；Apple 的相容性表格更在硬體門檻之上加了一道軟體門檻，列出 macOS Tahoe 26.4 以後版本為 Xcode 27 beta 4 的要求。⁴

同一則條目接著保護了產出：「The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.」² Apple 的相容性表格與此一致，顯示 Xcode 27 beta 4 的 macOS 部署範圍為 12 至 27，而 Xcode 26.6 為 11 至 26.5。⁴ 下限恰好往上移動了一個版本。Universal 二進位檔活了下來。

條目最後則保住了工作流程本身：「Intel development is still possible with macOS versions that support Rosetta like macOS 27.」²

接著是新功能那則，也是真正有能力改變您既有產品的那一則：

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed.¹

這裡有四個細節值得分開來看。Apple 只點名兩項設定、別無其他，所以 IPHONEOS_DEPLOYMENT_TARGET 及其同類都不在這條規則之內。Apple 給的是一道門檻，而不是某個工具鏈版本，因此觸發條件是您自己的部署目標跨過 27.0。Apple 說的是「will not build Universal by default」，描述的是預設值，不是禁令。而且 Apple 在同一段話裡就給了退路，明確指出把 x86_64 放回去的位置就是 ARCHS。

不報錯就改掉的預設值

機制本身平淡無奇，也正因如此才安靜。Apple 的建置設定參考文件如此描述 ARCHS：「A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced.」⁵ 那個預先定義的設定就是 ARCHS_STANDARD，而 Apple 在同一份文件的別處也確認了這層相依關係，提到指標驗證「Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD.」⁵

所以，從未提及 ARCHS 的 target，繼承的就是平台交給它的值。改掉平台交出去的東西，產品的形狀就跟著變，而版本控管底下沒有任何一個檔案被動過。

整個過程不會產生任何失敗。編譯器跑完，連結器跑完，封存檔通過驗證。工具鏈裡沒有任何一環會把單一 arm64 切片的 macOS 建置當成錯誤，因為那本來就不是錯誤。結果是一個正確、已簽章的 macOS app，只是原本帶兩個架構切片，現在只剩一個。在 Apple silicon Mac 上——如今每位 Xcode 27 開發者依規定都在用的機器——僅含 arm64 的建置照樣啟動，行為一模一樣。這項退化只會在早已不在開發現場的硬體上顯現。

把這種失效模式描述為「無聲」是我的說法，不是 Apple 的；Apple 只描述預設值，說完就停。Apple 確實有說的是，修正方式屬於增補性質，而這個措辭對規劃很重要：x86_64「can be added to the ARCHS build setting if this is needed.」¹ 需不需要，Apple 把判斷留給您。

Xcode 26.6 會告訴您什麼、不會告訴您什麼

我的機器跑的是 macOS 26.5.2 上的 Xcode 26.6（build 17F113），因此本文任何地方都不會出現 Xcode 27 的行為。¹³ 舊工具鏈能回答的有用問題只有一個：它是否已經以新方式運作。答案是否定的。

把 xcodebuild 指向一個純 macOS 專案，並把部署目標覆寫到 Apple 所指的門檻之上，架構清單依然紋風不動：¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

第一行是 xcodebuild 把覆寫值回顯出來；其餘才是解析後的結果。同一道指令改成 26.0，架構那幾行完全相同。¹³ Xcode 26.6 並未實作這道門檻，因此沒有人能在現行工具鏈上預演這項異動；任何前後對照都得等到 Apple silicon Mac 上的 Xcode 27。

平台範圍的界定倒是今天就能重現。同一個專案改用 iOS SDK 解析，得到 ARCHS_STANDARD = arm64，根本沒有 x86_64 可失去；換成 macOS SDK 則是 arm64 x86_64。¹³ Apple 的條目只點名 macOS 與 DriverKit 部署目標，多平台專案的 iOS 那一側毫無利害關係。

盤點自己受影響的範圍，而不是憑空捏造

有兩種習慣會產出自信滿滿的錯誤答案。這兩個我都踩過。

第一種是為了判斷專案是否為 macOS 建置，而傳入 -sdk macosx。這個旗標會覆寫專案自身的 SDK，於是 Xcode 回答的是關於旗標的問題，而非關於專案的問題。不加任何覆寫去問，我那個純 iOS 的瀏覽器專案會回報它真正的平台；加上 -sdk macosx 再問，同一個專案卻回報 SUPPORTED_PLATFORMS = macosx 與 ARCHS_STANDARD = arm64 x86_64，這純粹是旗標造成的假象。¹⁴ 起手式應該完全不帶 -sdk：

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

對我那個唯一的純 macOS app 執行，回來兩行：¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

兩行都要讀，絕不能只讀一行。那個專案宣告的是 SDKROOT = macosx，完全沒有 SUPPORTED_PLATFORMS 這一行，所以拿 SUPPORTED_PLATFORMS 去對專案檔做文字搜尋，會給它零分，直接跳過我手上唯一的純 macOS app。¹⁴ 解析後的設定會從 SDK 補上這個缺口；grep 做不到。這個階段請忽略 MACOSX_DEPLOYMENT_TARGET，因為 Xcode 無論如何都會給一個：我有三個純 iOS 專案照樣回報了 macOS 部署目標，兩個是 26.5，一個是 26.2。¹⁴

第二種習慣是在專案層級解析設定。xcodebuild -showBuildSettings 不帶 -target 時只回答單一 target，混合型專案會把其餘的埋起來。我的 Safari 擴充功能專案解析結果是 SUPPORTED_PLATFORMS = iphoneos iphonesimulator 與 ARCHS_STANDARD = arm64，讀起來像是一個與 Intel 完全無關的純 iOS 專案。把它的 target 列舉出來，卻找到四個，其中兩個是 macOS，兩個都解析為 arm64 x86_64：¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

有個怪癖要先有心理準備：帶著 SDKROOT = auto 的 target，在您指定 SDK 之前不會解析出 ARCHS_STANDARD，所以我 21 個 macOS target 中有 15 個在那一行上什麼都不印，直到指令補上 -sdk macosx，這時它們所屬的專案才解析出 arm64 x86_64。¹⁴ 空白代表未解析，不代表為空。

接著別再相信設定，改去讀二進位檔。建置設定描述的是意圖；lipo 描述的是您實際出貨的成品：

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

請優先採用 lipo，而非封存檔自身的中繼資料。我有兩份封存檔的 Info.plist 裡壓根沒有 ApplicationProperties 架構清單，所以對封存檔下 plutil 查詢什麼也拿不到，對裡頭的二進位檔跑 lipo 卻回傳 x86_64 arm64。¹⁴ 中繼資料裡的缺席，意味著封存檔的寫法不同，而不是 app 掉了一個切片。

11 個專案裡實際有什麼

我對 11 個 Xcode 專案、共 44 個 target 跑了這套稽核。8 個專案至少含一個 macOS target，21 個 target 為 macOS 建置，而目前受新預設值影響的範圍是零。¹⁴

這整批專案裡最高的 macOS 部署目標是 26.5，最低的是 13.0，出現在一個久未回頭整理的 Safari 擴充功能上。沒有任何一個 target 跨過 27.0，因此在有人親手把數字調高之前，也沒有任何一個 target 會進入預設值變更後的狀態。設定 ARCHS 的 target 是零，設定 EXCLUDED_ARCHS 的也是零，而這 11 個專案裡連一個 .xcconfig 檔都沒有，所以全部 44 個 target 的每一項架構決定都來自 ARCHS_STANDARD。¹⁴

封存檔的證據比設定的證據更有力，因為封存檔記錄的是實際出貨的內容。我的機器上有 79 份封存檔，建置日期落在 2026 年 4 月至 7 月之間。全部 51 份 macOS 封存檔橫跨七項不同產品，一律回報 x86_64 arm64。全部 28 份 iOS 家族封存檔一律回報 arm64。¹⁴ 這些專案裡從來沒有人選擇過 Universal；每一次都是預設值造就的。這正是 Apple 這項異動所作用的族群，也正因如此，不會有人察覺。

有一個必須誠實交代的缺口：把部署目標拉到 27.0 是一個刻意的動作，而我的專案目前都還沒有這麼做的理由。這批專案乾淨的結果，量到的是某個時刻，而不是某項政策。

Intel 軟體真正的終點在哪裡

Xcode 這項異動關乎的是一次建置裡的架構。Intel 軟體作為一個類別的終點落在 macOS 28，而 Apple 把這件事寫在 Rosetta 文件與 macOS 27 版本說明裡，兩處說法一致。

Apple 的 Rosetta 文件直接給出時程。Rosetta「was designed to make the transition to Apple silicon easier, and will be available through macOS 27」，作為 Intel app 的通用工具，而且「Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.」⁷ macOS 27 版本說明以同樣的但書陳述其後果：「All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.」¹⁰ 同一份說明另一處的一道 beta 限定指令，讓這個但書有了具體形狀：sudo game-test-tool enable 會開啟舊版 Intel 遊戲支援，而 Apple 警告「enabling legacy game support disables Rosetta.」¹⁵

macOS 27 用這段過渡期，逐一點名哪些東西活不下去。Apple 的棄用資訊段落指出「Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info」，另一則條目補充「Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0」，其中也包含「unused Intel-based software discovered on the system.」⁸⁹

有三則比較低調的條目，對任何出貨 Mac 產品的人來說更為重要。

Rosetta 本身不再自動留存：「If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0.」¹¹ Apple 的文件補上了脈絡，指出 macOS 27「directly integrates support for Intel binary translation, without needing to install Rosetta」，目的是支援 ARM 虛擬機器中的 Intel Linux 二進位檔以及 Intel Linux 容器。⁷ 使用者先前指定過的 app 也會改變：先前設為「Open using Rosetta」的應用程式現在「have the application launch natively」，而 Apple 建議「Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27.」¹²

安裝套件的預設值變了：「Installer packages which specify no hostArchitecture will now default to arm64」，Apple 並要求您「Ensure any pre and post install scripts behave as intended under arm64.」¹¹ 任何在 App Store 之外散布的 Mac 產品，不論其 app 是否為 Universal，都得承接這一項。

外掛的宿主程式承受的風險最為尖銳。Apple 警告「Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility」，並點名了需要手動檢查的目錄，包括 ~/Library/Audio/Plug-Ins/、~/Library/Printers/ 與 ~/Library/ColorPickers/。¹⁰ 一個外掛何以能拖累一個原本原生的 app，原因寫在 Apple 的 Rosetta 文件裡：「The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically.」⁷ 因此，一個 Intel 外掛會逼得它的宿主整個以轉譯模式執行，讓單一一個無人維護的元件，變成整個 app 對 Apple 已排定縮減的那項機制的依賴。

Universal 存在的意義，是為了觸及執行 macOS 12 至 27 的 Intel Mac，也就是 Apple 相容性表格為 Xcode 27 所公布的範圍。⁴ Apple 已把 Intel 軟體的終點訂在 macOS 28，同時完全沒有動部署範圍，所以一個 macOS 團隊真正該問的是：還有多少使用者仍在用需要那個切片的 Mac。

有兩件事我查過但沒找到：Xcode 27 與 macOS 27 的版本說明，都沒有提及 Mac App Store Universal Purchase 相關規定有任何變動，兩者也都沒有為 macOS 28 訂下任何日期。³⁶ 您讀到的任何日期，都請當成推論看待。

常見問題

Xcode 27 會讓我無法出貨 Intel app 嗎？

不會。在把 Intel Mac 棄用為開發機器的同一則條目裡，Apple 說的正好相反：「The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.」² Apple 的相容性表格也證實了這個範圍，列出 macOS 12 至 27 為 Xcode 27 beta 4 的部署目標。⁴ 改變的是預設值。macOS 部署目標達到 27.0 的 target，不再從 ARCHS_STANDARD 拿到 x86_64，而 Apple 明示的修正方式是您自己把 x86_64 加進 ARCHS。¹ 出貨 Intel 從此是一個您主動宣告的選擇，而不是繼承而來的結果。

如果 ARCHS_STANDARD 拿掉 x86_64，我的建置會失敗嗎？

Apple 那則條目裡完全沒有描述任何錯誤、警告或診斷訊息。Apple 描述的是預設值改變：macOS 或 DriverKit 27.0 以上的 target「will not build Universal by default.」¹ 一個以單一架構切片而非兩個完成編譯、連結與簽章的建置，是一個有效的建置；而在 Xcode 27 要求您使用的那台 Apple silicon Mac 上，這個差別在執行期完全看不出來。² Apple 只陳述預設值，把後果留白，所以「無聲」這個詞是我的，不是 Apple 的。請對已封存的二進位檔跑 lipo -archs 來檢查，別等建置日誌來提起這件事。

我可以在 Xcode 26 上測試新行為嗎？

不行。我直接在 Xcode 26.6（build 17F113）上跑過這個檢查：在純 macOS 專案上把 MACOSX_DEPLOYMENT_TARGET 覆寫為 27.0，ARCHS_STANDARD 仍解析為 arm64 x86_64，與同一道指令在 26.0 的結果完全相同。¹³ 舊工具鏈並未實作這道門檻，所以在 Xcode 26 上再怎麼折騰建置設定，都無法預覽這項異動。Xcode 26.6 確實能重現的是範圍界定：同一個專案對 iOS SDK 解析出 ARCHS_STANDARD = arm64，對 macOS SDK 則是 arm64 x86_64，恰好對應一則只點名 macOS 與 DriverKit 部署目標、別無其他的條目。¹¹³

我現在需要一台 Apple silicon Mac 嗎？

要跑 Xcode 27 的話，是的，沒有任何附帶條件：「Xcode 27 will only install and run on Apple silicon Macs.」² Apple 在硬體門檻之上還加了軟體門檻，Xcode 27 beta 4 需要 macOS Tahoe 26.4 以後的版本。⁴ Intel 開發在舊工具鏈上仍然存活，Apple 也是這樣定調的：「Intel development is still possible with macOS versions that support Rosetta like macOS 27.」² Apple 的 Rosetta 文件為這條路訂下了邊界，說明 Rosetta 作為通用工具「will be available through macOS 27」，此後只保留針對舊版無人維護遊戲的縮減子集。⁷

重點整理

給 macOS app 開發者： - 稽核時先不要帶任何 -sdk 旗標，把 SUPPORTED_PLATFORMS 與 SDKROOT 一起讀，而在判斷某個 target 究竟是否為 macOS 建置時，請忽略 MACOSX_DEPLOYMENT_TARGET。Xcode 會把 macOS 部署目標寫進純 iOS 專案裡：我有三個專案回報了這個值（26.5、26.5、26.2），卻沒有為任何一台 Mac 建置。¹⁴ - 在解析設定之前，先用 xcodebuild -list 列舉 target。對我的 Safari 擴充功能做專案層級查詢，回報的是一個純 iOS 專案，並藏起了兩個 macOS target。¹⁴

給使用者中包含 Intel Mac 的團隊： - 明確決定 x86_64，而不是被動繼承。當您把 macOS 部署目標拉到 27.0 時就設定 ARCHS，因為 Apple 那則條目給的正是這個解法，而若您略過它，也不會有任何警告。¹ - 用 lipo -archs 對已封存的二進位檔驗證，不要看建置設定，也不要看封存檔的 Info.plist。我有兩份封存檔完全沒有架構中繼資料，二進位檔本身卻是 Universal。¹⁴

給發布管理者： - 把硬體的時限與出貨的時限分開來看。Xcode 27 從第一天起就需要 Apple silicon Mac；Universal 產出仍可存活至 macOS 12 以後的版本，而 Apple 至今未公布 macOS 28 的任何日期。²⁴ - 清點 Intel 外掛與安裝套件，別只清點 app。Apple 警告 Intel 外掛「may not appear in Settings」，而一個 Intel 外掛會逼得它的整個宿主行程以轉譯模式執行。⁷¹⁰

27 這一輪的更新不斷把影響深遠的異動藏在不起眼的地方。連結器移除與模組名稱規則在升級工具鏈時直接讓建置失敗，@State 巨集則在原始碼層級讓它失敗，而啟動畫面鍵值會擋下一次送審。Intel 預設值什麼都沒弄壞，卻照樣改變了產品，這也讓它值得在升級之前、而非之後拿來稽核。整個系列的彙整頁在Apple 生態系系列。

參考資料