AI大力出奇迹，黑苹果或将迈入全新时代。

前言

注：本文提纲由人类手工撰写，由 AI 成文，有删改。

2026年，对于黑苹果（Hackintosh）玩家来说，原本应该是一个逐渐告别的年份，至少几个月前我也是这么认为的。

随着 macOS 27 Golden Gate 正式迈入 Apple Silicon 时代，苹果终于彻底关上了 Intel Mac 的升级大门。曾经依靠 Intel 处理器、AMD 显卡以及 OpenCore 引导工具搭建起来的黑苹果生态，似乎已经走到了命运的十字路口。没有了新版本 macOS 的官方适配，开发者失去了持续追赶的目标，普通玩家也逐渐失去了继续折腾的动力。曾经那个只要硬件选得对、EFI 配得好，就能用相对低廉的成本获得 macOS 完整体验的时代，看起来确实正在成为过去式。

然而，谁又能想到，剧情竟然在这个时候出现了反转？

AI，这个过去两年里被反复讨论、一度让不少人感到焦虑的技术，正在以一种近乎不讲道理的速度改变开源软件的开发方式。从让 NVIDIA RTX 显卡重新获得 macOS 图形加速，到尝试让 Intel Mac 运行 ARM64 原生应用，再到让骁龙 X2 Elite 笔记本启动最新一代 macOS，乃至在小米、POCO 等安卓手机上运行真正的 iOS 系统……这些如雨后春笋般冒出的项目，共同指向了一个令人兴奋的可能性：当 AI 成为开发者手中的超级杠杆，曾经被苹果硬件架构和软件生态牢牢锁死的边界，或许正在被一点一点撬开。

这一次，我们先不急着给黑苹果盖棺定论。

Intel 时代落幕，黑苹果真的走到了尽头？

经常安装黑苹果的朋友都知道，这个圈子能够发展起来，核心前提其实非常简单：苹果使用了与普通 PC 相近的硬件架构。

从早期的 Intel Mac，到后来的酷睿 i 系列，再到桌面级高性能处理器和 AMD 显卡，黑苹果玩家通过 ACPI 补丁、驱动、设备属性注入以及 OpenCore 等引导工具，让原本并不在苹果官方支持名单中的 PC 硬件，也能运行 macOS。

这套玩法并不轻松，但它有一个明显的优势：底层硬件架构相同。苹果官方使用什么型号的 Intel 处理器，玩家就尽量寻找相近的 CPU；苹果官方支持什么显卡，玩家就研究显卡驱动和设备 ID；遇到电源管理、USB、声卡、睡眠唤醒等问题，再靠社区开发者提供的补丁逐个解决。

整个过程有点像玩一款难度极高的拼图游戏。只要拼图足够完整，一台普通 PC 就能变成一台相当能打的 macOS 电脑。

但苹果转向自研芯片之后，游戏规则已经发生了变化。

macOS Tahoe 26 仍然支持部分 Intel Mac，例如特定年份的 MacBook Pro、iMac 和 Mac Pro。不过，进入 macOS 27 Golden Gate，苹果公布的官方兼容机型已经全部采用 Apple Silicon 芯片。换句话说，Intel Mac 不再获得新一代 macOS 的官方升级支持。这里需要说明，停止大版本升级不等于旧系统立即停止安全维护，两者不能混为一谈。

参考：苹果官方 macOS 27 兼容性列表

对于传统黑苹果而言，这意味着什么？

首先，过去那条依靠 Intel 平台持续跟进新版本 macOS 的路线，已经失去了官方更新的支撑。其次，苹果与 PC 硬件之间的差异将不再只是设备 ID、驱动和电源管理的问题，而是进一步涉及启动链、处理器架构、硬件接口以及平台安全机制。

以前我们研究的是怎么让一台 PC 伪装得更像 Mac（正所谓“完美黑苹果”）；今后，某些探索可能需要考虑怎样让非苹果硬件满足 Apple Silicon 时代的系统运行条件。

这可不是给 config.plist 再添加几个参数就能解决的问题。到了这个地步，如果仍然完全按照过去的思路开发，黑苹果的前景确实不容乐观。但问题在于，今天的开发环境，已经不是十年前、五年前的开发环境了。

AI 力大砖飞，开源开发正在进入另一种节奏

如果一直关注 AI 编程，就会发现一个很有意思的变化。

早些年，我们谈论 AI 写代码，更多想到的是生成一个函数、补全几行语法，或者给一段已有代码提供修改建议。稍微复杂一点的需求，一旦涉及多个文件、底层系统调用、编译错误和硬件兼容性，AI 就很容易开始一本正经地胡说八道。

我永远忘不了去年的某一天，让 Sonnet 改一个 Bug，它前后忙活了十几分钟，报告我解决了问题，但我仔细一看：问题不仅没解决，还顺手制造了三个新 Bug；有时候我要求它修复编译错误，它甚至会把错误本身理解错。

那时候的 AI 编程，多少有些“能写，但未必能用”的味道。

不过，随着模型能力、上下文处理、代码检索、工具调用和自动化测试能力不断进步，AI 辅助开发正在变得更加实用。开发者可以让模型协助阅读庞大的代码库、分析调用关系、编写补丁、定位错误，再通过编译和实际测试不断迭代。

还有一个容易被忽略的变化：以往开源项目大概率得拥有几十人、上百人的团队，才有机会挑战复杂问题。因为要解决一个复杂问题，往往需要大量的时间去逐步分析，拆解，提出方案，执行修正，审计和复核，反复迭代。但随着 AI 的普及，一些项目转为由人数极少的核心开发者推动，它们的研发成本、组织方式和成熟度各不相同，就目前而言，一个人即是整个项目的情况越来越普遍。当一个个人或小团队能够借助 AI 和现有开源基础设施完成过去需要更多人力才能推进的工作时，某些原本只能存在于技术讨论中的设想，就有机会成为可以编译、运行和测试的代码。

这正是 AI 时代最值得关注的事情。对于黑苹果玩家来说，以下几个项目，已经足以让原本沉寂的社区重新热闹起来。

需要特别说明：下文提到的这些项目，并没有全部公开、可核实的 AI 使用记录，因此不能把它们一概称为“AI 编写的项目”。更准确的说法是，这些成果出现于 AI 编程工具快速发展的阶段，而 AI 有可能显著降低了部分开发工作所需的时间和人力成本。

NVIDIA RTX 显卡驱动：有生之年系列照进现实

项目地址：NullMoth NVIDIA macOS Driver

如果要选一个最容易让老黑苹果玩家破防的项目，我会把票投给它。

NVIDIA 显卡驱动曾经是黑苹果圈绕不开的话题。早年 NVIDIA 与 macOS 的图形驱动生态有过一段相对友好的时期，但随着苹果转向 AMD 显卡以及自研 Metal 图形技术，后续新一代 NVIDIA 显卡失去了官方驱动支持。（坊间主流的说法是，NVIDIA 研发人员声称已向苹果提交了新版本驱动，但苹果一直未审核通过。）

尤其对于手里拿着比较新的 RTX 显卡的玩家来说，想在 macOS 下获得完整的硬件加速体验，几乎是不可能的事情。

不是显卡性能不够，而是 macOS 根本不愿意跟它好好说话。

过去，我们经常看到这样的配置：CPU 性能爆炸，RTX 显卡在 Windows 下能打能扛，切换到 macOS 后却只能眼巴巴地看着它，要么把显卡拔下来当镇纸，要么再插一张 AMD 显卡。

现在，NullMoth 项目正在尝试改变这种局面。

根据项目公开文档，它的目标是为 macOS 提供 NVIDIA 显卡的 Metal 驱动支持，覆盖 NVIDIA Turing 及更新架构，包括 GTX 16 系列、RTX 20、30、40、50 系列等。项目主要围绕 RTX 5060 展开测试，同时也明确说明，其他显卡可能存在尚未发现的问题。

这并不是简单地修改一下显卡设备 ID，也不是给系统套一个能够显示显卡名称的假驱动。项目构建了相对完整的图形驱动链路：通过 Metal 驱动插件接收图形调用，将苹果的 AIR 着色器中间表示转换为 SPIR-V，再借助 Mesa 的 NVK Vulkan 后端及相关 NVIDIA 内核驱动组件访问 GPU。

通俗地讲，它尝试在 macOS 的图形接口与 NVIDIA GPU 之间搭建一座桥梁。

项目文档列出的目标能力包括 Metal 3 的部分功能、光线追踪、网格着色器，以及 OpenGL、OpenCL 等相关图形和计算能力。

这意味着什么？

如果它能够进一步完善并扩大适配范围，那么一些原本因为显卡不受支持而被迫停留在旧版 macOS 的 PC，就可能重新获得更有价值的系统使用场景。

对于那些已经投入大量资金购买高性能显卡的玩家而言，这甚至可能改变整台机器的 macOS 部署方式。

不过，先别急着把显卡驱动安装包下载下来，准备一键起飞。

目前这个项目仍然属于实验性方案，而且有明确的系统版本限制、硬件和配置要求。它要求调整 OpenCore 安全配置、加载内核扩展，并对部分系统安全机制进行放宽处理。驱动兼容性、稳定性以及不同 GPU 的表现，也需要持续验证。

此外，这套驱动目前针对的是 Intel 架构的 macOS 环境，包括 Sequoia 15 和 Tahoe 26，并不意味着它已经让 NVIDIA 显卡直接获得 macOS 27 Golden Gate 支持。

即便如此，单从技术方向来看，它已经足够令人兴奋。

以前我们讨论的是 NVIDIA 显卡还能不能用，现在至少有人试图让它重新拥有进入 macOS 生态的机会。

这就是开源项目最吸引人的地方：苹果不做的事情，社区未必只能选择放弃。

反向 Rosetta：Intel Mac 也要运行 ARM64 原生应用？

项目地址：Maclator

如果说 NVIDIA 驱动解决的是硬件兼容性问题，那么 Maclator 试图解决的，就是一个更棘手的问题：软件架构兼容性。

苹果从 Intel 处理器转向 Apple Silicon 时，曾经推出 Rosetta 2，让原本为 Intel 处理器编译的应用能够在 ARM 架构的 Mac 上运行。它的作用可以简单理解为：软件原本讲 x86_64 语言，现在由系统帮忙翻译成 ARM64 处理器可以理解的指令。这项技术对苹果完成架构转型发挥了非常重要的作用。

但现在，问题反过来了。未来越来越多的 macOS 应用可能只提供 ARM64 版本，Intel Mac 用户怎么办？难道只能抱着老版本应用继续使用，直到某一天彻底无法更新？

Maclator 的想法相当大胆：既然苹果可以通过 Rosetta 2 让 ARM Mac 运行 Intel 应用，那么能不能反过来，让 Intel Mac 运行 ARM64 macOS 应用？

注意，它不是将整个 ARM 版 macOS 安装到 Intel 电脑里，而是尝试为 ARM64 应用建立一个兼容运行环境。

按照项目文档，Maclator 可以加载 ARM64 Mach-O 程序及相应的 ARM64 macOS 用户态组件，再通过解释执行、x86_64 即时编译（JIT）等方式执行 ARM64 代码。系统调用和部分 Mach 陷阱则交给 Intel 宿主系统处理或模拟；Metal 调用还可以尝试通过图形桥接访问宿主 GPU。

项目已经列出一些经过验证的运行实例，包括 ARM64 版本的 VS Code、Chromium，以及能够启动的 balenaEtcher。其中，Chromium 的实验还展示了通过宿主 AMD 显卡实现图形加速的能力。

这就很有意思了。

如果未来 Intel Mac 真正进入官方大版本更新的历史，那么传统 x86_64 黑苹果也会面临类似的问题。即使通过某种方式解决了系统升级，应用又该怎么办？Maclator 给出了一种思路：不一定非要把操作系统整体搬到另一种架构上，也可以先从应用兼容层入手，逐步解决跨架构运行问题。

当然，目前它仍然是实验性研究项目，绝不是下载以后就能让所有 ARM 应用在 Intel Mac 上运行的万能工具。音频、相当一部分 IOKit 硬件接口、沙盒应用、部分依赖 Swift 的苹果应用，以及某些 Metal 图形路径，仍存在不同程度的未完成工作。而且，CPU 指令转换、系统调用模拟和图形接口桥接本身就意味着额外的开销，实际性能也会因应用和硬件而存在差异。

但我认为，它真正的价值不是现在就能跑多少软件，而是把一个过去听起来非常困难的问题，变成了一个已经可以实际运行、可以持续迭代的开源项目。从这个意义上来说，Maclator 不只是给 Intel Mac 延寿，也是在探索未来操作系统兼容层可能发展的方向。

骁龙笔记本启动 macOS 27：这才是真正的跨架构挑战

项目地址：Snapintosh

接下来这个项目，可能会让不少人直呼离谱。

前面的 NVIDIA 驱动，主要是在已有的 Intel 平台上补齐显卡支持；Maclator 也仍然需要 Intel 宿主 macOS 环境。而 Snapintosh 直接把目标瞄准了 Qualcomm Snapdragon X2 Elite 平台。

根据项目公开文档，Snapintosh 已经能够在搭载 Snapdragon X2 Elite X2E-96-100 的 ASUS Zenbook A16 笔记本上启动 macOS 27 Golden Gate，并进入带有 GPU 加速的桌面环境。再次强调，这是特定笔记本上的实验成果，并不代表所有骁龙处理器都已经能顺利运行 macOS。

这件事的技术难度，远远超过普通意义上的系统安装。

Apple Silicon 虽然采用 ARM 架构，但这不意味着随便找一颗 ARM 处理器，就能直接把 macOS 安装上去。苹果的系统依赖特定的启动流程、内核接口、内存管理、安全机制、设备树及硬件驱动。高通平台即便同样采用 ARM 指令集，在底层实现上也与苹果自研芯片存在大量差异。

Snapintosh 的做法，是通过项目自己的 EL2 监控器及配套工具，为 macOS 提供它期待的部分 Apple Silicon 平台运行条件，并针对骁龙笔记本开发相关的图形与设备驱动。项目还开发了 Adreno 图形驱动相关组件，试图让 Apple Metal 图形调用经过着色器转换后，在高通 Adreno GPU 上运行。

这不是简单地将系统安装包解包，再把几个驱动文件放进 EFI。它需要在系统内核、虚拟化层、设备接口以及图形驱动等多个环节开展工作。从项目状态来看，macOS 已经能够启动到桌面，图形加速和键盘、触控板等功能也有了实际进展。但是，交互流畅度仍在完善，Wi-Fi 连接还需要借助宿主机代理工具，音频、摄像头、蓝牙、睡眠以及外接显示器等功能也尚未得到支持。而且，项目目前只针对特定型号的 ASUS Zenbook A16，运行过程还需要一台 Mac 作为宿主端，通过 USB-C 连接和驱动整个工作流程。

所以，暂时不要脑补成明天买一台骁龙笔记本，后天就能愉快安装 macOS。但这个项目的重要性，显然不在于它现在是否适合日常办公。苹果已经全面转向自研芯片，那么非苹果 ARM 硬件有没有机会运行 macOS？Snapintosh 至少用实际运行的桌面证明，这个问题并非完全没有答案。

过去，我们讨论黑苹果，关注的重点是怎样让 x86 PC 接近官方 Intel Mac；未来，或许也会有人研究如何让其他 ARM 电脑具备运行 Apple Silicon 时代 macOS 的能力。

如果这条路线能够持续发展，它所带来的影响，甚至可能超出传统黑苹果圈的范围。

比 macOS 更夸张：安卓手机居然也能启动真正的 iOS？

项目地址：

• HackiOS：在 POCO X5 Pro 5G 上运行 iOS 16.5
• HackiOS 用户态组件
• ios-sweet：在 Redmi Note 10 Pro 上运行 iOS 16.7.16
• ios-topaz：尝试适配 Redmi Note 12 4G

如果前面几个项目还停留在黑苹果玩家熟悉的电脑领域，那么这一波安卓设备运行 iOS 的尝试，则完全是另一个故事了。

首先要明确：这可不是给安卓手机安装一套仿 iOS 的主题，也不是运行一个模拟 iPhone 桌面的应用。这些项目尝试将苹果开源的 XNU 内核适配到非苹果硬件上，再运行对应版本的 iOS 用户态组件，包括系统守护进程、SpringBoard 主屏幕等。换言之，这是真真正正让 iOS 安装和运行到非 iPhone 硬件上！

其中，HackiOS 已公开代码，目标设备包括 POCO X5 Pro 5G，使用的是骁龙 778G 平台；项目还支持在 QEMU 环境中进行部分测试。开发者列出的已实现功能包括锁屏、主屏幕、触控、部分系统手势、Wi-Fi，以及一定程度的 GPU、音频和相机支持。另一个项目 ios-sweet，则在搭载骁龙 732G 的 Redmi Note 10 Pro 上成功启动了 iOS 16.7.16 用户态环境，并展示了进入系统桌面、打开设置、下拉控制中心等操作。后续还有面向 Redmi Note 12 4G 的 ios-topaz 适配尝试。

从技术角度看，这类项目和传统黑苹果有着相似之处：它们都需要在非苹果硬件上重建苹果操作系统所期待的平台条件，并解决启动、驱动和系统服务之间的兼容问题。

但手机平台的情况同样复杂。不同型号的骁龙芯片、GPU、触摸屏控制器、电源管理组件以及厂商固件，都可能造成不同的适配难题。即使一个项目成功启动，也不能据此推断它能够直接移植到其他小米手机，更不能将它当作可以日常使用的完整系统。

以 ios-sweet 为例，项目文档明确指出，目前仍缺少 Wi-Fi、蓝牙、蜂窝网络、音频、摄像头、GPU 等关键功能，许多安全机制也处于关闭或简化状态。它目前更接近内核移植与系统启动实验，而不是可用的 iOS 手机系统。

HackiOS 的功能进度相对不同，但同样仍然属于研究项目，并非完善的安卓替代系统。即便如此，手机领域出现的这些尝试，仍然给人带来了一种熟悉的兴奋感。

曾经的黑苹果玩家，不正是从一次次看似不可能的系统启动、硬件适配和驱动调试中，逐渐把原本不受支持的 PC 变成可用的 macOS 设备吗？

先别急着吹爆：这些项目距离真正成功还有多远？

看到这里，很容易产生一种错觉：AI 已经强到可以随便移植操作系统了，黑苹果马上就要原地复活。

我倒觉得，现在还不是下这个结论的时候。这些项目确实令人振奋，但技术演示与成熟产品之间，仍然隔着一条很长的路。

第一，成功启动不等于完整可用。

能够显示桌面，只能说明系统运行过程中有一部分关键环节已经打通，并不代表所有硬件都能够正常工作。对于 macOS 来说，显卡之外还有 USB、声卡、网卡、电源管理、睡眠唤醒、外接显示器以及各种系统服务。任何一个环节不稳定，都可能影响日常体验。对于 iOS 这样的移动操作系统而言，蜂窝网络、音频、摄像头、安全芯片、应用安装以及系统升级，也都是不可回避的问题。一张桌面截图可以证明项目取得了进展，却不能证明它已经成为一台真正可用的 Mac 或 iPhone。

第二，AI 可以提高开发效率，但不能凭空创造硬件兼容性。

AI 能够帮助开发者理解代码、编写驱动、分析崩溃日志，甚至提出修复思路；但硬件初始化是否正确、寄存器读写是否符合预期、图形输出是否稳定，最终仍然需要在真实设备上进行验证。尤其是涉及内核、显卡驱动以及启动链的工作时，一个小错误就可能导致系统无法启动，严重时甚至造成数据损失。这不是让 AI 再生成几轮代码就一定能够解决的问题。换句话说，AI 可能让开发者更快地找到问题，但并不能保证每个问题都有可行的解决办法。

第三，跨架构移植的维护成本可能比开发原型更高。

让一个版本的 macOS 在特定机器上启动，与让它长期跟随苹果更新，是两种完全不同的任务。一旦 macOS 更新了内核接口、图形框架或安全机制，第三方驱动和适配层就可能需要重新调整。当项目从最初的演示阶段走向长期维护，开发者还需要面对更多硬件型号、更多系统版本以及不断增长的 Bug 列表。如果项目缺少稳定的维护团队，或者始终没有足够多的真实用户参与测试，即使初期进展迅速，也可能在后续阶段停滞。

第四，安全性、许可与生态支持同样重要。

部分实验项目需要调整系统安全配置，或使用尚未完善的设备驱动；有的项目还明确提示存在数据损失风险。对于普通用户而言，这些风险必须认真考虑。

此外，苹果系统、固件以及第三方代码受到各自许可条件约束。能够在技术上实现某种功能，不代表所有使用和分发方式都不受限制。在我记忆里，把 iOS 移植到非 iPhone 硬件上早就有人尝试过，但大多后来销声匿迹了。苹果在 macOS 方面策略则更像隔壁的微软，放纵盗版成长，得到了更多的“弃黑投白”的用户，不过苹果也曾起诉过把黑苹果商业化的一家公司 Psystar（他们直接对外销售预装 macOS 系统的 PC），所以苹果官方对黑苹果社区有一定的容忍度，但直接商业化运作就是禁忌底线。以上只是个人观点不代表苹果官方立场。

最后还有一个现实问题：这些项目目前大多面向开发者和极客玩家。构建环境、固件提取、源码编译以及设备调试，都不是普通用户可以轻易完成的工作。它们还需要时间，才能回答最重要的问题：能否稳定运行、能否持续更新、能否让更多人使用？所以，我并不认为上述项目已经解决了黑苹果的全部困境。

但这并不妨碍我们对它们保持期待。

真正值得期待的，不只是黑苹果复活

回过头来看，这几个项目其实分别代表着不同的技术方向。

NVIDIA 驱动试图弥补显卡生态的缺口；Maclator 尝试跨越应用程序的处理器架构差异；Snapintosh 探索在非苹果 ARM 硬件上运行新一代 macOS 的可能性；HackiOS、ios-sweet 等项目，则在验证 iOS 能否运行于安卓设备所使用的硬件平台。它们的具体目标不同，成熟度也存在差距，但有一个共同点：它们不再仅仅满足于讨论某种设想是否可能，而是开始用真实设备、代码和运行实例回答问题。

而这，恰恰是 AI 时代最值得关注的变化。

当然，我们不能断言这些项目一定是由 AI 推动的，也不能将它们的进展全部归功于大模型。底层技术积累、开源社区长期沉淀、开发者的专业能力以及各种已有项目之间的协作，同样不可或缺。但 AI 的价值，或许就在于让这些积累更容易被调用，让开发者能够更快地完成原型、测试想法，并将精力投入真正棘手的问题。

以前，一个人想挑战复杂的内核适配和图形驱动开发，可能需要投入非常庞大的时间成本；现在，在一定条件下，AI 可以帮助开发者减少重复劳动，加快理解代码和迭代方案的速度。这并不意味着一个人就能轻松取代成熟的操作系统团队，而是意味着更多原本因人力不足而无法开展的实验，可能有机会真正启动。对于黑苹果而言，这种变化也许比任何单一的驱动突破都更重要。

过去二十年，黑苹果的黄金时代建立在 Intel 架构与苹果电脑硬件的相似性之上。如今，随着苹果全面转向 Apple Silicon，原来的技术路线不可避免地遇到瓶颈。未来的黑苹果，可能不再只是传统意义上由 Intel CPU、AMD 或 NVIDIA 显卡组成的 PC，也可能包含更多跨架构运行、图形接口兼容、虚拟化和硬件适配方面的探索。这未必意味着旧时代会以原来的形式回归，却可能意味着一个不同的研究方向正在形成。

我们当然希望未来某一天，能够有更完善的方案，让更多普通 PC 继续运行新版本 macOS；也希望 Intel 平台上的存量黑苹果，能够通过兼容层和社区驱动延长使用寿命。但即使这些愿望最终不能全部实现，上述项目仍然证明了一件事：技术边界并不总是永远固定的。苹果不再提供官方支持，不等于社区从此只能停止尝试；官方不再适配某种硬件，也不代表所有探索都失去了价值。尤其在 AI 快速发展的今天，一些过去需要大量人力才能完成的研究，正在获得新的可能性。

所以，我现在更倾向于相信，黑苹果并没有彻底走到终点。它或许正在告别过去那种依靠 Intel 平台不断追赶苹果更新的时代，并尝试走向一个更加多元、更加实验性的新阶段。

至于这些项目最终能走多远，还需要时间给出答案。但至少这一次，在苹果关上旧时代的大门之后，我们又看到了有人开始尝试寻找新的入口。

AI 力大砖飞，黑苹果绝处逢生。故事，或许还远没有结束。

参考链接

Github 项目主页

• NullMoth NVIDIA macOS Driver：https://github.com/nullmoth/nvidia-macos-driver
• Maclator：https://github.com/linuxkid473/maclator
• Snapintosh：https://github.com/Snapintosh/Snapintosh
• HackiOS 内核项目：https://github.com/oosexgang/hackios-xnu-kernel
• HackiOS 用户态项目：https://github.com/oosexgang/hackios-xnu-userland
• ios-sweet：https://github.com/dipa-studio/ios-sweet
• ios-topaz：https://github.com/MakrSas/ios-topaz

官方系统兼容性资料

• macOS 27 Golden Gate 兼容的 Mac 机型：https://support.apple.com/zh-cn/127255
• macOS Tahoe 26 兼容的 Mac 机型：https://support.apple.com/zh-cn/122867