Switch 游戏原生跑上 iPhone 与 Mac：开源项目 nxnative 技术拆解#
各位朋友好，我是紫星。最近两周，我盯一个开源项目盯得很紧：它不是新出的性能测试工具，却比很多跑分更能说明 Apple 芯片现在的位置——nxnative（GitHub 仓库 seedds/nxnative，MIT 许可）。这个项目的 star 曲线是我今年见过最陡的一条：10 月 19 日破 500，10 月 21 日破 1000，10 月 23 日破 2500，到 10 月 26 日已经约 3000 星，近 7 天涨了约 2600，日均约 370。而仓库创建时间，是 2026 年 10 月 13 日。也就是说，从仓库建立到破千星只用了 8 天。
它做的事情一句话可以说清：把玩家自有的 Switch 游戏 NSP 文件加上 prod.keys 密钥，用一个脚本转成可以在 iPhone、iPad、Mac 上侧载的未签名 IPA——然后游戏自己跑起来。注意，官方在仓库里明确写着「不是模拟器」：游戏自身的代码直接跑在 Apple 芯片上，Switch 的图形则以 Metal 重建。作为一个常年跟转译层打交道的技术作者，我认为这个定位值得认真对待——下面按我的习惯，把它的技术架构拆成三件套逐一过一遍。
一、先看档案：这是一个什么样的项目#
| 项目 | 内容 |
|---|---|
| 仓库 | GitHub 上的 seedds/nxnative |
| 许可证 | MIT |
| 输入 | 玩家自有的游戏 NSP 文件 + prod.keys 密钥 |
| 输出 | 可侧载到 iPhone/iPad/Mac 的未签名 IPA |
| 定位 | 官方明确声明：不是模拟器，游戏代码原生运行 |
| 资产边界 | 仓库不含任何游戏内容，与任天堂及任何发行商无关联 |
「不是模拟器」这句声明在技术上是有实义的，不是宣传话术。传统模拟器要在宿主设备上完整重建一台主机的硬件行为，代价是每一层都要过模拟这一道；而 nxnative 的思路是把游戏本身改写成 Apple 平台的原生应用，系统层面的缺口用一套宿主层顶上。两种路线的差异，后面第九节我会用表格对比。
二、星标轨迹：两周走完别人一年的路#
| 时间点 | 节点 |
|---|---|
| 2026-10-13 | 仓库创建 |
| 2026-10-19 | 星标破 500 |
| 2026-10-21 | 星标破 1000 |
| 2026-10-23 | 星标破 2500 |
| 2026-10-26 | 约 3000 星，近 7 天 +2600（日均约 370） |
中文社区的传播也在加速这个过程：北邮教师「爱可可-爱生活」10 月 23 日在头条发文介绍，实测 A17 Pro 与 M1 及以上设备多款游戏流畅运行，并可跑满 60 帧。一个项目两周内同时打通英文开发社区和中文玩家社区，这在纯技术项目里并不多见。
三、技术拆解①：NSO 重写器——把游戏二进制改写成原生执行#
第一件套是 NSO 重写器。Switch 游戏的代码以 NSO 格式的二进制存在，这个重写器的工作是把游戏二进制改写为 Apple 架构可原生执行的形态，让游戏代码不再隔着模拟层，直接跑在 Apple 芯片上。
这里有一个前提条件值得单独说：Switch 主机的处理器本身就是 ARM 架构，游戏代码从一开始就是按 ARM 指令集编译的；而 Apple 芯片（A 系与 M 系）执行的也是 ARM64 指令集。两边是同构的，所以重写器不需要做跨架构的指令翻译，只需要处理装载格式与二进制布局的改写。这就是事实层面最容易被人忽略的一点：这条「非模拟」路线之所以成立，是因为 ARM64 同构红利——如果目标平台是 x86 架构的 PC，缺了这一层同构，整个路线的复杂度会完全不同。这也是为什么这类项目出现在苹果生态、而不是其他生态。
四、技术拆解②：Horizon HLE 宿主层——替身系统服务#
Switch 的操作系统叫 Horizon，游戏运行时要向它请求各种系统服务。在 iPhone 或 Mac 上当然没有 Horizon，所以 nxnative 做了第二件套：Horizon HLE 宿主层，用一套替身系统服务顶替真实的 Horizon，让游戏以为自己还在 Switch 上运行。
HLE 指高层实现（High-Level Emulation）的思路：不去模拟内核的底层细节，而是在高层直接提供语义等价的服务接口。值得注意的是这套宿主层的同步语义以 Atmosphère 的 mesosphère 内核为参考——Atmosphère 是 Switch 自制系统社区最重要的内核层实现，其内核代码对 Horizon 行为的还原经过了大量真实硬件验证。用社区久经考验的开源实现做参考，比凭空猜测系统行为靠谱得多，这是这个项目工程判断上的聪明之处。
五、技术拆解③：NVN→Metal 图形转换层#
第三件套解决图形。Switch 的图形接口叫 NVN，游戏着色器按 Maxwell 架构编写，而 iOS 与 macOS 的图形栈是 Metal——三者没有一个能直接对话。nxnative 的转换链路是这样的：
- 游戏里的 Maxwell 着色器，先经 Ryujinx 模拟器以 MIT 许可开源的转换器转成 SPIR-V 中间表示；
- 再经 SPIRV-Cross 工具把 SPIR-V 转成 Metal Shading Language 源码；
- 最终在 Metal 之上重建 Switch 的图形呈现。
这条链路本质上是把 Switch 图形栈逐层映射到苹果图形栈：着色器转译一次到位，纹理与绘制语义由转换层补齐。开源生态的复用在这里体现得很充分——着色器转换这一环直接站在 Ryujinx 的肩膀上，而没有重新造轮子。
六、三件套之外的支撑组件#
除了核心三件套，仓库里还有一组各司其职的组件，合起来才是完整的管线：
| 组件 | 职责 |
|---|---|
| LibHac | 解析游戏 NSP 文件 |
| deko3d 纹理布局 | 纹理布局算法移植自 Switch 平台图形库 deko3d |
| libvpx | 处理影片播放 |
| stb_vorbis | 处理音频 |
这个组件清单能看出作者的风格：NSP 解析、纹理布局、视频、音频，全部优先复用成熟开源实现，自己只写真正缺的部分。对一个两周冲到 3000 星的项目来说，这种克制的工程品味比星数本身更能说明成熟度。
七、硬件门槛：为什么卡在 A17 Pro 与 iOS 26#
| 门槛 | 要求 |
|---|---|
| iPhone | iPhone 15 Pro 及更新机型（A17 Pro 芯片及以上） |
| iPad | M1 芯片及以上 |
| 系统 | iOS/iPadOS 26 或更新 |
| 存储 | 约需 NSP 文件体积的两倍 + 10 GB |
系统版本这道线卡得很死，原因是纹理：游戏纹理采用 BC 压缩格式，旧设备（旧系统）读不了，所以 iOS/iPadOS 26 是硬性下限。芯片门槛同样是硬性的——A17 Pro 与 M1 是名单的起点，没有弹性空间。存储方面按「NSP 两倍 + 10 GB」预留，这与管线中转译产物的体积特征相符，装大体量游戏前要先算好这一笔。
八、兼容性现状：哪些游戏能跑，跑到什么程度#
项目为每款游戏提供分游戏的说明页，已测试名单（Mac 或 iPhone 实测）包括：
- 《超级马力欧兄弟惊奇》（Super Mario Bros. Wonder）（站内已有攻略：《超级马力欧兄弟惊奇》）
- 《火焰纹章：Engage》（Fire Emblem Engage）
- 《塞尔达传说：旷野之息》（The Legend of Zelda: Breath of the Wild）
- 等数十款——名单规模以仓库 README 当前列表为准，本文不写死具体总数
几个关键现状：
| 事项 | 现状 |
|---|---|
| 帧率 | 部分游戏可从 Switch 原生 30fps 解锁至 60fps；旷野之息所属的 Zelda 系需 1.2.0 等特定更新版本 |
| 操作 | 支持触控（2D/3D 布局）与外接手柄 |
| 不支持 | amiibo 与联机功能 |
| 《塞尔达传说：王国之泪》 | 仍在移植中，目前仅能到达开场洞穴（iPhone 15 Pro 及以上、iOS 26），帧率问题未解决 |
| 名单外游戏 | 脚本会生成调查报告并尽力猜测设置打包，但可能无法启动 |
最后一条尤其值得注意：对不在名单里的游戏，管线会先做调查再尝试打包，这是一个「尽力而为」的机制，不是承诺。想拿冷门游戏直接上手的玩家，先看分游戏说明页再动手，能省一个晚上的构建时间。
九、与模拟器路线的机制对比#
把 nxnative 和传统模拟器放在一起看，差异是结构性的，不是程度上的：
| 维度 | nxnative（转译路线） | 传统模拟器（全系统模拟路线） |
|---|---|---|
| 指令执行 | 游戏代码经 NSO 重写后原生执行于 Apple 芯片 | 宿主上模拟整个主机 CPU 行为 |
| 图形 | NVN→Metal 转换层重建 Switch 图形 | 模拟主机 GPU 或整体转译 |
| 系统服务 | Horizon HLE 宿主层顶替系统服务 | 模拟或重构系统环境 |
| 交付形态 | 每款游戏产出一个独立 IPA | 通用模拟器加载游戏文件 |
需要说清楚的是：截至发稿，没有 nxnative 与 Yuzu、Ryujinx 等模拟器的第三方性能对比跑分数据，所以本文只做机制层面对比，不做性能结论。任何「转译一定比模拟快」的说法，在跑分出现之前都只能算推测，我作为硬件作者不背这个书。
十、从源码到 IPA：构建与侧载流程#
构建在 Mac 上进行，环境需要 Xcode 与 Homebrew。核心依赖与流程如下：
| 步骤 | 内容 |
|---|---|
| 1. 克隆仓库 | git clone 拉取源码 |
| 2. 安装工具链 | brew install xcodegen zstd spirv-cross glslang，另需 dotnet-sdk 与 Python 依赖（lz4、capstone、fonttools、nsz） |
| 3. 准备输入 | 玩家自有的 NSP 文件 + prod.keys；支持 NSZ/XCZ 压缩格式自动转换 |
| 4. 构建 | 首次构建约需 30-60 分钟，产出单个 IPA |
| 5. 侧载 | 经 AltStore 或 Sideloadly 侧载到设备 |
| 6. 自定义 | 设置经设备 Documents 目录下 env.txt 自定义（帧率、语言等） |
社区生态里还有一个值得单独一提的 fork：NX2Apple。它是一个独立项目，提供 macOS 图形界面应用，把整条打包管线跑完，并产出分片 RomFS 归档，让 IPA 体积更小。不想碰命令行的用户可以关注这条路线，但请注意它是社区独立项目，与主仓库要分开评估。
十一、起源与法律边界：一个灰色地带上的项目#
溯源方面，nxnative fork 自 d2r-mobile——一个让《暗黑破坏神2：重制版》（Diablo II: Resurrected，站内已有攻略：《暗黑破坏神2：重制版》）在 iOS 上原生运行的项目（MIT 许可）。d2r-mobile 里通用的部分——NSO 重写器、Horizon 宿主层、NVN-on-Metal 图形层与 iOS 应用壳——被抽出来泛化成了 nxnative，如今两个项目还在互相回馈修复。从「一款游戏能跑」到「一套框架跑多款游戏」，这条方法论复用的路径，和手游移植社区一贯的协作方式一脉相承。
法律层面必须如实交代三件事：其一，项目声明仅处理玩家合法拥有的游戏与密钥；其二，仓库不含任何游戏资产；其三，项目与任天堂及任何发行商无关联。这三条是仓库白纸黑字的自我定位。就本站的观察，截至发稿，任天堂方没有任何公开行动的报道——也就是说，「灰色地带」目前是对法律状态的描述，而不是对已发生事件的说法。考虑到任天堂在模拟器领域的历史维权姿态（此前对 Switch 模拟器仓库的 DMCA 清洗可见本站此前的整理），这个项目的法律暴露面与模拟器并不相同，但玩家在动手之前，应当清楚自己站在哪条线上。
十二、紫星的判断#
最后给三条我的看法：
- 这是 Apple 芯片地位的一次间接确认。 一条「不做模拟、直接原生跑」的路线能够成立，前提是目标芯片足够强、且与主机同构。这个项目的存在本身，就是 A17 Pro 与 M 系芯片算力的一张成绩单。
- 门槛线画得很诚实。 A17 Pro、M1、iOS/iPadOS 26，一道线都没有放宽；「约 NSP 两倍 + 10 GB」的存储要求也写得直白。技术项目把限制讲清楚，比把前景吹起来更值得信任。
- 看它的下一站，先看《塞尔达传说：王国之泪》。 王国之泪目前仅达开场洞穴、帧率问题未解决，这个 hardest case 的推进速度，就是整个项目天花板的进度条。我会持续盯着仓库的分游戏说明页更新。
对掌机与移动游戏生态感兴趣的读者，也可以对照阅读我们此前的 Steam Deck 游戏适配榜 2026——同一批游戏，「模拟兼容」与「原生转译」两条路线的体验边界，正在越来越清晰。
——紫星，NTGame 硬件编辑