一个叫Darling的开源项目最近又发了新版本，官网首页写着一句挺唬人的话：完整实现了Darwin环境，Mach、dyld、launchd一应俱全，目标是让macOS软件在Linux上"看起来、用起来、行为都跟原生应用一样"。它甚至专门解释了不违反Apple EULA的原因——只用了苹果已经开源的那部分Darwin代码。
这套说辞听起来像极了当年的Wine：一个翻译层，不用虚拟机也不用硬件模拟，直接让Windows软件跑在Linux上。但把Darling这两年半的版本记录摊开看，会发现一个官网FAQ不会主动告诉你的事实：GUI支持几乎停滞了。2025年2月一位维护者回答"图形界面到哪一步了",给出的答案是"简单的Hello World级别程序能跑，复杂GUI应用预期失败"；到2026年9月,类似的问题得到几乎一模一样的回答。中间隔了一年半，三个版本迭代。
版本更新在补什么，答案很诚实
2025年10月、2026年2月、2026年6月的三次发布，内容集中在QuickTime、Message、PubSub、SystemConfiguration相关的符号补全，加上Xcode/CoreServices的库支持和Fedora 44构建修复。翻译过来就是：项目在拼命给命令行工具和底层框架"填坑"，没有一条更新是冲着GUI去的。
官方文档自己列出的"已知不可用"清单更直接：Xcode图形界面、Logic、Final Cut Pro、Adobe全家桶、Mac Catalyst应用、Python的Tkinter、MacPorts，全部跑不起来。Hacker News上有用户测试过，Clang能正常工作，一碰原生Cocoa应用就崩，核心库缺失。Reddit上讨论Sketch这类设计软件时，社区共识也是"目前不指望"。
卡住的不是人手，是苹果的服务化架构
Wine花了近三十年才把Windows兼容度做到今天这样，靠的是Windows API相对公开、文档齐全，加上Proton这类商业资金和庞大的AppDB社区数据库常年迭代。Darling面对的对手完全不同：AppKit、Cocoa、Metal、CoreAudio、XPC里大量是苹果从没公开过的私有接口，官方只放出了内核层的部分代码。
Darling官方"高优先级"文档里承认，缺失的XPC-domain支持和LaunchServices/UTI数据库，大部分涉及苹果私有API——这不是接上一个守护进程启动器就能解决的活，而是要逆向理解一整套没有文档的服务通信协议。今年5月社区讨论提出用Vulkan模拟Metal、Skia实现Quartz 2D绘制，作为未来图形后端方向，但这只是贡献者提案，维护者对部分方案持保留态度，远没进入路线图。
命令行能跑不等于桌面能用，苹果的护城河从来不在API文档里
- 风险.项目同时在推进ARM64支持（PR仍开放中），但官方构建文档要求宿主必须是64位x86 Linux，这意味着连Darling自身在ARM64上的运行都处于早期阶段,更谈不上让它在ARM64主机上跑Intel版macOS应用。多线程推进，基础可用性反而卡在原地。
合法性上有一层容易被忽略的分界
Darling反复强调"不违反Apple EULA"，这句话本身没错——项目代码基于苹果已开源的Darwin部分，加上The Cocotron、Apportable Foundation、GNUstep等既有开源实现拼出来的Cocoa层，属于独立实现，受美国版权法第1201(f)条款的互操作性豁免保护。
但这只回答了"Darling这个项目合不合法"，没回答"你在上面跑的具体苹果软件合不合法"。苹果现行的macOS许可协议标题就是"仅限用于苹果品牌系统"，Darling自己的安装文档也提醒过，Xcode和苹果命令行工具受Apple EULA约束。项目合法与软件合法是两件独立的事，企业如果想拿Darling跑苹果开发者工具做CI流水线，这条界限值得先看清楚。
- 结论.Darling目前对Linux极客和需要交叉编译、测试Mach-O二进制的开发者有实际价值，但如果是冲着Xcode、Final Cut或Adobe这类GUI软件去的，现在还不是时候。