Darling – macOS Translation Layer for Linux

Darling – macOS Translation Layer for Linux
darlinghq.org

Rely on some developer(s) spend 10,000 hours of their time for free developing a Mac emulation layer, or go on eBay and buy a $600 used Mac to test on...

> OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac?

You don't. Darling is not a suitable replacement for testing on a real Mac in exactly the same way WINE is not a suitable replacement for testing Windows software. A developer who thinks so is misguided.

Virtualising macOS would be more suitable, although the only way to do so without violating macOS' licence conditions is to run the virtualised OS on a Mac anyway. Even then, virtualised macOS lacks hardware accelerated graphics support, limiting the testing of GUI apps at least.

> Apple shouldn't sue you

There's no reason they would. Nothing of Apple's seems to be infringed, as the system seems only capable of running anything that Apple's open source Darwin OS can.

Even if the Darling project reimplemented some of Apple's proprietary frameworks, this could be done based on Apple's open source releases of things such as Core Foundation, etc. The reimplementations of things like AppKit, when done in the future, could even possibly be based on something like GNUstep — which would give that project a well-needed shot in the arm, to say the least.

> additional software for their platform ultimately benefits their platform

Firstly, any well-written cross-platform software is easily ported to macOS. This is most evident with software intended for FreeBSD but is equally possible with software that originates on Linux; see Homebrew, MacPorts, etc. for the plethora of utilities that began life on Linux but have since become cross-platform, or software made by GNU that is typically cross-platform by design.

Secondly, Apple has been down the cross-platform road before, and none of its developers wanted a bar of it. Apps that are developed on other systems but not tested properly on macOS are always heavily criticised by macOS users as feeling foreign and un-Mac-like.

Back when Mac OS X was shiny and new, Apple offered three major platforms for developers: Cocoa, their C and Objective-C APIs inherited from NeXTSTEP; Carbon, their C and C++ APIs inherited from Classic Mac OS; and Java, a cross-platform offering to entice developers from other platforms, particularly Linux.

Apple deprecated their own Java in 2010 because (A) people really disliked using Java apps, even though Apple's implementation of the JVM was performant and had native support for Cocoa-style controls and (B) nobody was using it, with major preference going to Apple's own Cocoa and Carbon APIs.

Apple, and its userbase, prefer apps that are made with love and care _on_ Macs and _for_ Macs/iOS devices/Apple Watches/Apple TVs, respecting those platform conventions by being developed and tested on them.