Two Projects for Running Mac Software Elsewhere Hit the Front Page and Nobody Named the App
RavynOS and Darling both hit Hacker News on the same day, 5 and 14 years in. Across 159 comments, the recurring question was which Mac application anyone actually wanted to run.
The WJS Desk
Sep 1, 2026 · updated 2 hours ago · 5 min read
Two projects for running macOS software somewhere other than a Mac hit the Hacker News front page on the same day. RavynOS took 185 points and 105 comments, Darling took 177 points and 54 comments. One has been going since 2012, the other since 2021.
Between them the threads produced 159 comments and, as far as we can tell, not one person naming an application they wanted to run. That absence turns out to be the story.
What the two things are
They solve different halves of the same problem. Darling is a runtime that loads Mach-O binaries and provides a userspace so macOS applications run on Linux without a virtual machine. RavynOS is a whole operating system, built on FreeBSD with Apple's open-source Darwin components, aiming for macOS-like behaviour end to end.
| Darling | RavynOS | |
|---|---|---|
| Started | December 2012 | January 2021 |
| Stars | 13,185 | 6,960 |
| Language | Objective-C | C |
| Licence | GPL-3.0 | None detected by GitHub |
| Commits since 1 June 2026 | 22 | 100+ |
| Open issues | 398 | 86 |
| Contributors listed | 73 | 43 |
The commit counts are worth pausing on, because one thread claimed the opposite of what we found. Commenter porphyra said of Darling that it is "kinda sad that there are very few updates though," linking the project blog. The blog is quiet, but the repository is not dead: 22 commits in three months is slow, not abandoned. RavynOS, the younger and less starred project, is currently moving considerably faster.
Both threads found the same problem
Two commenters, in two different threads, independently landed on architecture. From the RavynOS discussion, itsrobreally:
I'm sort of surprised that development is still on X86 instead of moving over to ARM, it looks like the only builds for ARM are for raspberry pi. I know about Asahi but I would have thought that these darwin-based projects would have a leg up on booting even the latest hardware.
And from the Darling thread, porphyra:
In theory, running Apple Silicon apps on ARM64 linux machines would be really nice. But we are still far from having a performant and feature-complete implementation of doing so. Darling only targets x86_64 stuff.
We could not confirm Darling's architecture support from its own documentation, so treat that as an attributed claim rather than a checked one. RavynOS is more visible: its most recent toolchain release is published as ravynOS_Toolchain_Linux_x86.tar.xz, which is about as clear a statement of target as a filename can make.
Apple moved the Mac to its own ARM silicon in 2020. A compatibility project targeting x86_64 in 2026 is chasing an architecture that new Mac software has not been built for in years, and the gap widens every release.
Nobody could name the app
The question that kept surfacing was not technical. nonestdeus: "I honestly don't even know which mac exclusive program I would want to install." Alien1Being, who has used Linux since the 1990s and a Mac since 1988: "Is there some really amazing Mac only software that would justify the effort?"
The one concrete answer was retrospective. LollipopYakuza said that a few years ago they would have dreamt of running Photoshop on Linux, but that it and its mandatory utilities "became so bloated that even if it was officially offered on Linux I am not sure I would be using it."
The killer app these projects were built to reach either moved to the browser, moved to a subscription, or got heavy enough that nobody wants it any more.
That is a harder problem than architecture. Wine has a permanent constituency because Windows games and a long tail of line-of-business software genuinely do not run anywhere else. The macOS equivalent has thinned out: Final Cut and Logic are the honest answers, and both are exactly the deeply integrated Apple software a compatibility layer is least likely to reach.
The case for doing it anyway
The best comment in either thread was about preservation, not productivity. throwaway19567 argued that macOS binaries are the most susceptible to bit rot of any major platform: constant closed-source platform churn, and nothing like the community that keeps old Windows software running. You can run DOS, Windows and Linux software of almost any vintage with the right translation layer, and there is, in their words, a black hole of macOS applications from roughly 2002 to 2012.
That reframes the work. If the goal is running today's Mac apps on Linux, the architecture problem is close to fatal and the demand is unclear. If the goal is that software written for the Mac in 2006 should still be runnable in 2046, x86_64 Darling is exactly the right target, because that is what those binaries are.
Nobody in either thread was pitching it that way, which is a shame, because it is the version of the pitch that survives contact with the objections.
Two corrections worth carrying
jagged-chisel supplied the precision the headline lacked: it will run anything that runs on open-source Darwin, and you will not be running anything that needs macOS frameworks Apple never published. That is the boundary, and it is a large one.
On the legal question, RavynOS answers it directly in its own FAQ, pointing at ReactOS for Windows, GNUstep for Cocoa APIs, and Darling itself as precedent for clean compatibility work. The projects are also more entangled than they look: commenter jeandrek noted that at least one developer works on both PureDarwin and RavynOS, and Darling's own documentation credits The Cocotron, the Apportable Foundation and GNUstep for its Cocoa implementation. This is one small community reusing each other's work, not competing efforts.
Why this keeps coming back
The moderator note in the RavynOS thread listed prior front-page appearances in November 2025 with 165 comments, December 2023 with 176, and August 2022. Four visits, hundreds of comments each, over four years.
Something that resurfaces that reliably is answering a real want. The want is not "run Mac apps on Linux," which nobody in 159 comments could make concrete. It is closer to wanting the Mac's design without Apple's control, and that is a desire an operating system can address even if the compatibility layer never finishes.
Which suggests RavynOS has the better long-term position despite fewer stars. A macOS-flavoured FreeBSD is useful the day it is pleasant to use, whether or not it ever runs Final Cut. A compatibility layer is only useful when it runs the specific thing you needed, and right now the threads cannot agree on what that is.
What would change our read: either project shipping a credible ARM64 target, or someone finally naming the application. The second would tell us more than the first.
