Xcode 27 弃用 Intel：什么停止了，什么照常发布

以上内容全部出自测试版文档——Xcode 27 beta 4 与 macOS 27 beta 4 的发行说明。³⁶

Here is the complete corrected body:

在所有 Intel 相关的变更里，最有可能改动您已经发布的二进制文件的那一条，Apple 把它归在了“新功能”而非“弃用”之下。Xcode 27 发行说明里有一节名为 Intel Deprecation，其中恰好只有两条记录；而真正让 macOS 应用不再默认构建 Universal 的那一条，出现在“新功能”一侧。¹²

要点速览

• 标题背后藏着三项彼此独立的变更，Apple 自己的措辞把它们分得很清楚。其一，Xcode 27 只能安装并运行在 Apple silicon Mac 上。² 其二，macOS 27 SDK 依然支持把 Universal 应用向下部署到 macOS 12 及更高版本。² 其三，一旦某个构建目标的 macOS 或 DriverKit 部署目标达到 27.0，ARCHS_STANDARD 就不再包含 x86_64。¹
• 只有第三项会改变您实际交付的产物，而且改变时不给任何提示。Apple 在同一条记录里就给出了补救办法：“如有需要，可以把 x86_64 架构添加到 ARCHS 构建设置中。”¹
• 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；而在项目层级解析构建设置，会让一个默认构建目标为 iOS 的项目藏起两个 macOS 构建目标。¹⁴
• 我的 11 个 Xcode 项目共 44 个构建目标：其中 21 个面向 macOS 构建，最高的 macOS 部署目标是 26.5，没有任何一个设置了 ARCHS 或 EXCLUDED_ARCHS。¹⁴ 磁盘上全部 51 个 macOS 归档都是 x86_64 arm64。¹⁴
• Intel 软件的终点落在 macOS 28，而不是 Xcode 27；Apple 的原话还留了一个值得细读的例外：“所有基于 Intel 的软件将不再兼容 macOS 28.0，旧版游戏除外。”¹⁰

以上内容全部出自测试版文档——Xcode 27 beta 4 与 macOS 27 beta 4 的发行说明。³⁶

三句话，三项不同的变更

Apple 的 Intel Deprecation 一节只有两条记录。把它们当成同一个论断来读，会在两个方向上都做出错误决定。

弃用那一条说的是您桌上的机器，措辞不留余地：“Xcode 27 只能安装并运行在 Apple silicon Mac 上。”² 没有任何构建设置能调整这一点。Intel Mac 不再是能运行当前版本 Xcode 的机器；Apple 的兼容性表格还在硬件门槛之上加了一道软件门槛——Xcode 27 beta 4 要求 macOS Tahoe 26.4 或更高版本。⁴

同一条记录接着保护了产物：“macOS 27 SDK 支持将 Universal（Intel 与 Apple Silicon）应用向下部署到 macOS 12 及更高版本。”² Apple 的兼容性表格与此一致：Xcode 27 beta 4 的 macOS 部署范围是 12 到 27，Xcode 26.6 则是 11 到 26.5。⁴ 下限恰好上移了一个大版本。Universal 二进制并未消失。

这一条最后还保住了工作流本身：“在 macOS 27 这类支持 Rosetta 的 macOS 版本上，Intel 开发仍然可行。”²

接下来是“新功能”那一条——真正有能力改变您已经在发布的产品的，正是它：

最低部署目标设为 macOS 27.0 或 DriverKit 27.0 的构建目标，将不再默认构建为 Universal。当 MACOSX_DEPLOYMENT_TARGET 或 DRIVERKIT_DEPLOYMENT_TARGET >= 27.0 时，ARCHS_STANDARD 构建设置将不再包含 x86_64。如有需要，可以把 x86_64 架构添加到 ARCHS 构建设置中。¹

这里有四个细节值得拆开来看。其一，Apple 只点名了两个构建设置，别无其他，因此 IPHONEOS_DEPLOYMENT_TARGET 及其同类不在此规则之内。其二，Apple 给出的是一个阈值，而不是某个工具链版本，触发条件是您自己的部署目标越过 27.0。其三，Apple 的措辞是“不再默认构建为 Universal”，描述的是默认值，而非禁令。其四，Apple 在同一口气里就给了出口，明确指出把 x86_64 放回去的位置是 ARCHS。

不报错也会变的默认值

机制本身平平无奇，而这恰恰是它悄无声息的原因。Apple 的构建设置参考文档这样描述 ARCHS：“产品将要构建的架构列表。通常设为平台提供的预定义构建设置。如果指定了多个架构，就会生成通用二进制文件。”⁵ 那个预定义设置就是 ARCHS_STANDARD；Apple 在同一份文档的另一处也印证了这层依赖关系——指针认证“如果 ARCHS 被覆盖为不基于 ARCHS_STANDARD，则不产生任何效果”。⁵

于是，从未提及 ARCHS 的构建目标，平台给什么就继承什么。改变平台给出的内容，产物的形态随之改变——而版本控制下的任何文件都不需要动一行。

这项变更不会引发任何失败。编译器照常运行，链接器照常运行，归档也能通过校验。工具链里没有任何环节会把只含 arm64 单一切片的 macOS 构建视为错误——因为它本来就不是错误。结果是一个正确、已签名的 macOS 应用，只不过原先两个架构切片如今只剩一个。在 Apple silicon Mac 上——如今每一位 Xcode 27 开发者按规定都在用的机器——纯 arm64 构建照样启动，行为毫无二致。这次退化只会在早已不在场的那类硬件上显形。

把这种失效方式称作“无声”是我的判断，不是 Apple 的说法；Apple 只描述默认值，说完即止。Apple 确实讲清了修复方式是“添加”，而这个措辞对做规划的人很关键：“如有需要”，可以把 x86_64 添加到 ARCHS 构建设置中。¹ 至于是否“需要”，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 应用上，返回两行：¹⁴

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

两行都要读，绝不能只读一行。那个项目声明的是 SDKROOT = macosx，工程文件里根本没有 SUPPORTED_PLATFORMS 这一行，所以在工程文件里做文本搜索找 SUPPORTED_PLATFORMS，会给它记零分，直接漏掉我名下唯一一个纯 macOS 应用。¹⁴ 解析后的构建设置会从 SDK 补上这处空缺，grep 做不到。这一步先别管 MACOSX_DEPLOYMENT_TARGET，因为无论如何 Xcode 都会给出一个值：我有三个纯 iOS 项目照样报告了 macOS 部署目标，两个是 26.5，一个是 26.2。¹⁴

第二种习惯，是在项目层级解析构建设置。不带 -target 的 xcodebuild -showBuildSettings 只回答某一个构建目标的情况，混合型项目会把其余的埋起来。我的 Safari 扩展项目解析出的是 SUPPORTED_PLATFORMS = iphoneos iphonesimulator 和 ARCHS_STANDARD = arm64，读起来像是一个毫无 Intel 暴露面的纯 iOS 项目。把构建目标逐一列出来，才发现总共四个，其中两个面向 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 的构建目标，在您指明 SDK 之前解析不出 ARCHS_STANDARD。我那 21 个 macOS 构建目标里有 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。¹⁴ 元数据缺失说明归档的写入方式不同，并不代表应用少了一个切片。

11 个项目里到底装着什么

我对 11 个 Xcode 项目、共 44 个构建目标做了一遍排查。8 个项目至少包含一个 macOS 构建目标，21 个构建目标面向 macOS 构建，而目前对新默认值的暴露面为零。¹⁴

这批项目里最高的 macOS 部署目标是 26.5，最低的是一个很久没人再碰过的 Safari 扩展上的 13.0。没有一个构建目标越过 27.0，因此在有人手动把某个数字调高之前，也没有一个构建目标会进入新默认值的辖区。设置了 ARCHS 的构建目标为零，设置 EXCLUDED_ARCHS 的也是零，而且这批项目里连一个 .xcconfig 文件都没有——44 个构建目标中的每一个架构决策，都来自 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 文档直接给出了时间范围。作为面向 Intel 应用的通用工具，Rosetta“旨在让向 Apple silicon 的迁移更轻松，并将持续提供到 macOS 27”；而“在此时间范围之后，我们将保留 Rosetta 的一个功能子集，用于支持依赖 Intel 框架的、无人维护的旧版游戏”。⁷ macOS 27 发行说明以同样的例外条款陈述了后果：“所有基于 Intel 的软件将不再兼容 macOS 28.0，旧版游戏除外。”¹⁰ 同一份发行说明中另一处仅限测试版的命令，给这项例外勾出了形状：sudo game-test-tool enable 会开启旧版 Intel 游戏支持，而 Apple 警告说“启用旧版游戏支持会禁用 Rosetta”。¹⁵

macOS 27 用这段过渡期点名那些活不下去的东西。Apple 的 Deprecation Information 一节写道，“在 macOS 28.0 中将无法再运行的基于 Intel 的应用程序，现在会在‘显示简介’中显示相应标示”；另有一条补充说，“‘设置 > 通用’现在会列出将与 macOS 28.0 不兼容的基于 Intel 的应用”，其中也包括“在系统上发现的、未被使用的基于 Intel 的软件”。⁸⁹

还有三条不那么显眼的记录，对任何在发布 Mac 产品的人来说更为要紧。

首先，Rosetta 本身不再“粘着”：“若此前已安装 Rosetta，升级到 macOS 27.0 后不会自动恢复。”¹¹ Apple 的文档给出了背景：macOS 27“直接集成了对 Intel 二进制转译的支持，无需安装 Rosetta”，用以服务 ARM 虚拟机中的 Intel Linux 二进制文件以及 Intel Linux 容器。⁷ 用户此前固定过的应用也会变：之前被设为“使用 Rosetta 打开”的应用程序，如今“将以原生方式启动”；Apple 建议“过去任何需要 Rosetta 的兼容性问题，都应在 macOS 27 上重新评估”。¹²

其次，安装器的默认值变了：“未指定 hostArchitecture 的安装包现在将默认为 arm64”，Apple 要求您“确保所有安装前和安装后脚本在 arm64 下的行为符合预期”。¹¹ 任何在 App Store 之外分发的 Mac 产品都会继承这一条，与其应用是否为 Universal 无关。

第三，插件宿主这一条最为锋利。Apple 警告说，“基于 Intel 的插件和加载器可能不会出现在‘设置’中，也不会触发不兼容通知”，并点名了需要手动检查的目录，包括 ~/Library/Audio/Plug-Ins/、~/Library/Printers/ 和 ~/Library/ColorPickers/。¹⁰ 一个插件为何能拖住一个本来就是原生的应用，答案在 Apple 的 Rosetta 文档里：“系统不允许在同一个进程中混用 arm64 代码和 x86_64 代码。Rosetta 转译作用于整个进程，包括该进程动态加载的所有代码模块。”⁷ 因此，一个 Intel 插件会迫使宿主整体以转译方式运行，把一个无人维护的组件变成整个应用对某项设施的依赖——而这项设施已被 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 应用吗？

不会。在把 Intel Mac 作为开发机器弃用的同一条记录里，Apple 说的恰恰相反：“macOS 27 SDK 支持将 Universal（Intel 与 Apple Silicon）应用向下部署到 macOS 12 及更高版本。”² Apple 的兼容性表格也印证了这个范围，把 macOS 12 到 27 列为 Xcode 27 beta 4 的部署目标。⁴ 变的是默认值。macOS 部署目标达到 27.0 的构建目标，不再从 ARCHS_STANDARD 拿到 x86_64；Apple 给出的修复办法是自己把 x86_64 加进 ARCHS。¹ 发布 Intel 版本从此是一个需要您声明的选择，而不再是继承来的结果。

如果 ARCHS_STANDARD 去掉了 x86_64，我的构建会失败吗？

Apple 那条记录里没有任何地方描述错误、警告或任何形式的诊断信息。Apple 描述的是默认值的变化：macOS 或 DriverKit 部署目标在 27.0 及以上的构建目标“将不再默认构建为 Universal”。¹ 用一个架构切片而非两个完成编译、链接与签名的构建，是完全有效的构建；而在 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 只能安装并运行在 Apple silicon Mac 上。”² Apple 还在硬件门槛之上加了一道软件门槛，要求 Xcode 27 beta 4 运行在 macOS Tahoe 26.4 或更高版本上。⁴ Intel 开发在旧工具链上仍能存活，Apple 也是这么表述的：“在 macOS 27 这类支持 Rosetta 的 macOS 版本上，Intel 开发仍然可行。”² Apple 的 Rosetta 文档给这条路划了边界：作为通用工具，Rosetta“将持续提供到 macOS 27”，此后只保留一个缩减后的子集，面向无人维护的旧版游戏。⁷

关键要点

面向 macOS 应用开发者： - 先在不带 -sdk 参数的情况下排查，把 SUPPORTED_PLATFORMS 和 SDKROOT 放在一起读；在判断某个构建目标究竟是否面向 macOS 时，忽略 MACOSX_DEPLOYMENT_TARGET。Xcode 会往纯 iOS 项目里写入 macOS 部署目标：我有三个项目都报告了一个（26.5、26.5 和 26.2），却不为任何 Mac 构建。¹⁴ - 在解析构建设置之前，先用 xcodebuild -list 把构建目标逐一列出。对我的 Safari 扩展做项目层级查询，结果报告的是一个纯 iOS 项目，藏起了两个 macOS 构建目标。¹⁴

面向用户中仍有 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 插件和安装包，而不只是应用。Apple 警告说 Intel 插件“可能不会出现在‘设置’中”，而一个 Intel 插件会迫使整个宿主进程以转译方式运行。⁷¹⁰

27 这一轮周期总把影响深远的变更藏在毫不起眼的地方。链接器的移除与模块名规则会在升级工具链时直接让构建失败，@State 宏在源码层面把构建打断，启动屏幕键则会卡住一次提交。而 Intel 默认值什么都不会弄坏，却照样改变了产物——正因如此，值得在升级之前而不是之后排查一遍。完整的系列入口是 Apple 生态系统系列。

参考资料