未越狱 iPhone 真能跑 Windows 游戏吗：iOS 游戏模拟器 Madeira 完整指南
【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira
现在就能玩。Thumper、ULTRAKILL 等 x86-64 Windows PC 游戏，已经能直接跑在未越狱 iPhone 上。项目叫 Madeira，一个 iOS 游戏模拟器：FEX-Emu + Wine + DXMT 三层技术栈打包进单个 iOS 应用，游戏原封不动运行。
现在能玩到什么程度
先说结论：能玩，但要带着"研究项目"的预期。
- Thumper 可正常游玩，ULTRAKILL 同样可玩，是目前状态最成熟的两款游戏
- Marvel Cosmic Invasion 能到达游戏画面，但操控还不太稳定
- 其余游戏多数能进画面，帧率普遍偏低，表现因游戏而异
README.md 里作者说得很直白：这是一个活跃的研究项目，很多游戏能启动、部分能玩得好，但性能和兼容性因游戏而异，"expect rough edges"——要有粗糙边缘的心理准备。
iPhone 是怎么骗过 Windows 游戏的
核心思路是三层各管一段，逐层把 Windows 的假设补齐。
第一层假设是"我在 x86 CPU 上跑"。iPhone 是 ARM64，指令集完全不同。FEX-Emu 在这层出手：运行时把游戏的 x86 和 x86-64 代码逐块翻译成 ARM64，x86-64 转 ARM64 的指令转换就发生在这一步。
第二层假设是"系统 API 是 Windows 的"。这一层由 Wine 11 承担，而且不是普通的 Wine：整个被构建成 ARM64EC，Wine 自己以 ARM64 原生代码运行，只有游戏本体的 x86 代码过 FEX 模拟。这直接解释了帧率为什么可观——需要翻译的瓶颈被压到了最小范围。
还有一处必须提的设计改动：iOS 不允许 App 启动别的程序，更不允许 fork()。于是 Wine 的 wineserver 被从独立进程改造成线程，连同所有"Windows 进程"一起塞进同一个 iOS 进程里。你看到的每个 Windows 进程，其实都只是这个进程里的线程。
第三层是画面：游戏用 DirectX 画帧，iPhone 只认 Metal。DXMT 负责把 Direct3D 9/10/11 的绘制调用实时翻译成 Metal 提交给苹果 GPU；D3D12 则由自研的 madeira-d3d12 承接，运行时用 Apple 的 Metal Shader Converter 现场转换 DXIL 着色器。
三层叠完，Windows 游戏就"以为"自己还在 Windows 上。
动手前自查清单：3 项硬性条件
开始折腾前，先把三件事对一遍。
- 一台未越狱的 iPhone，iOS 26 或更新版本。开发验证在近期的 Pro 机型（A15 芯片）上进行，芯片越强体验越好。
- 能让 JIT 开起来。iOS 只在调试器附加时允许创建可执行内存，Madeira 用 StikDebug（或内置 StikJIT helper）完成 attach，拿到 CS_DEBUGGED 标志后 JIT 才可用。这也是它无法上架 App Store、只能侧载安装的原因。
- 一个免费 Apple ID 就够。注意免费证书 7 天过期，每周要重新签名装一次；好消息是重装后 App 数据容器保留，你的游戏、存档和 Wine prefix 都不会丢。
一条编译流水线，四道工序出 IPA
不想自己编译就直接下载官方 IPA 侧载；想复现构建，先看这条链。
克隆时记得带子模块：
git clone --recurse-submodules https://gitcode.com/GitHub_Trending/mad/Madeira注意 FEX、wine、dxmt、madeira-dock 都是指向项目自有 fork 的子模块，里面带着 iOS 移植工作，克隆上游仓库是无法构建的。
另外有几样仓库里没有的输入要自备（详见 docs/BUILDING.md 的表格）：llvm-mingw 交叉工具链、为 iOS 编译的 LLVM（要数小时）、Microsoft Visual C++ 运行时 DLL——最后一项受微软许可限制不可分发，获取方式见 tools/fetch-vcruntime.md。
之后的编译链分四道工序，按顺序跑：
- gnutls-ios：产出 libgmp、libnettle、libhogweed、libgnutls 静态库
- fex-ios 与 fex-arm64ec：产出 FEX 静态库，并把 ARM64EC 侧的 xtajit64.dll 复制进 App
- ntdll-unix、wineserver、win32u-unix：产出 Wine unix 侧的静态库
- dxmt-ios 与 madeira-d3d12：产出 DXMT 图形转换层和原生 D3D12 运行时
最后构建 App：
xcodebuild -project app/Madeira.xcodeproj -scheme Madeira \ -destination 'generic/platform=iOS' -allowProvisioningUpdates build一个坑：只有 Debug 配置能跑游戏，Release 构建曾导致 guest 崩溃。构建完成后把 Payload/Madeira.app 打包成 IPA，再侧载安装。
操作方案：手柄优先，触屏兜底
输入是这套模拟器完成度最高的部分之一，物理手柄优先，触屏兜底，两者由一套输入仲裁规则合并。
物理手柄走 XInput：配对后的 MFi/蓝牙手柄最多支持 4 个扩展配置文件，以 250Hz（4ms）采样，按钮、扳机、摇杆原样直通游戏，不经过鼠标合成。
没有手柄就用触屏：横屏编辑器里可以自由映射 A/B/X/Y、方向键、LB/RB，LT/RT 是全行程扳机，LS/RS 是带径向钳制的模拟摇杆，摇杆运动相对首次触摸位置。
重点是两套输入可以叠加，仲裁规则写得很明确：
- 扳机：物理与触屏取较大值
- 摇杆：物理摇杆偏离标准 XInput 死区时优先于触屏摇杆；触屏摇杆静止时保留物理值
- 多指：UIKit 独立处理每根手指，松开一根手指不会卡住另一根手指按住的按键
想整体回滚？在 Documents/madeira.cfg 里设env.MADEIRA_XINPUT = 0重启即可。
性能天花板与已知边界
把期望值调到合理位置，比盲目试错更重要。
内存是第一道墙：iOS 的 Jetsam 上限约 4096MB，大游戏可能顶到这条线被系统杀掉；长时间游玩还有热节流持续降频。这是移动设备模拟 PC 游戏的天然瓶颈。
32 位游戏理论上有路：Wine 11 的 WoW64 路线让 wow64.dll、wow64win.dll 以原生 aarch64 运行，只把程序的 x86 代码交给 FEX 的 WOW64 模块翻译；iOS 只有 64 位进程，纯 64 位加 thunking 正是可行路径，详见 docs/WOW64.md。
许可证方面：项目本体是 GPL-3.0-or-later（带 Metal Shader Converter 例外条款），各上游组件的许可明细在 LICENSES/ 与 THIRD-PARTY-NOTICES.md，分发派生作品需保持开源。
想往下深挖，按这个顺序读
先看应用主体，再补文档。
先翻 app/Madeira/：SwiftUI 前端、Wine 桥接代码和 arm64ec-windows/ 里预编译的 PE 模块都在这里，能直观看到一个 App 如何装下整个 Windows；接着读 docs/BUILDING.md 的从零复现流程和未验证步骤标注；输入机制看 docs/CONTROLLERS.md；缺 VC++ 运行时的看 tools/fetch-vcruntime.md。
FEX 管 CPU、Wine 管 API、DXMT 管 GPU——这条链路把"iOS 上模拟 PC 游戏"拆成了三层各自可验证的工程问题，也是这个仓库最值得逐层研读的原因。
【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
