Wine works because Microsoft spends billions on backwards compatibility and APIs are stable over time.
Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.
If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.
I've been paying attention to this project periodically over the past few years. It would be nice to have a FOSS clone of macOS, similar to how FreeDOS, ReactOS, and Haiku are FOSS clones of MS-DOS, Windows, and BeOS, respectively.
The only thing is that this project has been quite slow going, which is similar to the histories of FreeDOS, ReactOS, and Haiku, where it took a long time for those projects to get to a usable state. It is a lot of work cloning an operating system, especially with an aim for binary compatibility. The Linux kernel benefited from the fact that there was an entire GNU ecosystem of tools that can run on Unix, and even in that case, the GNU ecosystem was seven years in the making in 1991 when the first version of the Linux kernel was released. It would've taken much longer for Linux to have been developed had GNU tools not existed.
Writing an entire operating system is long, hard work, even when provided the resources of companies like Microsoft, Apple, and Google. Hopefully projects like ravynOS and the similar HelloSystem (https://hellosystem.github.io/docs/) will lead to FOSS clones of macOS eventually, even if we need to wait another 5-10 years.
Sometimes it strikes me that something like this might be one of the better litmus tests for AI — if it’s really good enough to start 10x-ing engineers (let alone replacing them) it should be more common for more projects like this should begin to accelerate to practical usability.
If not, maybe the productivity dividends are mostly shallow.
Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
On large code-bases like this, where a lot of context gets pulled in, agents start to cost a lot very quickly, and open source projects like this are usually quite short on money.
The problem is that many of these clean room reimplementations require contributors to not have seen any of the proprietary source. You can't guarantee that with ai because who knows which training data was used
Are those OSes actually that strict about contributors? That’s got to be impossible to verify and I’ve only seen clean room stuff when a competitor is straight up copying another competitor and doesn’t want to get sued
ReactOS froze development to audit their code.[1] Circumstantial evidence was enough to call code not clean. WINE are strict as well. It is impossible to verify beyond all doubt of course.
In an actual business environment, you are right that its not a 10x gain, more like 1.5-2x. Most of my job as an engineer is gathering and understanding requirements, testing, managing expectations, making sure everyone is on the same page etc...it seems only 10-20% is writing actual code. If I do get AI to write some code, I still need to do all of these other things.
I have used it for my solo startups much more effectively, no humans to get in the way. I've used AI to replace things like designers and the like that I didn't have to hire (nor did I have the funds for that).
I can build mini AI agents with my engineering skills for simple non-engineering tasks that might otherwise need a human specialist.
This was my thought here as well. Getting one piece of software to match another piece of software is something that agentic AI tools are really good at. Like, the one area where they are truly better than humans.
I expect that with the right testing framework setup and accessible to Claude Code or Codex, you could iterate your way to full system compatibility in a mostly automated way.
If anyone on the team is interested in doing this, I’d love to speak to them.
> A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience.
I am curious - what is the motivation for this project?
Is it to replicate macOS? - If yes, why?
Is it to provide application compatibility on a non-macOS? If yes, why a full OS? Why not take the route like Wine or other such layers that make compatibility possible? Also, is there such a need for running macOS apps on a non-macOS? Who is the target audience?
Would the energy be better spent in making Linux more stable or usable for the general public?
The goal for ravynOS is to be analogous to ReactOS. Much like ReactOS and WINE, ravynOS and Darling share a lot of Cocoa code.
For the problem of OpenStep implementations specifically, a bespoke software stack has the benefit of being able to put Mach messaging into the kernel, where it is much more performant.
They chose the FreeBSD kernel over Darwin for the sake of hardware compatibility (though of course NeXT Mach is one of the most widely-ported kernels of all time...)
There is also overlap with GNUstep, helloSystem, and other projects in the broader "open-source Mac/NeXT" space, though ravynOS (obviously) prefers BSD/MIT/Apache-style licensing over GNU-style licensing. Nevertheless, ravynOS currently uses the GNUstep libobjc2 runtime, a bit like how most of the Unix world used to depend on gcc.
"We love macOS, but we’re not a fan of the ever-closing hardware and ecosystem. So, we are creating ravynOS — an OS aimed to provide the finesse of macOS with the freedom of FreeBSD."
rayvnOS seems to be designed for people who love macOS, particularly its interface, its UI guidelines, and its ecosystem of applications, but who do not like the direction that Apple has moved toward under Tim Cook (soldered RAM, limited and inflexible hardware choices, notarization, iOS-influenced interface changes, increased pushiness with advertising Apple's subscription services, etc.) and who would be unhappy with either Windows or the Linux desktop.
Speaking for myself, I used to daily-drive Macs from 2006 through 2021, but I now daily-drive PCs running Windows due primarily to the lack of upgradable RAM in ARM Macs. I'm not a big fan of Windows, but I need some proprietary software packages such as Microsoft Office. This makes switching to desktop Linux difficult.
It would be awesome using what is essentially a community-driven clone of macOS, where I could continue using a Mac-like operating system without needing to worry about Apple's future directions.
On the Unix side of things, I believe the decision to base ravynOS on FreeBSD rather than on Linux may make migrating from macOS to ravynOS easier, since macOS is based on a hybrid Mach/BSD kernel, and since many of the command-line tools that ship with macOS are from the BSDs. This is known as Darwin. It's not that a Mac clone can't be built on top of Linux, but FreeBSD is closer to Darwin than Linux is.
This description really resonates with me, so I guess I’m a potential user.
I’ve been running macOS most of my life. In college I ran Linux on my laptops, but I switched back to macOS as the user experience was better - I could spend far less time messing with things and instead rely on system defaults and first party apps.
Year by year though I feel more like I don’t own my computer. I’ve tried switching back to Linux, but I always give up because despite the freedom, it starts feeling like a chore. Even Asahi Linux on macOS hardware I couldn’t get into.
The rayvnOS vision is something I could get behind. A fully packaged, macOS-like user experience, where the default settings are good and things work out of the box. I’d LOVE to have that as on option.
Linux compatibility or even macOS binary compatibility matters less to me than, say, an out of the box Time Machine like backup tool based on ZFS snapshots. So FreeBSD makes sense from that perspective.
So somehow running MacOS in 2025 on hot, loud, horrible battery life x86 based computers is a good thing?
Not to mention x86 Mac apps are not long for this world. I can’t think of a single application I would miss moving from Macs to Windows. It’s more about the hardware and the integration with the rest of my Apple devices.
Notes and Reminders are extremely good at what they do, and the synchronization with their iOS equivalents is flawless from what I can tell… and fat chance you get to uproot such a thing to a non-Apple OS.
Third party apps other than for media editing seem to be rare, I think Apple has gobbled or rug pulled much of its independent software vendor ecosystem.
Apple Mail also is in my eyes the only generic mail client out there that really “gets it”.
Thunderbird has always felt clunky in comparison and the recent redesign just made it a different kind of clunky. Everything else is either too minimal (Geary), tries to clone old style Outlook (Evolution), or is tied to/favors a particular provider (Gmail, Outlook, etc).
This. I use Linux as my primary OS (with KDE) and my main complaint, by far, is the email/calendar situation. Mail.app simultaneously just works and gets out of my way, and I haven't seen a Linux email client come close to replicating that.
Every few years I convince myself I'll create a better email client for Linux, and I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is. Maybe someday I'll take a sabatical and actually do it...
Come to think of it, it just dawned on me that most of the proprietary Mac programs I’ve used on Mac OS X/macOS (as opposed to the classic Mac OS) are either from Apple (Preview.app, Dictionary.app, iPhoto/Photos, iTunes/Apple Music, Keynote, iMovie, GarageBand), Microsoft (Office, Teams), or are Electron apps like Zoom and Slack. The only non-Microsoft, non-Electron third-party proprietary applications I’ve used on my Macs in the past 19 years are from the Omni Group, particularly OmniOutliner (which came bundled with my 2006 MacBook) and OmniGraffle.
It seems that what I miss the most about using a Mac whenever I’m on Windows or Linux is Apple’s bundled apps, not necessarily third-party Mac apps since I never used them much to begin with. Makes me think harder.
That’s what I was implying when I said the integration.
As far as indie apps, BBEdit will survive the heat death of the universe and has made it through every Apple transition since at least System 7 in 1992.
Funny enough, I’ve only had one Apple computer during each era - an Apple //e (65C02), a Mac LC II (68K), A PowerMac 6100/60 (classic Mac PPC), Mac Mini G4 (OS X PPC), a Core Dúo Mac Mini (x86) and now a MacBook M2 Air.
I was never really that interested in x86 Macs and I just bought cheso Windows PCs that I really didn’t use that much outside of work except web browsing and back in the day iTunes.
> Also, is there such a need for running macOS apps on a non-macOS?
Arguably there's a need for running macOS apps on macOS even. E.g. my parents are stuck having an old Intel Mac Pro around on an old OS for a few 32-bit programs (not sure if it changed, but IIRC you couldn't run an OS that supported them as a VM on Apple Silicon). Pretty soon Rosetta 2 will go away as well.
I have the same sentiment. I am forced to use a MacBook in my new job while waiting for them to procure a laptop that I can put Linux on. I can say that Linux with KDE Plasma desktop is in almost every way superior to Mac OS. Much better UX, configurability and core applications. And even little things are more polished and thought through compared to what a trillion dollar company was able to produce. It's really beyond me how people use Apple products, and it's the absolute majority of them in my field.
“Better” is largely subjective. For some (including myself), a Windows-like paradigm like KDE uses is not desirable, and UI papercuts like the many that KDE has are highly visible.
There are objective criteria that macOS definitely fails at. Various government agencies here in the states can't use macs even if they wanted to due to lack of #a11y support or the ability to load their own root cert stores.
I agree with you that for MOST people, MOST of the complaints boil down to "I just don't like the Mac UX," but there are organizations that cannot tolerate the risk of forcing employees to use equipment that doesn't follow even the basics of section 508 or DoD guidance.
Can’t comment on the others but I copy screenshots to the clipboard multiple times a day in macOS and have done for years. Very frequently I send them via Screen Sharing to another Mac and paste there, something I value hugely.
macOS has markup tools for screenshots (or any image) built right into Quicklook and Preview. It’s not as rich as something like SnagIt, but it’s good enough for adding some text, arrows, shapes, redactions, etc.
Dolphin is one of the things about KDE that bothers me, due to the way its windows are laid out and how they use margins/spacing. It just feels “wrong” in a way that even most other Linux file managers (including more full featured ones that still have a menubar) don’t.
Just curious... did your employer agree to getting you a Lennucks Bocks 'cause you asked nice or were they frightened of running afoul of one of the many #a11y or security evaluation frameworks?
I would much rather emulate linux apps on a more stable and consistent OS than vice versa. The sheer number of toolkits and window managers leaves my head spinning, and unifying their behavior even before you can begin to improve it feels like a nightmare.
I personally don't care much about the dock or the look and feel or whatever; I just want access to the usability of macos without having to accept how closed it is.
I'm not referring to the kernel at all. It's the morass of the userland—three decades of catering to the expectations of IBM PC/windows users have led to... inconsistent and underwhelming results. If I wanted to use 1980s UX, I would have switched to windows or linux decades ago.
But what am I saying? Consistent emacs bindings across all text forms is actually from the 1970s. Maybe I'm the problem....
Wouldn't it be more natural if this project made use of XNU/Darwin... But with the way things are going, with XNU going more and more proprietary, I suppose FreeBSD is "close enough". In any case, there's nothing we can do about it but these "macOS" alternatives are too fragmented. I would love to see "The" macOS clone.
This is so cool, the little mini screenshots look gorgeous because it replicates MacOS. I’m not sure if a lot of people feel the same but over the years I always thought it was a shame that Linux’ overall UX and aesthetics seemed a little bit more rushed and “crowd sourced” (in the sense that it felt diverse in terms of ui opinions and taste etc). It almost makes me want to try Linux again just for that look and feel (because I love my Mac’s but would like something different and more free)
From the mobile version I see a 10% other and 16.1% C++.
I think GH might have some issues because those two folders contain a lot of code (there is also C in between, but still), I don't know if I want to believe it's less than 2.6% Perl. [0]. "It's fixed".
Microsoft came close with Midori but bailed out and canned the product just before it should have been released in alfa / beta 1
> Midori is an experimental managed code operating system that was in development until 2015. A joint effort by Microsoft and Microsoft Research, it had been reported to be a possible commercial implementation of the OS Singularity, a research project begun in 2003 to build a highly dependable OS whose kernel, device drivers, and application software would all be written in managed code. It was designed for concurrency, and would run a program spread across multiple nodes at once.[1]
Because writing even a remotely modern OS is really really hard. I speak from experience. Even getting old hardware from the 90s and early 00s to work is a pain. Then of course you have the more modern standards (although even SATA is still modern for some definition of modern, but AHCI is a nightmare), and then you have things like modern NICs and GPUs which has documentation that is very hard to find, or in the case of even modern Intel GPUs, documentation that is 13 plus volumes and is absolutely massive... And the list just goes on and on and on. Before you know it your codebase is 100k LoC and like 80-90 percent of it is device drivers alone. And if you thought all that was bad, wait until you get into ACPI...
Yeah. OS dev is, I think it's safe to say, the hardest and most difficult project a software engineer could do, right alongside a modern compiler if you ditched LLVM and decided to make your own backend.
My dream is to work on an operating system that at least gets us to the 1990s and 2000s when it comes to research ideas.
I have a soft spot for the Smalltalk-80 environment and Lisp machines. They had a single address space. In my opinion, the two most interesting things about these environments are (1) their facilitation for component-based software based on live, dynamic objects, and (2) the malleability of the system, where every aspect of the system can be modified by the user in real time.
Of course, a critical downside of Smalltalk-80 and Lisp machine environments is the lack of security; any piece of code can modify the system. There are two solutions to this that I'm thinking about: (1) capability-based security for objects in the system, and (2) work on single-address space operating systems that still have memory protection (Opal was a research system that had this design; see Sharing and Protection in a Single-Address-Space Operating System [Chase et al. 1994]).
One of the nice things about Lisp is its metaprogramming facilities, from macros to the metaobject protocol. Metaprogramming makes it feasible to implement domain-specific languages that make expressing problems more aligned to their domains.
During the late 2000s and early 2010s, Alan Kay's Viewpoints Research Institute had a project named STEPS that investigated the pervasive use of DSLs to implement an entire desktop environment. They did not use Lisp as a substrate, but they did use OMeta (https://tinlizzie.org/ometa/) for handling parsing expression grammars (PEGs), which are used to describe many of the systems in STEPS. Two DSLs that immediately come to mind are one for describing the 2D graphics system and another for describing TCP.
So now I've described my dream substrate: a single-address operating system with capability-based security, where each subsystem is expressed as a live object, ideally coded in a DSL.
Now comes the interface. The programmer's interface would be similar to Smalltalk-80 and Lisp machines, with a live REPL for interactive coding. All objects can be accessed programmatically by sending messages to them. The end-user interface would be heavily based on the classic Mac OS, and applications would conform to human interface guidelines similar to System 7.5, but with some updates to reflect usage patterns and lessons in UI/UX that weren't known at the time. Application software would be similar to the OpenDoc vision, where components can be combined based on the user's wishes.
The end result sounds like a synthesis of various Apple projects from the late 1980s until 1996: component-based applications backed by a live object system with capability-based security.
This is my dream and is a side project I'd love to create.
My own high-level language, Varyx, has somewhat LISPy internals and is very dynamic — for example, you can annotate a variable with a type that's determined only at run time — and has an eval() that insulates the caller from the payload and vice versa. You can sequester mutable state within a closure, which can't be cracked open. Using an experimental Varyx build with some bindings for Apple's Core Graphics API, I wrote a script that rendered an arrow cursor (which I donated to the ravynOS project).
I would argue that iPadOS (built on iPhone's coat tails) moved the field forward significantly in terms of isolation and user security.
While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).
... and for those people Apple even makes lockdown mode to move the bar, while acknowledging it adds extra inconvenience: https://support.apple.com/en-au/105120
I have no such confidence about macOS, Linux or Windows, in fact the reverse. macOS has done the best at trying to bolt on some sandboxing (and linux has it too) but that's still very holey and not all-in like iOS/iPadOS has ended up.
Yes, I know there have been many bugs and leaks in iOS but the security level is far and above the desktops currently, and designed that way from the ground up. So when they finally make something work like copy and paste or sharing between apps, etc... it's by and large done very well.
It's been very difficult to add that kind of thing to Linux because you're trying to do the reverse and lock things down and it breaks everything... making it very challenging.. as opposed to Apple where basically nothing useful worked at the start (no copy/paste, one app at a time, no meaningful filesystem, etc).. but managed to get the product successful in the limited state and has slowly unlocked that stuff over time. Admittedly very slowly.
I cannot speak for Android as I just have never used it or surrounded myself in info about it's design, security, etc.. it may well be very similar although they from my casual observation seemed to do a much worse job at granular privacy permissions (e.g. for the longest time permissions were all granted at install time, and so many apps want so many most people are blind to it.. as opposed to Apple's model where even if notarised for something on the app store in most cases you have to agree to it when the app first uses it.. I know they fixed that a while back but I have no idea how well things have transitioned to that now). As a very techy person deeply knowledge in many things, and using desktop Linux since 2002, it's kindof a hilarious personal failing that I have never used Android.. I really should try and resolve that at some point.
> While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).
Log in to YouTube with one Google account. Log in to Google Drive with a different one.
Google knows that both accounts are owned by the same person, because Apple lets Google's apps access the data of the others on the same system.
It takes an astronomical amount of work to not only write an OS but handle 30 years worth of both hardware, and lessons learned.
People do write new OSes from scratch all the time, you can see the result of no popularity/usage because they can't do much for even enthusiasts.
Not to mention, if you want users, you need apps, and that involves trying to run what already exists or making it as easy as possible to port. All of that shapes the OS.
If you don't provide CoreFoo (for Foo in *), there's not really much point in talking about compatibility with macOS. I see no sign that they provide any of the possible CoreFoo libraries/frameworks.
It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
The website looks sleek, I get the impression that the ui for the os will be the same. But then when I look at the screenshots, it look like macOS stuck in 2008.
“Looks sleek” was only ever a surface level reason why macOS was a good UI. Far more important was that it was highly opinionated, and those opinions were very consistently applied, resulting in a highly predictable interface.
This has been degrading over the past decade, unfortunately.
Opinionated design is a big one, but another that's equally as big and even more unusual in the Linux world is progressive disclosure.
It basically amounts to adding lots of little power user features, but placing them ever so slightly out of the way so that newbies and less technical users don't get overwhelmed, but they're still within reach of those who can make use of them and reveal themselves as users grow and become more technically capable.
Linux desktops tend to take a much more binary approach: ultra-minimalist and stripped back so far that even iPadOS is more capable out of the box (GNOME) or everything and the kitchen sink on full display (KDE).
The RavynOS project would have a good chance at being binary compatible with Mac OSX if it copied all the Darwin libraries from the Darling project and used LLVM to generate all the appropriate dylibs. That's something I would support and contribute to. It could get to the point where it could run macOS console based applications.
But if macOS binary compatibility is not the goal, then there's no need for a Mach-O loader - it brings nothing to the table. Just use ELF binaries. Although at that point there's nothing macOS about it - it's just a Mac-like UI facade for FreeBSD distro with a different API. If Ravyn doesn't want to be to macOS like WINE is to Windows, I don't see the point.
Frankly I was a bit surprised that was not what they were doing. As a user I’d prefer a “mere” macOS UI on top of FreeBSD, so long as its quality is of the same. Use Darling as a compatibility loader, like WINE/Proton in SteamOS.
In future, your OS will be an agentic LLM which runs software by YOLOing the binaries, and then continuously fixing and refining the environment until it runs without crashing.
Can it run stock macOS programs like Photos? I want a non-chaotic way to import my old fart's iPhone galleries without a Mac Mini (HEIC and Lives are annoying), and docker-osx/vm's don't work for everyone.
Apple releases part of the source code of XNU, it would make much more sense to me, to re-create something like the original Darwin CD out of this for x86-64.
There are a number of MacOS CLI tools and drivers for x86_64.
It may be a motivation to continue work.
Even commercially it could be something interesting.
Wine works because Microsoft spends billions on backwards compatibility and APIs are stable over time.
Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.
If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.
I've been paying attention to this project periodically over the past few years. It would be nice to have a FOSS clone of macOS, similar to how FreeDOS, ReactOS, and Haiku are FOSS clones of MS-DOS, Windows, and BeOS, respectively.
The only thing is that this project has been quite slow going, which is similar to the histories of FreeDOS, ReactOS, and Haiku, where it took a long time for those projects to get to a usable state. It is a lot of work cloning an operating system, especially with an aim for binary compatibility. The Linux kernel benefited from the fact that there was an entire GNU ecosystem of tools that can run on Unix, and even in that case, the GNU ecosystem was seven years in the making in 1991 when the first version of the Linux kernel was released. It would've taken much longer for Linux to have been developed had GNU tools not existed.
Writing an entire operating system is long, hard work, even when provided the resources of companies like Microsoft, Apple, and Google. Hopefully projects like ravynOS and the similar HelloSystem (https://hellosystem.github.io/docs/) will lead to FOSS clones of macOS eventually, even if we need to wait another 5-10 years.
Sometimes it strikes me that something like this might be one of the better litmus tests for AI — if it’s really good enough to start 10x-ing engineers (let alone replacing them) it should be more common for more projects like this should begin to accelerate to practical usability.
If not, maybe the productivity dividends are mostly shallow.
There's also a cost problem here.
Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
On large code-bases like this, where a lot of context gets pulled in, agents start to cost a lot very quickly, and open source projects like this are usually quite short on money.
The problem is that many of these clean room reimplementations require contributors to not have seen any of the proprietary source. You can't guarantee that with ai because who knows which training data was used
Are those OSes actually that strict about contributors? That’s got to be impossible to verify and I’ve only seen clean room stuff when a competitor is straight up copying another competitor and doesn’t want to get sued
ReactOS froze development to audit their code.[1] Circumstantial evidence was enough to call code not clean. WINE are strict as well. It is impossible to verify beyond all doubt of course.
[1] https://reactos.org/wiki/Audit
I had never thought of this until now. Is the clean-room approach officially done with? I guess we have to wait for a case to be ruled on.
The organisational bottleneck still remains though. People need to discuss and coordinate at human speed.
I think AI will likely create more fragmentation initially, if a 10x developer is forced to run at 0.1x they're going to fork a project.
I believe in the AI 10x developer, but I suspect it only works for individuals or small teams at the moment.
In an actual business environment, you are right that its not a 10x gain, more like 1.5-2x. Most of my job as an engineer is gathering and understanding requirements, testing, managing expectations, making sure everyone is on the same page etc...it seems only 10-20% is writing actual code. If I do get AI to write some code, I still need to do all of these other things.
I have used it for my solo startups much more effectively, no humans to get in the way. I've used AI to replace things like designers and the like that I didn't have to hire (nor did I have the funds for that).
I can build mini AI agents with my engineering skills for simple non-engineering tasks that might otherwise need a human specialist.
This was my thought here as well. Getting one piece of software to match another piece of software is something that agentic AI tools are really good at. Like, the one area where they are truly better than humans.
I expect that with the right testing framework setup and accessible to Claude Code or Codex, you could iterate your way to full system compatibility in a mostly automated way.
If anyone on the team is interested in doing this, I’d love to speak to them.
Sure. In the meantime productivity is still useful.
> A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience.
I am curious - what is the motivation for this project?
Is it to replicate macOS? - If yes, why?
Is it to provide application compatibility on a non-macOS? If yes, why a full OS? Why not take the route like Wine or other such layers that make compatibility possible? Also, is there such a need for running macOS apps on a non-macOS? Who is the target audience?
Would the energy be better spent in making Linux more stable or usable for the general public?
If its just a hobby, sure, that is well & good.
A lot of these questions are answered here: https://ravynos.com/faq
To summarize...
There is a WINE-analogous project, called Darling: https://www.darlinghq.org/
The goal for ravynOS is to be analogous to ReactOS. Much like ReactOS and WINE, ravynOS and Darling share a lot of Cocoa code.
For the problem of OpenStep implementations specifically, a bespoke software stack has the benefit of being able to put Mach messaging into the kernel, where it is much more performant.
They chose the FreeBSD kernel over Darwin for the sake of hardware compatibility (though of course NeXT Mach is one of the most widely-ported kernels of all time...)
There is also overlap with GNUstep, helloSystem, and other projects in the broader "open-source Mac/NeXT" space, though ravynOS (obviously) prefers BSD/MIT/Apache-style licensing over GNU-style licensing. Nevertheless, ravynOS currently uses the GNUstep libobjc2 runtime, a bit like how most of the Unix world used to depend on gcc.
> There is a WINE-analogous project, called Darling: https://www.darlinghq.org/
Missed opportunity to call it Cider.
There's already been a Cider; it used some Wine code to ease porting games to MacOS.
> of course NeXT Mach is one of the most widely-ported kernels of all time...
actually the broader Mach kernel, not specifically the NeXT variant, is the one with a documented history of extensive portability
The NeXT variant did run on the following architectures:
1. Motorola 68k (the original NeXT hardware had 68030 and 68040 chips)
2. Intel x86 (NeXTSTEP 3.1 for Intel was released in 1993)
3. HP PA-RISC (I have an OPENSTEP 4.2 CD that can run on Motorola 68k, x86, PA-RISC, and SPARC hardware)
4. Sun SPARC
5. 32-bit PowerPC (Rhapsody, the original Mac OS X 1.0 that was essentially still Rhapsody, and of course Mac OS X from Cheetah through Leopard)
6. 64-bit PowerPC (Power Mac G5 and iMac G5)
7. Intel x86-64 (starting from Mac OS X Tiger all the way to macOS Tahoe)
8. 32-bit ARM (iOS on early iPhones with 32-bit ARM chips)
9. 64-bit ARM
I could be forgetting other platforms, but these are the ones I know from the top of my head.
I'm not affiliated with ravynOS, but I've been periodically following the project for a few years.
The main page (https://ravynos.com/) expresses the philosophy of ravynOS:
"We love macOS, but we’re not a fan of the ever-closing hardware and ecosystem. So, we are creating ravynOS — an OS aimed to provide the finesse of macOS with the freedom of FreeBSD."
rayvnOS seems to be designed for people who love macOS, particularly its interface, its UI guidelines, and its ecosystem of applications, but who do not like the direction that Apple has moved toward under Tim Cook (soldered RAM, limited and inflexible hardware choices, notarization, iOS-influenced interface changes, increased pushiness with advertising Apple's subscription services, etc.) and who would be unhappy with either Windows or the Linux desktop.
Speaking for myself, I used to daily-drive Macs from 2006 through 2021, but I now daily-drive PCs running Windows due primarily to the lack of upgradable RAM in ARM Macs. I'm not a big fan of Windows, but I need some proprietary software packages such as Microsoft Office. This makes switching to desktop Linux difficult.
It would be awesome using what is essentially a community-driven clone of macOS, where I could continue using a Mac-like operating system without needing to worry about Apple's future directions.
On the Unix side of things, I believe the decision to base ravynOS on FreeBSD rather than on Linux may make migrating from macOS to ravynOS easier, since macOS is based on a hybrid Mach/BSD kernel, and since many of the command-line tools that ship with macOS are from the BSDs. This is known as Darwin. It's not that a Mac clone can't be built on top of Linux, but FreeBSD is closer to Darwin than Linux is.
This description really resonates with me, so I guess I’m a potential user.
I’ve been running macOS most of my life. In college I ran Linux on my laptops, but I switched back to macOS as the user experience was better - I could spend far less time messing with things and instead rely on system defaults and first party apps.
Year by year though I feel more like I don’t own my computer. I’ve tried switching back to Linux, but I always give up because despite the freedom, it starts feeling like a chore. Even Asahi Linux on macOS hardware I couldn’t get into.
The rayvnOS vision is something I could get behind. A fully packaged, macOS-like user experience, where the default settings are good and things work out of the box. I’d LOVE to have that as on option.
Linux compatibility or even macOS binary compatibility matters less to me than, say, an out of the box Time Machine like backup tool based on ZFS snapshots. So FreeBSD makes sense from that perspective.
So somehow running MacOS in 2025 on hot, loud, horrible battery life x86 based computers is a good thing?
Not to mention x86 Mac apps are not long for this world. I can’t think of a single application I would miss moving from Macs to Windows. It’s more about the hardware and the integration with the rest of my Apple devices.
Notes and Reminders are extremely good at what they do, and the synchronization with their iOS equivalents is flawless from what I can tell… and fat chance you get to uproot such a thing to a non-Apple OS.
Third party apps other than for media editing seem to be rare, I think Apple has gobbled or rug pulled much of its independent software vendor ecosystem.
Apple Mail also is in my eyes the only generic mail client out there that really “gets it”.
Thunderbird has always felt clunky in comparison and the recent redesign just made it a different kind of clunky. Everything else is either too minimal (Geary), tries to clone old style Outlook (Evolution), or is tied to/favors a particular provider (Gmail, Outlook, etc).
This. I use Linux as my primary OS (with KDE) and my main complaint, by far, is the email/calendar situation. Mail.app simultaneously just works and gets out of my way, and I haven't seen a Linux email client come close to replicating that.
Every few years I convince myself I'll create a better email client for Linux, and I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is. Maybe someday I'll take a sabatical and actually do it...
> I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is.
What are some of the things you’re thinking of?
Come to think of it, it just dawned on me that most of the proprietary Mac programs I’ve used on Mac OS X/macOS (as opposed to the classic Mac OS) are either from Apple (Preview.app, Dictionary.app, iPhoto/Photos, iTunes/Apple Music, Keynote, iMovie, GarageBand), Microsoft (Office, Teams), or are Electron apps like Zoom and Slack. The only non-Microsoft, non-Electron third-party proprietary applications I’ve used on my Macs in the past 19 years are from the Omni Group, particularly OmniOutliner (which came bundled with my 2006 MacBook) and OmniGraffle.
It seems that what I miss the most about using a Mac whenever I’m on Windows or Linux is Apple’s bundled apps, not necessarily third-party Mac apps since I never used them much to begin with. Makes me think harder.
That’s what I was implying when I said the integration.
As far as indie apps, BBEdit will survive the heat death of the universe and has made it through every Apple transition since at least System 7 in 1992.
Funny enough, I’ve only had one Apple computer during each era - an Apple //e (65C02), a Mac LC II (68K), A PowerMac 6100/60 (classic Mac PPC), Mac Mini G4 (OS X PPC), a Core Dúo Mac Mini (x86) and now a MacBook M2 Air.
I was never really that interested in x86 Macs and I just bought cheso Windows PCs that I really didn’t use that much outside of work except web browsing and back in the day iTunes.
> Also, is there such a need for running macOS apps on a non-macOS?
Arguably there's a need for running macOS apps on macOS even. E.g. my parents are stuck having an old Intel Mac Pro around on an old OS for a few 32-bit programs (not sure if it changed, but IIRC you couldn't run an OS that supported them as a VM on Apple Silicon). Pretty soon Rosetta 2 will go away as well.
It would be great if it runs on mac too. macOS doesn't have much compatibility with itself.
I have the same sentiment. I am forced to use a MacBook in my new job while waiting for them to procure a laptop that I can put Linux on. I can say that Linux with KDE Plasma desktop is in almost every way superior to Mac OS. Much better UX, configurability and core applications. And even little things are more polished and thought through compared to what a trillion dollar company was able to produce. It's really beyond me how people use Apple products, and it's the absolute majority of them in my field.
“Better” is largely subjective. For some (including myself), a Windows-like paradigm like KDE uses is not desirable, and UI papercuts like the many that KDE has are highly visible.
I use KDE because it lets me emulate a macOS-like paradigm better than Gnome or other options can.
There are objective criteria that macOS definitely fails at. Various government agencies here in the states can't use macs even if they wanted to due to lack of #a11y support or the ability to load their own root cert stores.
I agree with you that for MOST people, MOST of the complaints boil down to "I just don't like the Mac UX," but there are organizations that cannot tolerate the risk of forcing employees to use equipment that doesn't follow even the basics of section 508 or DoD guidance.
What accessibility is it missing?
You can import new roots via Keychain, correct?
Yes.
I don't keep the record of every thing that I don't like about MacOS, but here's some:
- cannot keep natural scrolling for trackpad whilst having the expected scrolling behaviour for the mouse
- needs an external app for fractional display scaling
- screenshot tool is objectively inferior to that in Plasma, eg. not clear how to annotate a screenshot or copy it to clipboard
- Dolphin file browser is has cleaner and simpler UI, is more configurable and has a built-in terminal which is super handy.
...
Can’t comment on the others but I copy screenshots to the clipboard multiple times a day in macOS and have done for years. Very frequently I send them via Screen Sharing to another Mac and paste there, something I value hugely.
macOS has markup tools for screenshots (or any image) built right into Quicklook and Preview. It’s not as rich as something like SnagIt, but it’s good enough for adding some text, arrows, shapes, redactions, etc.
Dolphin is one of the things about KDE that bothers me, due to the way its windows are laid out and how they use margins/spacing. It just feels “wrong” in a way that even most other Linux file managers (including more full featured ones that still have a menubar) don’t.
Except for the trackpad, alas.
Just curious... did your employer agree to getting you a Lennucks Bocks 'cause you asked nice or were they frightened of running afoul of one of the many #a11y or security evaluation frameworks?
I would much rather emulate linux apps on a more stable and consistent OS than vice versa. The sheer number of toolkits and window managers leaves my head spinning, and unifying their behavior even before you can begin to improve it feels like a nightmare.
I personally don't care much about the dock or the look and feel or whatever; I just want access to the usability of macos without having to accept how closed it is.
It's hard to get a more consistent and stable kernel than Linux, not counting academic or experimental kernels w/o extensive hardware support.
I'm not referring to the kernel at all. It's the morass of the userland—three decades of catering to the expectations of IBM PC/windows users have led to... inconsistent and underwhelming results. If I wanted to use 1980s UX, I would have switched to windows or linux decades ago.
But what am I saying? Consistent emacs bindings across all text forms is actually from the 1970s. Maybe I'm the problem....
If it is no longer closed, it might proliferate just like Linux once it gathers a critical amount of users. :)
Mac OS without the background ads garbage or the constant blocking of call-home requests would be nice.
Where are you seeing ads?
what are you smoking ?
> Would the energy be better spent in making Linux more stable or usable for the general public?
Linux is stable and widely used, whether as Android, Ubuntu, WSL on Windows or Crostini on ChromeOS (itself Linux under the hood).
The general public buy products like Macs, Lenovos, Steam Decks, Chromebooks or Frameworks. Nobody buys a "Linux".
Linux and it's ecosystem are features of those products, not products themselves.
This is all nice and well, while https://www.puredarwin.org/wiki/#/news/Support-Cliff-Sekel
Wouldn't it be more natural if this project made use of XNU/Darwin... But with the way things are going, with XNU going more and more proprietary, I suppose FreeBSD is "close enough". In any case, there's nothing we can do about it but these "macOS" alternatives are too fragmented. I would love to see "The" macOS clone.
I think the idea is take what you can and evolve.
Keeping it x86_64 for now makes sense in many respects.
But it could become a real uKernel OS in the long run.
This is so cool, the little mini screenshots look gorgeous because it replicates MacOS. I’m not sure if a lot of people feel the same but over the years I always thought it was a shame that Linux’ overall UX and aesthetics seemed a little bit more rushed and “crowd sourced” (in the sense that it felt diverse in terms of ui opinions and taste etc). It almost makes me want to try Linux again just for that look and feel (because I love my Mac’s but would like something different and more free)
Repo has zero Objective-C or C++ (IO, DriverKit, MSL), hardly anything relevant if the goal is macOS compatibility.
This considering the last macOS version before Swift was announced as goal.
I think it's in the frameworks folder, e.g., https://github.com/ravynsoft/ravynos/tree/main/Frameworks/Ap...
Edit: also CoreServices https://github.com/ravynsoft/ravynos/tree/main/CoreServices/...
Well, there is actually a lot of ObjC.
I stand corrected, you will notice that it isn't visible on the languages colour bar, nor C++.
From the mobile version I see a 10% other and 16.1% C++.
I think GH might have some issues because those two folders contain a lot of code (there is also C in between, but still), I don't know if I want to believe it's less than 2.6% Perl. [0]. "It's fixed".
[0]: https://github.com/github-linguist/linguist/issues/1626
Why is every new OS project just a rehash of 60/70's tech. What about something new that actually attempts to move the field forward.
Microsoft came close with Midori but bailed out and canned the product just before it should have been released in alfa / beta 1
> Midori is an experimental managed code operating system that was in development until 2015. A joint effort by Microsoft and Microsoft Research, it had been reported to be a possible commercial implementation of the OS Singularity, a research project begun in 2003 to build a highly dependable OS whose kernel, device drivers, and application software would all be written in managed code. It was designed for concurrency, and would run a program spread across multiple nodes at once.[1]
[1] https://en.wikipedia.org/wiki/Midori_(operating_system)
https://joeduffyblog.com/2015/11/03/blogging-about-midori/
Because writing even a remotely modern OS is really really hard. I speak from experience. Even getting old hardware from the 90s and early 00s to work is a pain. Then of course you have the more modern standards (although even SATA is still modern for some definition of modern, but AHCI is a nightmare), and then you have things like modern NICs and GPUs which has documentation that is very hard to find, or in the case of even modern Intel GPUs, documentation that is 13 plus volumes and is absolutely massive... And the list just goes on and on and on. Before you know it your codebase is 100k LoC and like 80-90 percent of it is device drivers alone. And if you thought all that was bad, wait until you get into ACPI...
Yeah. OS dev is, I think it's safe to say, the hardest and most difficult project a software engineer could do, right alongside a modern compiler if you ditched LLVM and decided to make your own backend.
Even Apple got to a point where they needed to acquire another company because they hit a brick wall with MacOS.
My dream is to work on an operating system that at least gets us to the 1990s and 2000s when it comes to research ideas.
I have a soft spot for the Smalltalk-80 environment and Lisp machines. They had a single address space. In my opinion, the two most interesting things about these environments are (1) their facilitation for component-based software based on live, dynamic objects, and (2) the malleability of the system, where every aspect of the system can be modified by the user in real time.
Of course, a critical downside of Smalltalk-80 and Lisp machine environments is the lack of security; any piece of code can modify the system. There are two solutions to this that I'm thinking about: (1) capability-based security for objects in the system, and (2) work on single-address space operating systems that still have memory protection (Opal was a research system that had this design; see Sharing and Protection in a Single-Address-Space Operating System [Chase et al. 1994]).
One of the nice things about Lisp is its metaprogramming facilities, from macros to the metaobject protocol. Metaprogramming makes it feasible to implement domain-specific languages that make expressing problems more aligned to their domains.
During the late 2000s and early 2010s, Alan Kay's Viewpoints Research Institute had a project named STEPS that investigated the pervasive use of DSLs to implement an entire desktop environment. They did not use Lisp as a substrate, but they did use OMeta (https://tinlizzie.org/ometa/) for handling parsing expression grammars (PEGs), which are used to describe many of the systems in STEPS. Two DSLs that immediately come to mind are one for describing the 2D graphics system and another for describing TCP.
So now I've described my dream substrate: a single-address operating system with capability-based security, where each subsystem is expressed as a live object, ideally coded in a DSL.
Now comes the interface. The programmer's interface would be similar to Smalltalk-80 and Lisp machines, with a live REPL for interactive coding. All objects can be accessed programmatically by sending messages to them. The end-user interface would be heavily based on the classic Mac OS, and applications would conform to human interface guidelines similar to System 7.5, but with some updates to reflect usage patterns and lessons in UI/UX that weren't known at the time. Application software would be similar to the OpenDoc vision, where components can be combined based on the user's wishes.
The end result sounds like a synthesis of various Apple projects from the late 1980s until 1996: component-based applications backed by a live object system with capability-based security.
This is my dream and is a side project I'd love to create.
If you're okay with a System 6 appearance, I've already made one <https://github.com/jjuran/metamage_1/tree/master/68k/modules...>, for Advanced Mac Substitute <https://www.v68k.org/ams/>.
I do appreciate Alan Kay's thinking, in particular his talk "Normal Considered Harmful" <https://www.youtube.com/watch?v=FvmTSpJU-Xc>
My own high-level language, Varyx, has somewhat LISPy internals and is very dynamic — for example, you can annotate a variable with a type that's determined only at run time — and has an eval() that insulates the caller from the payload and vice versa. You can sequester mutable state within a closure, which can't be cracked open. Using an experimental Varyx build with some bindings for Apple's Core Graphics API, I wrote a script that rendered an arrow cursor (which I donated to the ravynOS project).
Perhaps we should talk. :-)
How about the immutable OSes like Fedora Silverblue
I would argue that iPadOS (built on iPhone's coat tails) moved the field forward significantly in terms of isolation and user security.
While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).
... and for those people Apple even makes lockdown mode to move the bar, while acknowledging it adds extra inconvenience: https://support.apple.com/en-au/105120
I have no such confidence about macOS, Linux or Windows, in fact the reverse. macOS has done the best at trying to bolt on some sandboxing (and linux has it too) but that's still very holey and not all-in like iOS/iPadOS has ended up.
Yes, I know there have been many bugs and leaks in iOS but the security level is far and above the desktops currently, and designed that way from the ground up. So when they finally make something work like copy and paste or sharing between apps, etc... it's by and large done very well.
It's been very difficult to add that kind of thing to Linux because you're trying to do the reverse and lock things down and it breaks everything... making it very challenging.. as opposed to Apple where basically nothing useful worked at the start (no copy/paste, one app at a time, no meaningful filesystem, etc).. but managed to get the product successful in the limited state and has slowly unlocked that stuff over time. Admittedly very slowly.
I cannot speak for Android as I just have never used it or surrounded myself in info about it's design, security, etc.. it may well be very similar although they from my casual observation seemed to do a much worse job at granular privacy permissions (e.g. for the longest time permissions were all granted at install time, and so many apps want so many most people are blind to it.. as opposed to Apple's model where even if notarised for something on the app store in most cases you have to agree to it when the app first uses it.. I know they fixed that a while back but I have no idea how well things have transitioned to that now). As a very techy person deeply knowledge in many things, and using desktop Linux since 2002, it's kindof a hilarious personal failing that I have never used Android.. I really should try and resolve that at some point.
> While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).
Log in to YouTube with one Google account. Log in to Google Drive with a different one.
Google knows that both accounts are owned by the same person, because Apple lets Google's apps access the data of the others on the same system.
It takes an astronomical amount of work to not only write an OS but handle 30 years worth of both hardware, and lessons learned.
People do write new OSes from scratch all the time, you can see the result of no popularity/usage because they can't do much for even enthusiasts.
Not to mention, if you want users, you need apps, and that involves trying to run what already exists or making it as easy as possible to port. All of that shapes the OS.
If you don't provide CoreFoo (for Foo in *), there's not really much point in talking about compatibility with macOS. I see no sign that they provide any of the possible CoreFoo libraries/frameworks.
It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
The website looks sleek, I get the impression that the ui for the os will be the same. But then when I look at the screenshots, it look like macOS stuck in 2008.
The Mac UI only got worse after that.
Nah. Mavericks was peak.
Who cares about sleekness? Linux has looked sleek for decades but still behaves like ass
“Looks sleek” was only ever a surface level reason why macOS was a good UI. Far more important was that it was highly opinionated, and those opinions were very consistently applied, resulting in a highly predictable interface.
This has been degrading over the past decade, unfortunately.
Opinionated design is a big one, but another that's equally as big and even more unusual in the Linux world is progressive disclosure.
It basically amounts to adding lots of little power user features, but placing them ever so slightly out of the way so that newbies and less technical users don't get overwhelmed, but they're still within reach of those who can make use of them and reveal themselves as users grow and become more technically capable.
Linux desktops tend to take a much more binary approach: ultra-minimalist and stripped back so far that even iPadOS is more capable out of the box (GNOME) or everything and the kitchen sink on full display (KDE).
The RavynOS project would have a good chance at being binary compatible with Mac OSX if it copied all the Darwin libraries from the Darling project and used LLVM to generate all the appropriate dylibs. That's something I would support and contribute to. It could get to the point where it could run macOS console based applications.
But if macOS binary compatibility is not the goal, then there's no need for a Mach-O loader - it brings nothing to the table. Just use ELF binaries. Although at that point there's nothing macOS about it - it's just a Mac-like UI facade for FreeBSD distro with a different API. If Ravyn doesn't want to be to macOS like WINE is to Windows, I don't see the point.
Frankly I was a bit surprised that was not what they were doing. As a user I’d prefer a “mere” macOS UI on top of FreeBSD, so long as its quality is of the same. Use Darling as a compatibility loader, like WINE/Proton in SteamOS.
> copied all the Darwin libraries from the Darling project and used LLVM to generate all the appropriate dylibs
I'm just starting for the day and misread that as "...used LLM to generate...", and I wondered what kind of crack you were smoking.
In future, your OS will be an agentic LLM which runs software by YOLOing the binaries, and then continuously fixing and refining the environment until it runs without crashing.
This has been a slow going effort for a few years now, it's not "new".
https://ravynos.com/screenshots.html
Can it run stock macOS programs like Photos? I want a non-chaotic way to import my old fart's iPhone galleries without a Mac Mini (HEIC and Lives are annoying), and docker-osx/vm's don't work for everyone.
They say source-compatible, not binary-compatible.
GNUstep failed to get traction, I doubt they can do much better.
It's a totally different path but you could try Immich to do that.
Apple releases part of the source code of XNU, it would make much more sense to me, to re-create something like the original Darwin CD out of this for x86-64.
There are a number of MacOS CLI tools and drivers for x86_64.
It may be a motivation to continue work.
Even commercially it could be something interesting.
I am not sure if it is easier though.
PureDarwin seems to do very slow progress.
i’d do anything for an open source mac os clone i can run on my arm macbook pro. i’m sick of apple.