Darling, an open-source project dedicated to running macOS software on Linux, is shifting its development strategy to address the 'unsolvable' problem of matching Apple's massive engineering capacity. By adopting a formal policy for AI-assisted contributions, the project aims to accelerate the implementation of thousands of macOS frameworks that have expanded significantly in recent years.

Scaling Against Apple's Framework Expansion

The scale of the macOS platform has become a significant hurdle for a volunteer-led project. Between macOS 10.14 and macOS 27, the number of public frameworks grew from 273 to 464, while private frameworks jumped from 878 to 2,754.

A screenshot of Apple's Render Pipeline sample running under the Darling compatibility layer.
The Darling project enables the execution of Apple's Render Pipeline sample on Linux systems.blog.darlinghq.org

This image demonstrates the project's ability to run Apple's graphics-related frameworks on a non-macOS platform.

macOS Framework Growth: macOS 10.14 Public Frameworks 273 frameworks; macOS 27 Public Frameworks 464 frameworks
macOS Framework Growthblog.darlinghq.org

Chart drawn by HN Digest from figures reported by blog.darlinghq.org; values are shown as written in the source.

Unlike Wine, which can leverage Microsoft's redistributable runtimes, Darling must implement most of Apple's frameworks from scratch. The project's new AI policy is designed to bridge this capacity gap, allowing the team to compete on more level ground with Apple's engineering resources.

“AI changes the equation. What used to be an unsolvable problem with few contributors is now financially realistic, and it lets us compete with Apple on something closer to level ground.”

— Development Update - Q4 2026 | Darling Development Blog

AI Policy and Clean-Room Rules

The new AI policy is structured as instructions for AI agents but binds the human contributors who use them. To maintain integrity, the project enforces 'clean-room' rules: developers must implement documented contracts rather than hacks for specific applications and must be able to explain every line of submitted code in their own words.

A key restriction is the prohibition of using disassembly to produce matching code. While disassembly may be used to document behavior, the AI agent writing the code is never allowed to see the disassembly; it only receives a separate behavioral description produced in a different context.

Architecture Support and Infrastructure

Darling is introducing initial ARM64 support to remain relevant as Apple moves away from Intel architecture. This support is bolstered by the VibeDarling fork, which is actively developed on ARM64 and will be folded back into the main project.

To improve stability, the project moved away from a Linux kernel module (LKM) in 2022. It now uses 'darlingserver,' a userspace kernel server that handles Mach IPC and psynch calls via a Unix RPC socket, preventing the kernel panics and freezes associated with the previous LKM approach.

Future Goals and Limitations

The project's short-term goal is to merge work from various forks back into the main Darling codebase using agent-driven merging logic. Long-term plans include stabilizing AppKit support to improve the visual appearance of applications and developing native tools like a configuration utility and a log viewer.

A notable limitation remains the lack of commercial backing. While the project is seeing success with specific applications like League of Legends and TextEdit, it continues to rely on volunteer efforts and community-driven forks to maintain momentum against Apple's proprietary ecosystem.

A screenshot of the native Apple TextEdit application running successfully via Darling.
TextEdit is one of the specific applications successfully running under the Darling project.blog.darlinghq.org

This visual provides a concrete example of the project's success in running standard macOS applications.