Darling is the closest thing there is to a Wine for macOS: a free (GPL-3.0) compatibility layer that loads Mach-O binaries on Linux and gives them the libraries and system calls they expect. It has been in development for more than a decade and has almost 14,000 stars on GitHub, but in 2026 it had barely moved: the last change merged before October dates from 6 September.
In November that changed overnight. Its founder, Luboš Doležel, has opened 85 pull requests since the 1st, after opening none between January and October. And he doesn’t hide how: at least 40 commits in the repository carry a Co-Authored-By: Claude Opus 5.5 line.
Rules first
The change of pace didn’t go unnoticed. On 2 November a user opened an issue asking for “a clear and official AI policy”, with a list of awkward questions: which parts of the project accept AI, how the project makes sure no proprietary Apple code gets in, what happens if a model was trained on leaked code, and how quality is kept up.
The answer came two days later as an AGENTS.md, a file that tells an AI agent how to behave in the project and, above all, sets obligations for the humans:
- Whoever opens the PR answers for every line. They must be able to explain what the change does, why it is correct and why it follows the rules, “in your own words”. “The agent wrote it and followed AGENTS.md” is not an acceptable answer, and a PR whose author can’t explain it may be closed regardless of how it was produced.
- No replying through the bot. When a maintainer asks a question, they expect the human to answer, not text pasted from an assistant.
- Implement the documented contract, not an app. Special cases keyed on app name, bundle ID or version to make one program work are forbidden.
- Respect macOS’s layering. If one framework sits on another in Apple’s system, it must do so in Darling too, and every bug is fixed in the layer where it originates.
- Undocumented quirks get flagged. When an app depends on behaviour Apple never documented, Darling can mimic it, but isolated, with a
QUIRK:comment stating where the evidence comes from and a test that fails without it.
Then the most delicate part, the legal line. The file bans using disassembly or decompilation of Apple binaries as evidence, along with any leaked or confidential material and the code of corecrypto, Apple’s cryptographic library, whose source can be read but not reused. After the discussion it was extended to cover any future code released on those terms, and leaks.
In the thread, the user who asked for the policy pressed on a specific risk: a model can reproduce code it memorised during training, and there’s no way to tell when it does. Doležel replied that PRs touching corecrypto will be cross-checked against Apple’s implementation to make sure they aren’t a copy. On quality he was blunter: in his experience, code from frontier models is “much higher” quality than what the average contributor sends, as long as the person driving them knows what they’re doing. Enforcement is up to the reviewer.
What has already landed: Darling on ARM64
The biggest change is ARM64 Linux host support, merged on 6 November (PR #1818, around 6,500 new lines). Until now Darling only ran on x86-64. With this change, on an aarch64 machine darling shell starts and runs native arm64 Mach-O binaries: bash, coreutils, pipes and job control, launchctl, Perl 5.18, Ruby 2.6 and Python 2.7.
The PR brings together several people’s work: a base port by another contributor, fixes from a second patchset and bugs found while testing on an aarch64 kernel, some picked with attribution from third-party forks called VibeDarling. Doležel sums it up in a comment: “I used Claude to get it running + I told it to check VibeDarling for hints.”
There’s more in this month’s PR list: hardening of the launcher (setuid, guest environment, prefix checks), missing public constants in several frameworks with the values macOS uses, signals now forwarded to the foreground job, and work on uploading OpenGL 3D textures.
Darling versus Reef
The timing is striking. This very morning we covered how Cutefish is building Reef, its own layer to run Mac apps on Linux. The two projects attack the same problem from opposite ends:
| Darling | Reef (Cutefish) | |
|---|---|---|
| Licence | GPL-3.0, open source | Closed “for now” |
| Where it runs | Any Linux distribution | Only on Cutefish |
| What it runs today | Mostly command-line tools | Only graphical apps |
| Built from | Apple’s open source pieces (xnu, dyld, objc4…) plus its own frameworks | About 460,000 lines of its own code plus a few Apple open source pieces |
| Architectures | x86-64 and, since November, ARM64 | Not stated |
Cutefish says Reef uses no Darling code. We found no reference to Reef in Darling’s repository.
Our take
It’s a good example of what AI is doing to small projects: a maintainer working almost alone on a stalled project gets years’ worth of pace back in weeks. Darling has done what other projects are still arguing about: write the rules down before the patch flood swallows it. Its rules are stricter than usual on the legal side, and rightly so: a project that reimplements macOS and ends up with copied Apple code is asking for serious legal trouble.
It remains to be seen whether the pace holds and whether it reaches what it lacks most, graphical apps. Meanwhile, for anyone running Linux on an ARM64 laptop, Darling is already an option for Mac command-line tools. For the Apple side there’s our macOS page, and the Cutefish page to follow Reef. We covered the wider debate in how Linux, Mesa, PostgreSQL and FreeRDP handled AI-made patches.
Sources: Darling repository and its AGENTS.md; issue #1806, “Please document a clear and official AI policy” and PR #1811, “Add AGENTS.md”; PR #1818, “ARM64 (aarch64) Linux host support”; Luboš Doležel’s PR list; Darling website.