macOS 27 Golden Gate 9 月发布:留给 Mac 工具厂商的纯 ARM64 过渡期,开始进入收尾

macOS 27 Golden Gate 9 月发布:留给 Mac 工具厂商的纯 ARM64 过渡期,开始进入收尾

当一个操作系统的底层架构切换进入”收尾阶段”,真正被逼到墙角的不是用户,而是那些还在靠翻译层续命的工具厂商。

2026 年 6 月 9 日 WWDC 上,苹果预览了 macOS 27 “Golden Gate”(金门)。7 月 13 日开放公测,7 月 22 日已推送第二个公测版本,正式版预计 9 月随秋季新品一同推送。

这版系统有一个绕不开的标签:首个仅支持 Apple Silicon 的 macOS。Intel Mac 彻底出局,连 Rosetta 2 也进入了生命周期的最后阶段。

对普通用户来说,这或许只是一次系统升级。但对 Mac 工具软件厂商来说,一个悬在头顶六年之久的靴子终于落地了——纯 ARM64 适配,从”建议做”变成了”不做就得死”。

这不是危言耸听。这是一道有明确截止日期的算术题。


一、时间线:苹果给的缓冲期,已经用完了

先把关键节点捋清楚:

时间事件
2020 年 11 月M1 芯片发布,Rosetta 2 同步推出,Intel→ARM 过渡开始
2026 年 6 月 9 日WWDC 2026,macOS 27 Golden Gate 预览发布
2026 年 7 月 13 日macOS 27 Public Beta 1 开放公测
2026 年 7 月 22 日macOS 27 Public Beta 2 推送
2026 年 9 月macOS 27 正式版预计发布(秋季)
2026 年 9 月macOS 27 是最后一版完整支持 Rosetta 2 的系统
2027 年末(late 2027)macOS 28 发布,Rosetta 2 通用功能移除(CodeWeavers 官方博客引用苹果计划)

六年过渡期,够不够?对 Adobe、微软这种大厂来说早就够了。但对大量独立开发者、行业软件厂商和硬件驱动供应商来说,这个窗口正在以肉眼可见的速度关闭。


二、为什么说”纯 ARM64 适配”是真命题

有人可能会说:Rosetta 2 不是到 macOS 28 才彻底移除吗?还有一年多时间,急什么?

这个说法有三个盲区。

1. macOS 27 已经完全不支持 Intel Mac

Golden Gate 是首个完全不支持 Intel Mac 的 macOS 版本:

  • MacBook Neo(A18 Pro,2026)
  • MacBook Air(Apple Silicon,2020 及以后)
  • MacBook Pro(Apple Silicon,2020 及以后)
  • iMac(Apple Silicon,2021 及以后)
  • Mac mini(Apple Silicon,2020 及以后)
  • Mac Studio(2022 及以后)
  • Mac Pro(Apple Silicon,2023 及以后)

macOS Tahoe(26)支持的最后几款 Intel 机型——2019 款 MacBook Pro 16 寸、2020 款 iMac、2019 款 Mac Pro——全部被砍。

这意味着:如果你的工具软件只有 x86_64 版本,从 macOS 27 开始,你在 Intel Mac 上跑不了新系统,在 Apple Silicon Mac 上只能靠 Rosetta 2 跑翻译版。两头不讨好。

2. Rosetta 2 在 macOS 27 中的角色已经变了

macOS 27 仍然是最后一版完整支持 Rosetta 2 的系统。CodeWeavers 在 2026 年 6 月 19 日的官方博客中确认:

“In late 2027, macOS 28 will drop support for Rosetta, Apple’s translation framework for Intel applications. This change will directly impact PortJump applications.”

更关键的信号是 XCode 27 本身的配置变化。Xcode 27 只能在 Apple Silicon Mac 上安装和运行,当 macOS 部署目标设置为 27.0 及以上时,ARCHS_STANDARD 默认不再包含 x86_64——编译 Universal Binary 从默认行为变成了需要手动声明的事情。

苹果的原话是:”macOS 27 SDK 支持向后部署 Universal 应用到 macOS 12 及以后。” 但默认架构的变化传递的信号很明确:Intel 不再是默认目标。

3. 插件问题是隐藏的定时炸弹

这是最容易被忽视的一点。苹果的 Rosetta 文档明确写道:

“系统不允许在同一个进程中混合 arm64 代码和 x86_64 代码。Rosetta 翻译应用于整个进程,包括该进程动态加载的所有代码模块。”

这意味着:即使你的主程序已经是 Universal Binary,只要有一个 Intel 插件被加载,整个应用就会被强制以 Rosetta 翻译模式运行。一个没适配的音频插件、打印驱动、Photoshop 扩展,就能把一个已经原生化的应用拖回翻译模式。

苹果特别提醒开发者手动检查 ~/Library/Audio/Plug-Ins/~/Library/Printers/ 等目录。VST 2 格式插件尤其危险——它从未原生支持 Apple Silicon,完全依赖 Rosetta 运行。


三、行业已经行动:这些厂商在做什么

当苹果还在给缓冲期的时候,头部工具厂商已经开始动手了。这些案例恰恰证明了”纯 ARM64 适配”不是一个伪命题——而是行业已经在执行的迁移计划。

CrossOver 27:全面转向 ARM64 原生

CodeWeavers 在 2026 年 7 月 31 日正式发布了 CrossOver 首个 ARM64 原生预览版。 CrossOver 27 关键信息:

  • 基于 Wine 11 引擎,仅支持 Apple Silicon Mac,放弃 Intel Mac 支持
  • Intel 用户可继续使用 CrossOver 26
  • CodeWeavers 已经在为 macOS 28 做准备——他们的 PortJump 工具会受影响
CrossOver 软件介绍与安装使用教程

Oracle JDK 27:停止维护 macOS x64 端口

2026 年 6 月 5 日,Oracle JVM 高级总监 Mikael Vidstedt 提交了 JEP draft 8386091:Deprecate the macOS/x64 Port for Removal

JEP 提案指出:

“Apple 已经将其硬件平台迁移至 AArch64,因此正在逐步淘汰对 x64 的支持。维护该端口是一项相当庞大的工程投入,目前也没有明确的长期维护承诺。”

这是继苹果宣布结束 Intel Mac 生命周期后,又一家重要开发者平台正式退出支持。Java 生态的 Intel Mac 用户将面临无法编译、运行最新 JDK 的风险。

Xcode 27:开发工具本身只认 Apple Silicon

Xcode 27 只能在 Apple Silicon Mac 上安装和运行。Xcode 27 beta 3 在 6-9 WWDC 同步推送,6-12 推出了 CrossOver 26.2(注意:不是 27),Xcode 27 默认打包仅输出 arm64 Apple Silicon 安装包,x86 打包选项默认隐藏(来源:多多软件站 macOS Golden Gate 27 官方介绍页)。

苹果的原话是:”macOS 27 SDK 支持向后部署 Universal 应用到 macOS 12 及以后。” 但默认架构的变化传递的信号很明确:Intel 不再是默认目标

独立开发者:有人在赶工,有人已完成

EagleFiler 的开发者 Michael Tsai 正在重写应用以完全原生支持 Apple Silicon。新版将作为全新购买,老用户享 50% 折扣。

而备份工具 SuperDuper! 4 已经完成了全面重写,原生支持 Intel 和 Apple Silicon 双架构。

Apple 自家全家桶:7-11 那一周集中切完

Apple 自家的”全家桶”——Xcode、Logic、Final Cut Pro、Pixelmator——都在 7-11 那一周前后集中切完 ARM64:

  • Xcode 27 beta 3 — 2026-06-09 WWDC 同步推送
  • Logic Pro 12.3 — 2026-07-11 发布(AI 增强)
  • Final Cut Pro 12.3 — 2026-07-11 发布(AI 工具全量上线)
  • Pixelmator Pro 4.3.0 — 2026-07-20 分发(Apple 官宣 7-12)
  • Microsoft Office LTSC 2024 for Mac 16.110 — 2026-06-17 发布(原生 ARM64)
  • WPS Office for Mac 12.1.26035 — 2026 夏季更新(金山办公)

四、谁还没准备好?最危险的几类

以下几类软件是迁移高风险区:

打印机驱动——打印机厂商几乎没有经济动力去更新驱动软件,很多老旧打印机在 macOS 28 之后将无法使用。

行业专用软件——苹果社区讨论中已有大量用户反映,许多行业专用软件、老旧插件和内部工具仍依赖 Rosetta 2 运行,迁移难度远超预期。

音频/视频/图像插件——即使宿主软件(如 Logic Pro、Photoshop)已经是 Universal,第三方插件如果还是 Intel 版本,会强制整个应用以 Rosetta 模式运行。苹果特别提醒开发者手动检查 ~/Library/Audio/Plug-Ins/~/Library/Printers/ 等目录。VST 2 格式插件尤其危险,因为它从未原生支持 Apple Silicon,完全依赖 Rosetta 运行。

付费软件的版本授权问题——Capture One 等应用可能需要购买新版本授权才能在 macOS 28 上继续使用。对用户来说,这意味着可能要为一款已经买过的软件再付一次费。

开源项目中的 x86_64 专用代码——涉及 AVX、AVX2、AVX512 指令集的代码在 ARM 上没有对应指令,Rosetta 2 无法翻译。这类问题在高性能计算、机器学习框架中比较常见。


五、给 Mac 工具厂商的建议

如果你是 Mac 工具软件的开发者或决策者,现在是做决断的时候了。

时间节点

  • 2026 年 9 月:macOS 27 发布,Intel Mac 彻底不支持新系统。Rosetta 2 仍可用,但 macOS 28 已经是看得见的终点。
  • 2027 年末(late 2027):macOS 28 发布,Rosetta 2 通用功能移除(CodeWeavers 引用苹果计划)。这是硬截止日期。

迁移路径

1. 审计:用 lipo -archs 检查所有二进制文件和插件,确认哪些还是纯 x86_64。macOS 27 的系统设置中新增了”基于 Intel 的应用”列表(System Settings > General > About > System Report > Software > Rosetta Software),可以查看所有需要 Rosetta 的应用。

2. 优先级排序:先迁移被高频使用的核心组件,再处理边缘功能。特别注意插件目录——一个 Intel 插件会拖垮整个 Universal 应用。

3. 编译适配:在 Xcode 27 中,如果部署目标设为 27.0+,需要手动在 ARCHS 中添加 x86_64 才能继续产出 Universal Binary。如果决定只做 ARM64,确认部署目标覆盖足够用户。

4. 测试:在 macOS 27 Golden Gate beta 上做全面回归测试。Golden Gate 移除了 Boot Camp、AFP 协议、Time Capsule 支持,如果你的工具有依赖这些功能的代码,需要提前适配。

5. 用户沟通:提前告知用户迁移计划。是否需要重新购买?老版本能用到什么时候?这些问题的答案直接影响用户留存。

如果实在无法迁移

  • 留在 macOS 27 是最稳妥的选择,但意味着无法获得新系统功能和安全更新。
  • 考虑开源替代方案或切换到其他平台。
  • 对于企业内部工具,可以评估通过 Linux+UTM 虚拟化方案延长使用寿命。

六、结论:真命题,不是狼来了

“Mac 工具厂商必须适配纯 ARM64”这句话,在 2020 年 M1 发布时是”建议”,在 2025 年 WWDC 苹果通知开发者时是”预警”,在 2026 年 9 月 macOS 27 发布时是”最后通牒”。

这不是媒体炒作的焦虑。当你看到 CrossOver 在重写整个 Wine 兼容层、Oracle 在砍掉 JDK 的 x64 端口、Xcode 在默认架构里悄悄移除 x86_64——这些都是行业头部玩家用行动投的票。

苹果自己也给了足够多的信号:从 26.4 版本的弹窗警告,到 27 版本的自动卸载 Rosetta,再到 28 版本的彻底移除。每一步都在缩短缓冲期。六年过渡期,够长了。

有意思的是,8 月 9 日彭博社曝出的苹果自家芯片路线图,方向也一致:M6 系列被砍掉 Pro、Max、Ultra 三个高阶版本,团队资源集中压向新一代 M7,按计划 2027 年春季面世,顶配 M7 Ultra 直接对标英伟达专业 AI 加速芯片。

苹果自己都不等 Pro、Max、Ultra 这条线了——它把赌注压在 ARM64 的下一个台阶上。

macOS 28 预计 2027 年末发布——从现在算起,大约还有 14 个月。而 14 个月之后,macOS 28 桌面上的 Rosetta 2 将完全消失。 一个还在用翻译层续命的工具,能不能让老用户正常打开,能不能给新用户交代一个能用的 ARM64 版本——这些问题的答案,要从 9 月那个整点之后的工作日开始算。

编辑于 2026-08-09 · 著作权归作者所有