macOS 27 下 Mac App 还要保留 Intel 版吗？2026

Apple 于 2026 年 9 月 9 日说明，macOS 27 面向 Apple silicon，macOS 26 是最后支持 Intel Mac 的系统版本。(Apple Developer 公告) 这不等于开发者必须立即删除 Intel 版：只要仍承诺支持运行旧版 macOS 的 Intel 用户，就保留并验收通用二进制；只有在明确结束这项支持、且依赖和分发链路验证通过后，才考虑只发布 arm64。

本周建议动作：先列出仍承诺支持的 macOS 版本和用户，再检查发布包中每个可执行组件的架构；不要只因 macOS 27 转向 Apple silicon，就直接改成 arm64-only。

仍有 Intel 用户的 macOS App 开发者：判断是否继续维护 x86_64，以及相应测试责任。
已有 Apple silicon 版本、准备支持 macOS 27 的开发者：核对 arm64 构建、第三方依赖和交付物。
需要安排发布环境的小团队：确认构建环境能否验证目标架构；构建通过不等于已覆盖真实用户设备。

macOS 27 的运行硬件范围与你是否支持旧系统上的 Intel 用户是两件事。前者由系统支持范围决定，后者是产品发布政策：如果仍承诺让 Intel Mac 用户在受支持的旧版 macOS 上使用应用，删除 x86_64 就会与承诺冲突。

还要谨慎看待 Rosetta 的边界。Apple Developer 在 2026 年 9 月 9 日的公告称 macOS 26 是最后支持 Rosetta 的版本；另一则 2026 年 9 月 1 日公告则称 macOS 27 是 Rosetta 的最后支持版本。两则公告措辞不一致，因此不要据此把 Rosetta 视为 macOS 27 或后续系统上的稳定兼容保证；发布计划应以 Apple 更新后的说明和目标系统实测为准。

因此，决策应从用户支持矩阵开始，而不是从 Xcode 的默认架构开始：明确哪些 Intel 机型、系统版本和应用版本仍在支持范围内，再判断要交付哪种架构。macOS arm64 是 Apple silicon 原生运行所需的架构切片；它不会自动替代旧系统上 Intel 用户需要的 x86_64 切片。

通用二进制通常包含 arm64 与 x86_64 两种架构切片，系统按运行设备选择相应切片；仅含 arm64 则是主动放弃 Intel 设备支持的发布选择。Apple 的通用 macOS 二进制构建说明指出，构建通用二进制时会分别编译各架构，再合并对应产物。

架构审计不要止步于主 App。我们建议把这些项目逐项列入发布检查：

• App 主可执行文件、插件、动态库和辅助进程。
• 内置命令行工具、安装脚本及自编译依赖。
• 闭源 SDK、第三方插件，以及运行时才加载的组件。
• 下载器或更新器实际分发的文件，而不只是 Xcode 项目中的源码。

仅 x86_64 的第三方库不能因主 App 已编译成功，就视为兼容 arm64。Apple 对多平台二进制框架包 XCFramework 的说明要求依赖所需的平台和架构由相应二进制变体覆盖；应向供应方确认具体产物，或用 file 检查库文件。若依赖无法提供目标架构版本，先评估替换、拆分或延续旧架构，不要未经运行验证就切到 arm64-only。

Xcode 的 ARCHS 决定构建目标架构；设置为多个架构时可以产生通用二进制，但项目设置不等于最终安装包一定符合预期。Apple 的Xcode 构建设置参考说明了 ARCHS 的作用；Xcode 27 发布说明还指出，当最低部署目标设为 macOS 27 时，标准架构不再默认包含 x86_64。若仍需要 Intel 切片，必须检查项目设置和最后生成的产物，而不是依赖旧工程行为。

可按以下步骤完成发布前核对：

1. 记录支持范围。 写明仍支持的 macOS 版本、Intel 用户承诺、最低部署目标和这次发布要改变的范围。
2. 清理构建并归档。 使用正式发布配置重新构建，保存 Xcode 版本、SDK、构建目标和归档文件，避免拿调试构建代替发布产物。
3. 检查主可执行文件。 从 .app/Contents/MacOS/ 中定位实际二进制，运行 lipo -archs /路径/到/可执行文件，确认所需架构切片确实存在。
4. 检查嵌入组件。 对插件、动态库、辅助进程和命令行工具逐个检查；若依赖采用 XCFramework，也要核对被实际链接或打包的变体。
5. 分别运行关键路径。 在适当的 Apple silicon 和 Intel 环境测试启动、登录、核心功能、更新与安装流程；有架构专属代码时，专门触发相应分支。
6. 复核最终分发包。 检查签名后的 App、安装包或下载文件，确认构建产物、发布渠道和版本说明一致，并记录每个测试环境的设备架构、系统版本、目标架构和结果。

Apple 的通用 macOS 二进制构建说明也区分了“可以构建”和“可以在该设备调试”：Apple silicon Mac 能运行原生 arm64，也可在 Rosetta 支持范围内运行 x86_64 切片；Intel Mac 则不能运行或调试 arm64 切片。架构检查证明文件包含哪些切片，却不能替代目标设备上的启动和功能测试。

macOS 27 上还能运行 Intel 版 App 吗？

macOS 27 面向 Apple silicon，因此 Intel Mac 本身不能运行 macOS 27。对于只含 x86_64 的应用是否能通过 Rosetta 在 Apple silicon 上运行，Apple Developer 的公告对 Rosetta 结束边界存在上述措辞差异；不要把单次启动成功当作长期支持承诺。优先发布 arm64，针对既有版本和目标系统做实测，并复核 Apple 的另一则 Rosetta 公告。

只发布 arm64 会影响哪些用户？

影响对象首先是仍在你的支持范围内、使用 Intel Mac 的用户；他们需要兼容的旧版应用，不能执行只含 arm64 的主程序。还要检查你的发布包是否包含必须在同一进程加载的 x86_64 插件或库。若决定结束 Intel 支持，应同步调整兼容说明、旧版下载和用户通知，而不是只改构建设置。

怎样确认通用二进制包含 Intel 架构？

对最终归档中的可执行文件运行 lipo -archs，查找 x86_64 与 arm64；再逐个检查插件、动态库、辅助进程和内置工具。Apple 的Apple silicon 应用迁移指南建议在创建通用版本后分别测试两种架构。检查结果应与实际设备运行记录一起留档。

第三方库暂时没有 arm64 版本，App 还能发布吗？

可以继续评估发布，但不能假设它能被 arm64 进程加载。如果库是 Intel-only，而应用在 arm64 模式下必须加载它，就需要先寻找 arm64 版本、替代库或可行的隔离方案；否则应保留已验证可运行的发布路径，并清楚限定支持范围。XCFramework 的名称本身也不是兼容证明，应检查实际包含的平台和架构。

按以下分支做决定，不必把“保留双架构”或“改成 arm64”当成所有项目的统一答案：

• 若仍承诺支持旧版 macOS 上的 Intel 用户，且 x86_64 依赖和测试环境可维护：保留通用二进制，并继续验收 Intel 路径。
• 若 Intel 用户仍在支持范围，但某个第三方依赖缺少所需切片：先修复或替换依赖；在确认整套交付物可用前，不要切换到 arm64-only。
• 若产品政策已明确结束 Intel 支持，用户通知与旧版分发安排完成，且 arm64 依赖、安装和运行均已验证：再将仅发布 arm64 纳入发布决策。
• 若只有构建成功记录，没有目标设备上的运行和关键功能结果：继续视为验收未完成，不要把它当作双架构发布通过。

对小团队来说，隐性成本不只是一份额外切片：还包括依赖升级时的双架构排查、旧系统回归、插件故障定位和用户支持承诺。另一方面，删除 Intel 切片也会带来用户迁移、旧版本维护和发布说明调整。我们建议把这些成本与实际支持义务一起评估，不以未经核实的用户占比或性能收益替代证据。

若团队没有可用的 Apple silicon Mac，可先确认构建环境是否支持所需的 Xcode 工具链，再用实际项目验证依赖解析、架构产物、签名和运行路径。Apple 的Xcode 27 发布说明可用于核对工具链与架构默认行为；Apple silicon 上的构建测试仍不能替代 Intel 设备覆盖测试。

如果现有方案是借用团队成员的 Mac 或临时调整发布设备，可能遇到环境不可控、构建记录不完整、无法重复测试等问题；添置专用 Mac 又意味着设备采购与持续维护成本。若需要一段时间内可控的 Apple silicon 构建环境，可以了解 JEXCLOUD 的远程 Mac 方案，并在选择前核对 Xcode 可用性、访问方式和自己的项目能否完成验收；确有需求时，再查看 远程 Mac 使用方案。它适合补充临时构建或验证资源，但不能自动替代 Intel 实机测试，也不一定适合长期稳定重负载或必须接触本地物理接口的工作流。

最后更新于 2026 年 10 月 16 日；系统支持与架构结论核对自 Apple Developer 的 macOS 27 公告、Rosetta 公告、通用二进制文档、Xcode 27 发布说明及构建设置资料。