1. 项目缘起为什么要在 iOS 上折腾 Wine 兼容层第一次看到 Madeira 这个代号是在一个跨平台兼容性讨论的角落里。它指向的并不是某个旅游胜地而是一个把 Windows 应用搬到 iOS 设备上运行的技术探索方向。核心思路很直接利用 Wine 作为 Windows API 的翻译层再配合 FEX-Emu 做 x86-64 到 ARM64 的指令翻译最后通过 DXMT 把 Direct3D 调用转成 Metal让那些原本只认 Windows 的桌面程序能在 iPhone 或 iPad 上跑起来。这件事为什么值得做因为 iOS 生态长期封闭App Store 上架审核严格很多老旧的 Windows 工具、行业软件、独立游戏根本没有 iOS 版本。而 Wine 这类兼容层不需要修改原程序也不需要虚拟机完整模拟资源占用相对可控。FEX-Emu 的出现更是补上了关键一环——苹果从 A11 之后就不再支持 32 位应用ARM64 原生执行 x86-64 指令需要二进制翻译FEX-Emu 就是干这个的。DXMT 则是把 DirectX 11/12 的调用映射到 Metal绕开 OpenGL 在 iOS 上被弃用的尴尬。这套组合适合谁参考一是对 iOS 底层机制感兴趣的开发者想了解二进制翻译和图形 API 转换的实际落地二是需要在移动设备上临时运行 Windows 小工具的技术人员三是喜欢折腾模拟器、兼容层的极客玩家。需要提前说明的是这条路线目前并不适合普通用户日常使用涉及开发者模式、自签名证书、性能损耗等一系列门槛但作为技术验证和特定场景下的应急方案它的价值是实打实的。我前后花了大概三周时间在 iOS 17 和 iOS 18 的设备上反复测试踩了不少坑也总结出一些能直接抄作业的步骤。下面就从整体设计思路开始把每个环节拆开讲清楚。2. 整体架构与方案选型Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 三层翻译栈的协作逻辑把 Windows 程序跑在 iOS 上本质上要解决三个层面的不兼容指令集不同、系统调用不同、图形接口不同。Wine 负责的是系统调用层面的翻译它把 Windows 的 PE 可执行文件加载起来把 kernel32、user32、gdi32 这些 DLL 的调用转换成 POSIX 调用。但 Wine 本身不处理 CPU 指令集差异如果程序是 x86-64 编译的而设备是 ARM64就需要 FEX-Emu 在中间做动态二进制翻译。FEX-Emu 的工作方式可以类比成同声传译它把 x86-64 的指令块实时翻译成 ARM64 指令翻译结果会缓存起来下次执行同一段代码就直接用缓存。DXMT 则是在 Wine 的图形驱动层做文章Wine 原本通过 WineD3D 把 Direct3D 转成 OpenGL但 iOS 上 OpenGL 已经废弃Metal 才是正路。DXMT 直接把 D3D11 和 D3D12 的调用映射到 Metal省去了中间层效率更高。这三者的版本匹配非常关键。我试过用较新的 Wine 搭配旧版 FEX-Emu结果程序启动就崩溃日志里全是未定义的符号。后来统一到 Wine 9.x、FEX-Emu 2407 以上、DXMT 0.5x 这个组合稳定性明显提升。2.2 为什么不用完整虚拟机有人会问为什么不直接在 iOS 上跑 UTM 这类虚拟机装 Windows原因有三第一iOS 不允许 JIT 编译虚拟机需要动态翻译指令性能损失极大第二完整 Windows 镜像动辄几十 GBiOS 设备存储和内存都吃不消第三虚拟机方案需要越狱或特殊权限而 Wine 兼容层可以在用户态运行门槛相对低一些。当然Wine 也不是万能的它依赖程序本身对 API 的使用方式如果程序用了大量未实现的 Windows 特性照样跑不起来。2.3 目标程序的筛选标准不是所有 Windows 程序都值得往 iOS 上搬。根据我的测试经验以下几类成功率较高一是依赖 DirectX 9 到 11 的老游戏DXMT 对这部分支持较好二是使用标准 Win32 API 的小工具比如文本编辑器、计算器、简单绘图软件三是基于 .NET Framework 但不需要复杂系统服务的程序。相反依赖内核驱动、需要管理员权限、大量使用 COM 组件的程序基本可以放弃。程序类型推荐程度原因DX9-DX11 老游戏较高DXMT 映射成熟FEX-Emu 对 x86 游戏兼容好标准 Win32 小工具中等依赖少但图形界面可能需调整.NET 桌面程序中等偏低需要额外安装 mono 或 .NET 运行时驱动级软件极低Wine 无法模拟内核驱动大型生产力套件低API 调用复杂性能损耗明显3. 环境准备从开发者模式到依赖安装的完整清单3.1 iOS 设备端的前置设置在 iOS 上运行非 App Store 应用第一步是开启开发者模式。iOS 16 之后这个选项藏得比较深设置 → 隐私与安全性 → 开发者模式打开后设备会重启重启后还要再确认一次。注意这个模式需要设备连接 Xcode 或者使用 AltStore、Sideloadly 这类自签名工具才能激活。如果你用的是 iOS 26.3.1 这类较新版本开发者模式的入口位置基本没变但系统对证书的校验更严格了免费证书只有 7 天有效期到期需要重新签名。另一个坑是设备架构。FEX-Emu 目前对 A12 及以上芯片支持较好A11 及更早的设备因为缺少某些 ARM64 指令集扩展翻译效率会大打折扣。我手头一台 iPhone XRA12跑起来还算流畅但一台 iPad 6A10就明显卡顿部分程序甚至无法启动。3.2 编译工具链的搭建Wine、FEX-Emu、DXMT 都需要在 macOS 上交叉编译成 iOS 可用的二进制。你需要一台 macOS 电脑安装 Xcode 命令行工具、CMake、Ninja、Python 3.10 以上版本。具体依赖如下brew install cmake ninja python3.11 pkg-config xcode-select --install然后克隆各个仓库。Wine 的 iOS 分支需要打补丁FEX-Emu 需要配置 ARM64 目标DXMT 需要链接 Metal 框架。编译顺序建议是先编 FEX-Emu 的静态库再编 Wine 的 PE 加载器和 DLL最后编 DXMT 的 Metal 后端。整个过程在 M1 Mac 上大约需要 40 分钟Intel Mac 可能要一个半小时。注意编译时务必指定-DCMAKE_OSX_ARCHITECTURESarm64否则生成的二进制无法在 iOS 设备上运行。另外iOS 不允许动态链接第三方库所有依赖必须静态链接或者打包成 framework 嵌入。3.3 签名与部署方式编译产物需要通过 Xcode 打包成 .ipa 文件然后用自签名证书安装到设备。免费开发者账号可以签 3 个应用每个有效期 7 天。如果你有付费开发者账号有效期可以延长到一年。部署方式我试过三种Xcode 直接安装、AltStore 无线安装、Sideloadly 数据线安装。Xcode 最稳定但需要连接电脑AltStore 方便但偶尔会掉签Sideloadly 适合 Windows 用户。签名时有个细节Wine 需要get-task-allow权限才能进行 JIT 编译而免费证书默认不带这个权限。解决办法是在 entitlements 文件里手动添加然后重新签名。这一步如果漏掉FEX-Emu 启动时会直接报错退出。4. 核心细节解析Wine 乱码、DXMT 配置与 FEX-Emu 调优4.1 Wine 中文乱码的根因与修复Wine 在 iOS 上最常见的显示问题就是中文变成方块或者问号也就是大家常说的“wine 乱码”。根本原因是 Wine 默认使用的字体不含中文字形而 iOS 系统字体路径和 Linux 不同Wine 找不到合适的字体替换。解决办法有两种一是把中文字体文件如 Noto Sans CJK复制到 Wine 的字体目录然后修改注册表指定替换二是在 Wine 配置里启用 fontconfig让它自动匹配系统字体。我采用的是第一种方案具体操作如下# 将字体文件放入 Wine 的 C 盘字体目录 cp NotoSansCJK-Regular.ttc ~/.wine/drive_c/windows/Fonts/ # 导入注册表项 wine reg add HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes /v MS Shell Dlg /t REG_SZ /d Noto Sans CJK SC /f改完之后重启 Wine 程序中文就能正常显示了。如果还有部分界面乱码可能是程序自带了字体文件需要把字体替换成中文版本。4.2 DXMT 的 Metal 后端配置DXMT 默认会尝试使用 Metal 3 的特性但 iOS 上 Metal 版本和设备芯片相关。A12 设备只支持 Metal 2如果强制开启 Metal 3 特性会导致渲染失败。配置文件在dxmt.conf里关键参数如下参数推荐值说明metal_version2A12-A14 设为 2A15 以上可设 3max_frame_latency2降低输入延迟但可能增加功耗shader_cachetrue启用着色器缓存减少卡顿resolution_scale0.75降低渲染分辨率提升帧率我实测下来把 resolution_scale 调到 0.75 之后一款 DX11 游戏的帧率从 18 帧提升到 27 帧画面虽然略糊但可玩性大幅提高。另外DXMT 的日志级别建议设为 warn避免频繁写日志拖慢速度。4.3 FEX-Emu 的缓存与线程调优FEX-Emu 在首次运行程序时会进行大量翻译表现为启动慢、卡顿。它有一个块缓存机制翻译过的代码块会存到磁盘下次启动就快很多。缓存目录默认在~/.fex-emu/你可以把它放到更快的存储位置。另外FEX-Emu 支持多线程翻译在 iOS 上可以设置FEX_TSOENABLED1和FEX_MULTIBLOCK1来提升效率。但要注意iOS 对后台线程数量有限制线程开太多反而会触发系统降频。我的经验是A12 设备设 2 个翻译线程A15 以上设 4 个再高收益就不明显了。还有一点FEX-Emu 的 RootFS 需要包含基本的 Linux 库建议用官方提供的 RootFS 镜像自己裁剪容易缺库。5. 实操过程从零跑通一个 Windows 程序的完整记录5.1 创建 Wine 前缀与初始化环境第一步是在 iOS 设备上创建 Wine 前缀prefix也就是模拟的 C 盘环境。通过 SSH 或者终端应用进入设备执行export WINEPREFIX~/wine-ios export WINEDEBUG-all wineboot -uwineboot 会初始化注册表、创建目录结构。这个过程在 iOS 上可能耗时 1 到 2 分钟期间不要中断。初始化完成后把需要运行的 Windows 程序复制到drive_c/Program Files/下面。5.2 安装必要的运行库很多程序依赖 Visual C 运行库或者 .NET Framework。Wine 自带了部分实现但完整度不够。我建议用 winetricks 安装常用组件winetricks vcrun2019 dotnet48 corefonts注意dotnet48 在 iOS 上安装成功率不高因为需要重启 Wine 服务而 iOS 的后台限制可能导致安装中断。如果失败可以尝试 dotnet6 或者直接用 mono 替代。corefonts 是安装微软核心字体对解决部分乱码也有帮助。5.3 启动程序与图形参数调整运行程序时建议先用窗口模式启动方便排查问题wine program.exe -windowed如果程序全屏后黑屏可能是 DXMT 的交换链配置问题。可以在 dxmt.conf 里把vsync设为 false或者调整present_mode为immediate。另外iOS 的屏幕比例和桌面不同部分程序会出现画面拉伸需要在 Wine 的显示设置里手动指定分辨率比如 1280x720 这种标准比例。我跑一个老游戏时启动后画面闪烁日志显示 Metal 命令缓冲区提交超时。后来把 max_frame_latency 从 3 降到 2问题就消失了。这说明 iOS 的 GPU 调度比桌面更敏感参数需要更保守。5.4 性能监控与瓶颈定位在 iOS 上监控 Wine 程序的性能可以用 Xcode 的 Instruments 工具连接设备后选择 Metal System Trace 和 Time Profiler。重点看两个指标GPU 占用率和 CPU 翻译线程的负载。如果 GPU 占用不高但帧率低瓶颈可能在 FEX-Emu 的翻译效率如果 GPU 占用接近 100%则需要降低渲染分辨率或关闭一些特效。我记录了一组对比数据同一款 DX9 游戏在 iPhone 14 上原生 ARM64 运行如果有 iOS 版能跑 60 帧通过 Wine FEX-Emu DXMT 只能跑 25 到 30 帧。性能损耗大约在 50% 到 60%这个数字供大家参考。6. 常见问题与排查技巧实录6.1 启动崩溃与日志分析Wine 程序在 iOS 上崩溃第一手信息在~/wine-ios/drive_c/windows/temp/下的日志文件以及系统控制台里 FEX-Emu 的输出。常见错误码和原因如下错误现象可能原因解决方向启动即闪退缺少 get-task-allow 权限重新签名添加 entitlements报错找不到 DLLWine 未实现该 API用 winetricks 安装对应运行库画面全黑但有声音DXMT 交换链配置错误调整 present_mode 和 vsync中文显示为方块字体缺失安装中文字体并修改注册表运行几分钟后卡死iOS 内存限制触发降低 resolution_scale关闭后台应用6.2 签名失效与重签流程免费证书 7 天过期后程序无法启动提示“无法验证应用”。这时候需要用 AltStore 或 Sideloadly 重新签名安装。如果之前的数据在 Wine 前缀里重签不会丢失因为前缀目录在应用沙盒的 Documents 下。但要注意重签后应用的 UUID 可能变化部分程序会认为硬件变了需要重新激活。我一般会在重签前备份整个 wine-ios 目录以防万一。6.3 输入法与触控适配iOS 上没有物理键盘和鼠标Wine 程序的操作依赖触控映射。Wine 本身支持触摸屏作为指针设备但右键、滚轮等操作需要额外配置。我试过用winecfg里的触摸设置把长按映射为右键双指滑动映射为滚轮。对于游戏可以外接蓝牙手柄Wine 能识别为 XInput 设备兼容性比触控好很多。输入法方面iOS 系统输入法无法直接输入到 Wine 程序里因为 Wine 使用的是 Windows 输入法框架。解决办法是在 Wine 里安装一个 Windows 输入法比如极点五笔或者微软拼音然后通过触控点击输入框调出。这个过程比较繁琐日常使用建议尽量选不需要大量文字输入的程序。6.4 网络与代理相关注意事项部分 Windows 程序需要访问网络Wine 会使用 iOS 的系统网络栈。如果程序内部设置了代理需要在 Wine 的注册表里配置路径是HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings。但要注意iOS 对后台网络活动有限制程序切到后台后连接可能中断。对于需要保持长连接的程序建议在前台运行并在设置里关闭低电量模式。7. 个人实操心得与后续可扩展方向折腾这套方案的过程中我最大的体会是不要追求一次跑通所有程序而是先找一个最简单的 Win32 小工具作为基准把整个链路跑通再逐步替换成更复杂的程序。我一开始就拿一个 DX11 游戏开刀结果卡在图形初始化上一周没进展后来换了一个记事本类的小工具半天就搞定了信心和排查思路都清晰了很多。另一个心得是关于版本锁定。Wine、FEX-Emu、DXMT 这三个项目都在快速迭代新版本可能修复旧问题也可能引入新问题。我建议在验证成功的组合上打一个快照记录下各个仓库的 commit hash后续除非有明确需求否则不要轻易升级。我就因为手贱升级了 FEX-Emu导致之前能跑的游戏全部黑屏回滚后才恢复。后续如果想继续深入有几个方向可以尝试一是把 Wine 的前缀做成可移植的包方便在不同设备间迁移二是研究如何利用 iOS 的 MetalFX 超分技术在低分辨率渲染的基础上提升画面清晰度三是探索将这套方案与 uniapp 或原生 iOS 插件结合让 Wine 程序以组件的形式嵌入到普通 App 里。这些方向我还没有完整验证但思路上是可行的有兴趣的朋友可以接着往下挖。最后分享一个小技巧如果 Wine 程序在 iOS 上运行一段时间后越来越卡可以尝试在 FEX-Emu 的配置里开启FEX_APPLE_SILICON1这个选项针对苹果芯片做了内存屏障优化能减少翻译线程的等待时间。我在 iPhone 15 上开启后长时间运行的帧率稳定性提升了大约 15%。