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.
New Microsoft under Satya has a different stance on anything WinRT related, or even newer Win32/COM APIs since Windows 8.
Also .NET Framework is the Python 2 of .NET, the breaking changes are a reason there are still new projects being done in .NET Framework 4.8.x.
Trying to be binary-compatible with Tahoe may not be worth it. But you could make a distro binary-compatible with Snow Leopard.
Or better, make it compatible with Ventura apps without the bloat of MacOS Ventura.
That could give new life to old Macs. It can also give a PC a MacOS-like environment without having to deal with Hackintosh.
Generally their “availability” macros in swift and objc keep things working across versions in a forward compatible way.
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.
If not, maybe the productivity dividends are mostly shallow.
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.
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.
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.
In an AI driven OS, there will be less need for bare bones "classical" programming, other than the AI infrastructure.
Now is this possible today, not really as the misteps from Google, Apple and Microsoft are showing, however eventually we might be there with a different programming paradigm.
Having LLMs generate code is a transition step, just like we run to Compiler Explorer to validate how good the compiler optimizer happens to be.
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.
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.
Missed opportunity to call it Cider.
actually the broader Mach kernel, not specifically the NeXT variant, is the one with a documented history of extensive portability
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.
Hold on a minute.
It's not "soldered". It's integrated with the SoC. The benefit is memory latency and bandwidth.
If you know Framework, their entire mission is to build upgradeable laptops, and they keep delivering. Now they also wanted to build an incredibly powerful, but small and quiet desktop. They went directly to AMD, asked their engineers to make the memory upgradeable. AMD worked really hard and said not possible, not unless you want all of these cores to sit idle.
https://frame.work/blog/framework-desktop-deep-dive-ryzen-ai...
The world has moved on. Just as you no longer have discrete cache chips or discrete FPUs, you can't do discrete memory anymore - unless you don't need that level of performance, in which case CAMM is still an excellent choice.
But that's not what Apple does. M1 redefined the low-end. It will remain a great choice in 5 years, even when macOS kills it off - Asahi remains very decent.
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.
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.
It's a shame that OpenDarwin didn't continue. PureDarwin seems to exist, but progress is understandably slow.
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.
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.
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 have the opposite reaction. To me the screenshots look like someone tried to replicate macOS but failed. The text antialiasing is off, the font is different (and worse), the border-radii on menus are off, etc.
Besides, the actual screenshots of the current OS (https://ravynos.com/screenshots) are... really rough.
[0]or retro, for anyone who's offended by me calling it dated.
> 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]
> While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia.
From https://www.microsoft.com/en-us/research/project/singularity...
Enjoy this recording of an internal presentation, while it is still available on YouTube,
https://www.youtube.com/watch?v=37WgsoZpf3k
Joe Duffy also did a few presentations, on one of them (too lazy to search for the exact moment), he mentions that even with Midori running in front of them, the Windows team was very sceptical of it,
"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy"
https://www.youtube.com/watch?v=CuD7SCqHB7k
"Safe Systems Programming in C# and .NET"
https://www.infoq.com/presentations/csharp-systems-programmi...
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.
Note that Smalltalk, Interlisp-D, Mesa, Cedar, safe systems programming are also 60/70's tech, but these ones hardly anyone bothers to copy in such attempts.
> but these ones hardly anyone bothers to copy in such attempts.
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.
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.
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. :-)
Also why despite not agreeing how Google went down with Java in Android, I appreciate their approach, because this kind of platforms apparently only get adoption with such kind of hard pushes, otherwise it would be yet another tiny UNIX clone.
Ironically is probably the closest we have on the market from Inferno/Limbo ideas on a mainstream OS.
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.
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.
Also your narrative about iOS moving from locked down to opening things up over time isn't entirely accurate, when iOS (iPhoneOS) was first released, it didn't have any concept of permissions at all! Apps could use whatever API the OS offered with the user none the wiser. At that time Android Market forcing developers to disclose which permissions were required was seen as unusually transparent and secure. Random iPhone apps scanning contacts deceptively pushed Apple to adopt a permissions model several years after the iPhone was first released.
The two platforms have historically leap frogged each other in various ways but at this point have started to converge as mobile settled into a boring appliance instead of groundbreaking new computing paradigm. Apart from sideloading, notifications and some minor annoyances here and there I can almost forget which OS I'm using as I switch between iOS and Android (thanks to gestures removing the trademark home/back navigation distinctions).
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.
This has been degrading over the past decade, unfortunately.
huh?
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.
ravynOS is moving to Darwin.
Keeping it x86_64 for now makes sense in many respects.
But it could become a real uKernel OS in the long run.
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.
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.
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.
What would be required to achieve this?
I guess one thing macOS users like is the default UI. So this is probably an area where Linux lacks - both GNOME and KDE have shortcomings when compared to that UI. (They are mostly fine if one does not have that as a use case, though I find GNOME to really want to simplify everything to the point of having almost no features left.)
Also no one bothers making the beautiful native apps now, everything is electron, which is equally inconsistent everywhere.
So I think the advantage over time Vs a Linux system is diminishing... Slowly.
One persons shortcomings is another persons normal work flow. To me this is simply a matter of adjusting to a different environment.
I went form Windows 7 to Linux and the key part was that I always use open source software where possible such as FreeCAD, KiCAD, Libre Office, Firefox, Krita, Gimp, etc. This makes transitioning very painless. I also dont customize, no dotfiles, media managers, themes, prompts, shells, or reliance on OS features, etc. I keep it primitive.
This considering the last macOS version before Swift was announced as goal.
Edit: also CoreServices https://github.com/ravynsoft/ravynos/tree/main/CoreServices/...
Well, there is actually a lot of ObjC.
GNUstep failed to get traction, I doubt they can do much better.