Darling: macOS compatibility for Linux

There is an increasingly active development effort, known as Darling, that is aiming to provide a translation layer for macOS software on Linux; it is inspired in part by Wine. While Darling isn't nearly as mature as Wine, contributors are continuing to build out capabilities that could make the project more useful to a wider group of users in the future.

The project released a progress report for the second quarter of 2019 on July 23 outlining recent contributions and the state of the project overall:

According to the project's website, the name Darling is a combination of "Darwin" and "Linux". Darwin is an open-source effort that is at the foundation of macOS, providing a Unix-based layer that macOS is built upon.

Licensing

Darling is licensed under GPLv3 and, according to the project home page, it does not violate Apple's End User License Agreement (EULA) since it only uses the parts of Darwin that have been released as free software. Darwin, however, is licensed under the Apple Public Source License (APSL), which is a free-software license, but is not compatible with the GPL according to the FSF.

In an issue posted on BountySource on July 25, Richard Yao suggested that Darling opt for a different license, such as the LGPLv2.1, which in his view would be compatible with the APSL. Darling contributor Lubos Dolezel disagreed, saying that it is possible to distribute GPL code with differently licensed code:

It is not clear that this reasoning would extend to the kernel module, which is licensed under the GPL but that, according to Yao, contains a fair amount of XNU (Darwin kernel) code that is under the APSL.

Beyond Darwin

There are also tools and libraries outside of Darwin that are part of Darling, including Cocotron, which is an open-source implementation of Cocoa — Apple's API layer for desktop applications.

In an interview, Darling contributor Andrew Hyatt explained that it's best to think of the project as being made up of many different components. Anything on https://opensource.apple.com/ that is useful is pulled down and included by the project. "This is typically command line tools but does include some system libraries/frameworks, such as Security and libsystem," Hyatt said. "Things like AppKit have source unrelated to Apple. We based our AppKit and Foundation on the source of Cocotron, which was outdated when we forked it but we have been slowly adding missing bits to it. I'd say the issues we face are from our implementations being incomplete more than they are divergent."

AppKit is a framework that includes libraries and objects used to build user-interface elements for an application. There are many other frameworks that are now being added into Darling, with a good number of them started in the past quarter by contributor James Urquhart. The report noted that Urquhart's pull requests gave the project more stubs for many frameworks.

Urquhart explained in an interview that stubs are basic implementations of API functions that are meant to allow programs which use the API to load. "In most cases they do absolutely nothing besides this, so they don't provide any guarantees that the program will run correctly," he said. "So the stubs are mere stepping stones to implementing the full required API."

Among the framework stubs that Urquhart contributed is AGL, for creating and managing OpenGL rendering contexts. There are also multiple stubs contributed by Urquhart for frameworks that are related to Carbon, which is a C-based API used for enabling backward compatibility for Mac OS 8 and 9 applications on Mac OS X. The Core Services framework works with Carbon to provide identity and other services, while ApplicationServices brings additional features to Carbon.

Urquhart explained that, in general, the focus for his contributions was to get legacy applications running on a basic level, without a graphical user interface (GUI). This required stubs implemented for the aforementioned frameworks in order for the executable to even load.

The Darling status update also mentions the challenge of nested frameworks within macOS:

What can you do with Darling?

Unlike Wine, Darling cannot run full macOS GUI applications such as the Xcode IDE on Linux yet. Xcode is a collection of Apple's core development tools that are used for building both macOS and iOS applications. Urquhart said that he's not using Darling in any production environment — most of his tinkering at the moment is for proof-of-concept work.

While a full-GUI macOS application won't run on Linux via Darling, that doesn't mean that macOS applications won't work. Hyatt explained that, if what you want to run can be done from the command line, there is a decent chance it will work. "In the past year we have made some big steps towards getting xcodebuild working, which allows you to compile Xcode projects from the command line," Hyatt said. "I think if we get that fully working it will really grow the project because then it would be possible to build your iOS/macOS apps on a Linux server."

Hyatt highlighted a GitHub issue for the Darling project that illustrates an interesting use case. In that issue, Tom Medema asked if it was possible to run sketchtool, which is the command-line interface for the popular Sketch macOS app. Progress has been made, as can be seen in the bug report, to the point that it will start up and print its usage text.

Another use case for Darling in the future could be for 32-bit software. With the upcoming macOS Catalina release set for later this year, Apple is dropping support for 32-bit applications. Hyatt emphasized that Darling has no such plans and will continue to include 32-bit support. "Our position also allows us to potentially have better compatibility for older apps than macOS itself because we can bake in conditional logic into our APIs that behaves in a more compatible way for older programs," he said.

Looking forward, Hyatt commented that he expects that people will merge patches to improve compatibility for applications they want to use Darling for. "It's tough to put a number on full GUI app support," he said. "If it's in years, I'm not sure how many, I guess it depends on if we can attract even more contributors with the skill and time to work on that."

Overall, it remains to be seen how successful Darling will become and if it will eventually emulate Wine's success by enabling a broad range of macOS applications to run on Linux. It took years of effort for Wine to become stable and it is a continuous effort to enable a growing list of applications; the same trajectory is likely for Darling. What is clear is that there is a dedicated group of developers who are interested and committed to figuring out how make the macOS application layer work in some capacity on Linux.