You realize that Mac OS X 10.4 Tiger is now twenty years old, this was the first version of Mac OS X to support Intel processors, all of the patents for it have now expired. With quantum supremacy being maybe two years out to crack all the old security keys, what is to stop us Intel Mac users from just rolling our own MalusOS distribution based on Darwin and a clean room reverse engineered implementation of Aqua that can keep running Intel Mac Apps? Given SIP and all the other security improvements to MacOS Tahoe it's probably going to be around for at least another twenty years just like Windows XP regardless of Apple disowning it. There is already ReactOS, WINE, and Proton for Windows. Code is a dirt cheap commodity with AI now, so even without Apple's support and blessings we could keep Intel Tahoe doing for another 20 years easily.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
All of the patents for Mac OS X 10.4 Tiger Intel have expired.
- Thread starter nbritton
- Start date
- Sort by reaction score
DankeBrutus
macrumors regular
> ...what is to stop us Intel Mac users from just rolling our own MalusOS distribution based on Darwin and a clean room reverse engineered implementation of Aqua that can keep running Intel Mac Apps?
A whole lot of work.
Maybe there will be a small but dedicated group of developers trying to reverse engineer OSX, like ReactOS, but there is no guarantee of this.
A whole lot of work.
Maybe there will be a small but dedicated group of developers trying to reverse engineer OSX, like ReactOS, but there is no guarantee of this.
maflynn
macrumors Broadwell
Why?
What do you gain, and in all honesty, the number of intel mac users must be incredibly small. Doesn't seem like a good use of time, energy and effort - what will the benefit?
Apple produced upwards of 250 million Intel based Macs, and to this day over 30% of Safari HTTP web requests still come from Mac OS X 10.x releases that predate macOS. The legacy Mac OS X market share is larger than the entire Linux desktop movement combined.
Honestly I don't care much about Darwin (the underlying Unix-like operating system of macOS), but porting Apple's proprietary Aqua GUI along with full Intel Mac application ABI compatibility to the FreeBSD operating system would be a very worthwhile endeavor.
Last edited:
Some of those are probably faked User-Agent strings. People can have many reasons for doing that, such as keeping old server-side software working.
The recent kerfuffle about low iOS 26 adoption rates was due to the stats-tracking website not accounting for Apple's change to User-Agent strings.
iOS 26 Shows Unusually Slow Adoption Months After Release [Updated]
Update: As noted by Nick Heer on his Pixel Envy blog, analytics data is unreliable because Safari on iOS 26 is reporting a different operating system version in the user agent string that analytics services rely on for data. For example, devices on several versions of iOS 26 are reporting...
forums.macrumors.com
maflynn
macrumors Broadwell
Why?
I'm not purposely being obtuse but I'm failing to see the advanages of trying to port a 20 year old operating system, so it can run on intel macs. Wouldn't that represent significant risks with regards to vulnerabilities? What advantages would you have over keeping macos on your intel mac instead of trying to create a cloned copy of a 20 year old operating system?
I never said port a 20 year old operating system, that is not how patents work, once a US patent is formally issued the company has exclusive rights to use that technology for 20 years, after that time anyone can use it (the technologies and concepts) without licensing it. This applies to all prior patents that even the newest macOS Tahoe release is built upon, which is basically everything, there is really nothing new in Tahoe that wasn't already in place twenty years ago; it's basically all just window dressing. What I said was port Aqua, Quartz Compositor, and Cocoa. Moreover, design patents only last 15 years, so that actually puts Mac OS X 10.7 Lion within the crosshairs for "look and feel", not Tiger.
Last edited:
Patents are one thing; copyright is another. Tiger remains Apple's legally protected IP.
bogdanw
macrumors G3
1. Apple Open Source https://opensource.apple.com/releases/
2. Until Catalina, statistics are largely accurate.
"Apple are incorrectly reporting all macOS releases since Catalina 10.15 as Catalina 10.15. You can read more about it here.
We can't correctly show usage for Catalina 10.15, Big Sur 11, Monterey 12, Ventura 13 or Sonoma 14 until Apple fixes this."
https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide
2. Until Catalina, statistics are largely accurate.
"Apple are incorrectly reporting all macOS releases since Catalina 10.15 as Catalina 10.15. You can read more about it here.
We can't correctly show usage for Catalina 10.15, Big Sur 11, Monterey 12, Ventura 13 or Sonoma 14 until Apple fixes this."
https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide
maflynn
macrumors Broadwell
You never answered the question - Why?
What advantages do you see instead of just using your intel mac with the provided OS?
Agreed, nothing I said should be construed that we violate Apple's copyright of its source code implementations of its now expired patents. We can write own code implementations using reverse engineering techniques like the ReactOS and WINE teams did.
That said, I own official Apple-branded hardware, so pursuant to Apple's end user license agreement for macOS, I can run up to three concurrent instances of any prior macOS or OS X operating system on my Apple-branded hardware[1]. The license agreement expressly grants the right to use macOS in a virtualized environment, including ABI libraries for an Aqua, Quartz, and Cocoa compatibility layer running on top of FreeBSD, in the exact same way that FreeBSD has a compatibility layer for Linux…
So if you own Apple-branded hardware there is really no need to reverse engineer anything, because Apple already grants you a license to use Apple's software in any way you see fit on Apple-branded hardware, so long as it is for personal non-commercial use.
[1]: https://www.apple.com/legal/sla/docs/macOSSequoia.pdf
Because in roughly two years Apple is going to drop support for the amd64 ISA. I'm not going to abandon over forty years of software development just because Apple wants to extract more money from me with their proprietary vender locked silicon… I've been down that road before and I'm not going back.
maflynn
macrumors Broadwell
And nothing is stopping you from using the OS that's currently on the the Mac.
So you're looking to develop a new OS built upon Darwin, and the expired 10.4 patents with adding new features that you want? Is that a correct assessment of your thread?
No, just no. I don't even like Darwin, XNU, or Mach, under the hood Apple's "engine" is a total POS nightmare to deal with, I can't tell you how many times I've figuratively pulled my hair out trying to get their cockeyed implementation of unix to do things that are extremely trivial to do on any other unix like operating system. I only use it now because the applications that I want to run are designed to run on the Aqua GUI that is built on top of them, and Apple is currently willing to support their Frankenstein POS. But in about two years Apple isn't going to support it anymore, so I'm talking about porting Apple's Aqua GUI to FreeBSD so that you can run Intel Mac applications on a traditional *nix machine. 🤷♂️ I want to create an exit ramp so we can get off this nightmare ride.
Last edited:
maflynn
macrumors Broadwell
So what does an exit ramp mean exactly? And what does that have to do with expired 10.4 patents?
I'm not trying to be purposely obtuse, I'm asking specifics, and you're responding with vague comments.
What exactly are you looking for? You mentioned the patents, you mentioned darwin, you said there's millions of intel macs in the wild. Please be specific
maflynn — ok, specifics, because I think we’re talking past each other.
When I say “exit ramp”, I’m not talking about “porting Tiger” or freezing myself onto a 20‑year‑old OS. I’m talking about building the macOS application runtime + GUI stack that Intel macOS apps expect (Cocoa/AppKit + CoreFoundation + Quartz/CoreGraphics/CoreAnimation + the WindowServer/compositor semantics) *on top of a modern nix kernel (FreeBSD first, and potentially Linux too).
In plain English: the same idea as WINE/Proton for Windows apps, except this is for Intel macOS apps, and the host OS is FreeBSD (or Linux). The goal is to run native *nix GUI apps (Qt/GTK) side‑by‑side with native Mac apps in the same desktop session.
1) What “exit ramp” means (concretely)
It means:- I can keep using the Intel Mac applications I already depend on even after Apple drops amd64 and stops shipping security updates for my hardware/OS line.
- I can move the “real OS” under my feet to something sane and maintainable long-term (FreeBSD: ZFS, jails, ports, predictable upgrades, etc.) without giving up the apps that are locked to Aqua/Cocoa.
- I can run those Mac apps as first-class desktop windows alongside Qt/GTK apps, not inside a full-screen VM.
2) What this has to do with “expired 10.4 patents”
The “patents” point was never “we can copy Tiger.” We obviously can’t copy Apple’s source code or trade dress and pretend it’s ours.The patents angle is just: a lot of the core concepts behind Aqua/Quartz/Cocoa are not new inventions from last year—many are decades old—so patent landmines are less of a blocker than people assume. The real blockers are:
- engineering effort (huge),
- behavior compatibility (harder than “UI looks similar”),
- and not copying Apple’s copyrighted implementation.
3) What you actually have to build to run “arbitrary Intel Mac apps” on FreeBSD
To run arbitrary Intel macOS GUI apps, you need to supply three big layers:- Binary + syscall personality (so the program can start and make OS calls)
- Framework/runtime layer (so it finds the libraries it was linked against)
- GUI + compositor integration (so windows render and receive events)
Below is what that looks like in concrete components.
A) The “Darwin personality” on FreeBSD (kernel + loader layer)
A1) Mach‑O executable loading (required day one)
macOS binaries are Mach‑O. FreeBSD natively expects ELF. So you implement one of:- Kernel loader: add a imgact_macho loader similar to FreeBSD’s existing “personalities” (think compat layers) so execve() recognizes Mach‑O, maps segments, sets up stack/TLS, and transfers control to the dynamic linker.
- Userland loader: register Mach‑O via binmiscctl (or equivalent) and dispatch Mach‑O execution to a userland “macho-runner” that emulates the exec loader and then hands off to dyld.
A2) dyld / dynamic linking (required day one)
Mac apps assume dyld, not ld.so. You need to provide:- dyld (or a dyld-compatible loader) that understands:
- frameworks (/System/Library/Frameworks/...)
- @rpath, @executable_path, @loader_path
- fat/universal binaries (pick x86_64 slice)
- symbol resolution rules exactly like macOS expects
A3) Syscall + Mach IPC compatibility (“Darwinulator” concept)
Even “simple” macOS userland expects a bunch of Darwin/Mach behaviors. You can do this in two ways:Option 1: Implement Darwin/Mach compatibility directly on the FreeBSD kernel
Like FreeBSD’s Linux binary compatibility conceptually: map foreign syscalls to native kernel primitives, implement missing semantics, and provide the expected process/thread/memory behavior. (FreeBSD already proves this model works at scale with Linux binaries.)
Option 2: Hybrid kernel module / server approach
Keep the FreeBSD kernel mostly untouched and implement Mach-ish services in a privileged server + a small kernel module for the handful of things you can’t fake efficiently (message passing, some vm calls, etc.). You’re essentially recreating “just enough Mach” for userland.
In practice you’d implement at minimum:
- process/thread primitives expected by libSystem + libpthread
- kqueue/event semantics that macOS libs rely on (FreeBSD already has kqueue, which helps)
- mmap/vm_* behaviors Mac runtimes assume
- Mach messaging primitives (mach_msg style IPC) or a compatible abstraction
- signals/exception behavior close enough for crash handlers, debuggers, etc.
B) The macOS userland runtime on top of that (libraries/frameworks)
This is the “WINE part” of the project.B1) Core runtime libraries (required before anything GUI works)
You need equivalents of:- libSystem (the umbrella of libc + pthread + syscall stubs)
- Objective‑C runtime (libobjc) and associated ABI behavior
- libdispatch (Grand Central Dispatch) because modern code assumes it
- CoreFoundation (CFRunLoop, CFType, bundles, localization, property lists)
B2) Cocoa/AppKit (the real “Aqua app” API surface)
Most Intel Mac GUI apps are Cocoa. They need:- Foundation (strings, collections, file APIs, KVO, notifications, bundles)
- AppKit (NSApplication event loop, NSWindow, NSView, menus, controls, text system)
- nib/storyboard loading behaviors
- pasteboard, drag/drop, services
A pragmatic path here:
- Use an existing Cocoa reimplementation as a bootstrap (even if incomplete), then iteratively improve behavioral compatibility until real apps run.
- Compatibility work is less about “drawing rounded buttons” and more about subtle things like responder chain, runloop modes, text layout quirks, event coalescing, timers, etc.
B3) Quartz/CoreGraphics/CoreText + image codecs
GUI apps need:- CoreGraphics drawing model (paths, compositing modes, PDF rendering)
- CoreText font shaping/rendering
- ImageIO codecs (PNG/JPEG/TIFF/etc), color management (at least minimally)
B4) CoreAnimation + compositing model
Modern AppKit apps assume CoreAnimation. So you need:- CALayer tree management
- compositing, transforms, opacity, backing stores
- vsync timing model good enough for UI smoothness
- accelerated path via OpenGL/Vulkan (or at minimum a software fallback)
C) The GUI integration that makes this an “exit ramp” instead of a VM
This is the part you’re specifically asking about: run Mac GUI apps and Qt/GTK apps concurrently.C1) WindowServer equivalent as a translation target, not necessarily a clone
macOS has a WindowServer/compositor model. On FreeBSD you don’t need to literally replicate the entire internal architecture, but you do need a component that:- owns top-level windows
- routes input events (mouse/keyboard/IME)
- manages z-order, focus, spaces/virtual desktops if you want them
- composes surfaces efficiently
Concretely:
- Each NSWindow maps to a host surface/window
- Drawing output (CoreGraphics/CoreAnimation) renders into buffers
- Those buffers are presented to Wayland/X11 as window contents
- Host WM handles stacking, multi-monitor, etc.
C2) Desktop-level integration (so it feels unified)
To be a real exit ramp, you also build:- clipboard sharing between Mac apps and *nix apps
- drag-and-drop bridging (files + text)
- shared file dialogs or a “native” file picker mapping
- notifications mapping (NSUserNotification → host notification system)
- global menu bar support optionally (or just per-window menus)
C3) Audio/video/input
To run real desktop apps you implement:- CoreAudio → host audio stack
- HID/input events → host input
- basic video decode paths for common formats (or map to ffmpeg pipeline)
D) Compatibility strategy: how you get from “hello world” to “arbitrary apps”
To get to “run essentially any arbitrary Intel Mac app” you don’t start with Photoshop. You do it in phases:Phase 1 — CLI Darwin environment
- Mach‑O loader + dyld + libSystem-ish stubs
- enough syscalls to run basic command line macOS binaries
Phase 2 — Foundation + Objective‑C runtime
- get non-GUI Cocoa tools running
- implement bundles, plist, localization
Phase 3 — Basic AppKit GUI
- one window, basic controls, event loop
- rendering via a simple 2D backend
Phase 4 — Quartz/CoreText/CoreAnimation
- real text system
- layer-backed views
- basic compositing
Phase 5 — “Desktop integration”
- clipboard, drag-drop, file open
- packaging of .app bundles (LaunchServices-like behavior)
Phase 6 — The hard cases
- GPU-heavy apps, private frameworks, modern security expectations, etc.
E) The practical safety valve: VM-based seamless mode (optional, but realistic)
If your requirement is truly “any arbitrary Intel Mac app,” the only approach with near‑100% compatibility is: run real macOS in a VM and integrate its windows into the host desktop (seamless/unity mode style).That can still be an “exit ramp” because:
- the host OS is FreeBSD
- the VM is just an application provider
- Mac apps show up as windows next to GTK/Qt apps
- Native compatibility for a large and growing set of apps
- VM fallback for the apps that depend on proprietary/private frameworks or very exact modern behaviors
F) “Possibly also Linux kernel”
That’s feasible if you architect it cleanly:- Keep the framework/runtime layer portable (mostly userland code).
- Keep the kernel personality layer thin and OS-specific:
- FreeBSD backend (Darwinulator style)
- Linux backend (either native implementation or reuse the existing Darwin-on-Linux approach)
And on the BSD side there are explicitly macOS-inspired FreeBSD projects pursuing compatibility goals (ravynOS).
So this isn’t “I had a shower thought.” It’s a known class of problem with known approaches—it’s just a lot of work.
4) So, what exactly am I looking for?
I’m looking for the feasibility (and ideally community interest) in building a FreeBSD-hosted Aqua/Cocoa/Quartz compatibility stack that:- boots and runs Mach‑O Intel macOS apps,
- displays them as normal windows under a *nix compositor,
- allows them to coexist with Qt/GTK apps,
- and provides a path off Apple’s unsupported Intel future.
If your objection is “that’s massive effort,” sure—it is. But now we’re at least discussing the actual technical project, not “porting Tiger.”
Have you looked at:
GitHub - LibreCorp/OpenOSX: A open-source initiative to build a fully open and free version of Mac OS.
A open-source initiative to build a fully open and free version of Mac OS. - LibreCorp/OpenOSX
github.com
P.S.One challenge is that even if we develop an OS that is perfectly ABI compatible with MacOS X, will there be any supported commercial software for it circa 3030? That is, will Microsoft, Adobe, Tableau, etc continue to release for it? If not, maybe the effort would be better invested in building up existing OS to be a better targets for developers?