[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fv3myddm0cz1d":3},{"code":4,"message":5,"data":6,"timestamp":25},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":9,"updated_at":23,"history":24},"ly05010419\u002FMacNativeGames",5,null,"C",5172,747,744,7,[],"用自备的游戏文件和密钥，在 Apple 芯片 Mac、iPhone、iPad 上原生运行 Switch 版塞尔达。","## 解决什么问题\n\n在 Apple 硬件上玩《王国之泪》或《旷野之息》，过去基本等于跑 x86 模拟器（Ryujinx、Yuzu，后者已停止维护），再叠一层翻译，调半天才勉强稳定。这个项目换了一条路：它不模拟 Switch。游戏自己的 ARM64 代码直接跑在 Apple 芯片上，只在操作系统要求的地方做改写，Switch 系统服务由一层小型宿主代码应答，游戏的 NVN 图形调用重建到 Metal 之上。\n\n## 有什么不同\n\n在 Apple 芯片上做模拟，通常要翻译指令集、还要维护多个图形后端。这里因为客户机与宿主同为 ARM64，CPU 侧的工作基本消失，精力集中在系统服务垫片和 Metal 渲染器上。第二个不同点是共享着色器列表：玩家机器上遇到的变体会被收集成一份只含标识符的公开清单（README 称已有 34,179 个变体），每次构建都用玩家自己的数据提前编译，直接针对模拟器首次运行最恼人的着色器编译卡顿。第三是覆盖范围：同一套构建流程同时产出 Mac 应用和未签名 IPA，而不只是桌面端。\n\n## 适合谁\n\n适合拥有正版游戏、有 Switch、并且愿意自己 dump 密钥和系统文件、用脚本构建应用的人。已测试的基线是 M 系列 MacBook Air\u002FPro 和 Mac mini；iOS 构建要求 iOS\u002FiPadOS 26 和 iPhone 14 及以上，这直接排除了绝大多数现有设备。如果你想要一个开箱即用的模拟器前端，或者不愿意处理密钥与游戏 dump，这不适合你。不愿意按游戏、按版本逐个构建的人也应该绕道：它是构建系统，不是启动器。\n\n## 上手成本\n\n你需要自备游戏文件（XCI 或 NSP）、prod.keys 和系统文件；仓库不分发任何游戏内容，因此构建出的应用只能自用，不能分享。构建耗时不小：README 提到 M4 上《王国之泪》1.4.3 首次启动着色器预热约 90 秒，装好 Xcode Metal 工具链后 GPU 着色器编译约 6 分钟，不装则更久，并且应用一旦移动位置可能丢掉 macOS 的 Metal 缓存。README 直接建议用 Claude Code 或 Codex 来协助完成构建，说明构建步骤还不算打磨好。文档详尽但分散，已知缺口也存在：音频修复只在 1.0.0 上验证过，首次进入新场景掉帧是预期行为。MIT 许可。\n\n## 点评\n\n这是一个只有一周、5,180 star、日均约 744 star 的项目，是明显的短期冲高而非长期积累：2026-10-24 之前没有任何记录，也没上过每日 trending 榜。技术前提（在 Apple 芯片上用原生 ARM64 执行替代 CPU 模拟）是可信的，共享着色器清单把卡顿问题众包出去也是聪明的设计，但 README 本身更像一份快速更新的变更日志，充满按版本的注意事项和尚未验证的路径。可以把它看作适合有硬件、有文件的折腾者的有趣实验，而不是稳定的游玩方案。后续值得观察更新节奏能否维持，以及音频和场景覆盖能否在单一版本之外得到验证。",{"slug":19,"name":20},"games","游戏",[],"MIT","2026-10-24T20:05:47Z",[],1792887572]