Rendered at 12:13:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ncr100 11 hours ago [-]
> Do you know about opensource.apple.com, GNUstep, The Cocotron and other projects?
> We do, and in fact, Darling is largely based on the original Darwin source code published by Apple. We use The Cocotron as a basis for our Cocoa implementation, along with the Apportable Foundation and various bits of GNUstep.
In theory, running Apple Silicon apps on ARM64 linux machines would be really nice. But we are still far from having a performant and feature-complete implementation of doing so.
Darling only targets x86_64 stuff. Still, it's a cool project.
Kinda sad that there are very few updates though [1]
their AppKit implementation receives about 20-30 commits every 5 years. Cool project, but
you are better off waiting for proprietary software manufacturers to release ARM64 builds (a lot of them do now) and patch the holes with FEX.
ay 12 hours ago [-]
I went down a deep but entertaining rabbit hole in the other direction for fun: https://github.com/ayourtch-llm/fakelinux - initially with the idea “just replace the syscalls in the executable with some sort of a trap and handle that”.
It almost worked, unfortunately MacOS reserves x18 for platform purposes and Linux doesn’t.
The result is some sort of pretty mad contraption which works sufficiently often to compile aarch64 Linux VPP and its dependencies on the Mac using Linux gcc :)
I suppose with some polish it might be useful for something..
ishaderdevicemg 10 hours ago [-]
Recently, Apple has made it so with a special entitlement, com.apple.private.custom-x18-abi iirc, you can actually use the x18 register, mainly so ARM64 versions of WINE/CrossOver can run outside of Rosetta, since they'll be partially killing Rosetta in macOS 28.
In the current betas, there's actually more entitlements that allow this, not just private ones.
floam 10 hours ago [-]
com.apple.private.uexc as well?
jagged-chisel 12 hours ago [-]
Quibble: it'll run anything that runs on open source Darwin. You won't be running anything needing macOS frameworks.
999900000999 12 hours ago [-]
Very neat.
All I want for Christmas is Logic on Linux. But then you’d still need a Mac to legally download it from the App Store and DRM checks would probably only work on Macs
Melonai 10 hours ago [-]
Agh that's one of my biggest Linux regrets! Logic Pro is probably my favorite DAW, it feels so smooth to use, and that's likely connected to me using GarageBand extensively when I was a child. (I still remember "composing" multiple memorial songs in honor of Steve Jobs, as weird as that sounds!)
The strategy Apple has figured out with GarageBand pre-installed (or at least very low friction to install) seems really really smart in hindsight, give complete beginners a highly simplified but functional version of your professional utility, and provide an on-ramp to your professional programs. I imagine if Microsoft had some professional version of Windows Movie Maker it would've taken over a big chunk of the video editing market via the same method.
Anyway, regarding Linux DAWs, I am trying to get used to Ableton in Wine, but it's just not the same, and making it work in Wine is troublesome enough that I end up giving up before finishing anything of interest. Is there any DAW that feels like it actually belongs on Linux and doesn't either feel like you're maintaining a package by yourself, or has an awfully bad UI/UX like all FOSS DAWs I tried so far? I think in 2026 there's really a good opportunity here, with user interest genuinely rising for Linux on desktop.
999900000999 9 hours ago [-]
WINE doesn’t work well with DAWs.
Most DAWs barely work on the platforms they support.
I can’t see Linux as being a viable market since most Linux users except software to generally be free.
Vs OSX which lets you enter a credit card number and buy stuff right from the built in store.
If I recall Ubuntu might of once attempted paid applications on its built in store and it didn’t really work.
Logic is probably made at below cost, but it keeps you in the OSX ecosystem.
Need a 32GB OSX box with a 2TB drive, only one place to get it.
> "composing" multiple memorial songs in honor of Steve Jobs, as weird as that sounds!
Very strangely fitting: using Jobs "bicycle for the mind" to compose this in his honor :)
nnevatie 7 hours ago [-]
Reaper is available on Linux.
bigyabai 9 hours ago [-]
Bitwig natively supports Linux. I bought a license a while ago and while the cost is steep, I don't regret it at all.
The downsides are going to be the bland cross-platform UI and the general lack of plugin support on Linux. But the upside is native PipeWire support for application-specific channel audio and complex output routing options. The pack-in plugins are pretty good too, The Grid can replace a lot of your subtractive synths: https://www.bitwig.com/the-grid/
vunderba 8 hours ago [-]
+1 for Bitwig - written by a bunch of former Ableton devs and its external plugin/module sandbox means that a badly behaving VST won't take down the entire DAW.
tgv 2 hours ago [-]
I don't think anyone has an implementation of macOS' audio and midi frameworks (and whatever else Logic links to; probably a lot). I would like to have Hauptwerk under Linux, but it uses ilok, and that's not going to happen any time soon. But we can dream.
inatreecrown2 11 hours ago [-]
Give Reaper a try, it works very well on linux and you can even use VSTs.
tensor 10 hours ago [-]
Sadly a lot of VSTs are Windows and Mac only too due to shitty DRM. :-(
inatreecrown2 9 hours ago [-]
True. On the other hand, there are top quality developers like u-he Urs Heckmann that provide native linux support.
SyneRyder 6 hours ago [-]
AudioThing, TAL and Modartt have Linux versions as well. Korneff Audio is moving in that direction, but not everything is ported over yet.
dosisking 9 hours ago [-]
> All I want for Christmas is Logic on Linux.
Linux has a terrible audio subsystem. First you'd have to write CoreAudio for Linux, which would not be easy.
bwindels 2 hours ago [-]
If you're referring to pulseaudio or alsa, more recently pipewire should have improved the situation a lot.
999900000999 8 hours ago [-]
Linux audio is great when it works. In my experience a good chunk of the time either Linux audio or Bluetooth is completely bonked out of the box
dyzone 9 hours ago [-]
Bitwig works on linux. I just installed and ran it. Zero issues. Bitwig team has just 30 people.
boudin 2 hours ago [-]
What's terrible? It just work out of the box.
pacifika 6 hours ago [-]
You wouldn’t want to run it without instruments and effects I’d imagine.
nnevatie 7 hours ago [-]
There’s always Reaper.
nonestdeus 12 hours ago [-]
Cool that it exists, but I honestly don't even know which mac exclusive program I would want to install.
jeremyjh 7 hours ago [-]
If its possible to compile & and sign iOS or MacOS apps that would be VERY useful in CI environments, but yeah hard to think of other killer command-line apps that only run on MacOS.
If they had good GUI support then some more things open up but nothing really essential. Garage Band has no equal in terms of ease of use, if you are into that sort of thing.
It has built in support for Electron, JVM, Flutter and even native apps (although of course then you still have to compile the native binaries on macOS yourself).
That also works the other way around. You can ship to Windows from Linux or macOS.
Gigachad 8 hours ago [-]
Might be useful to run ARM mac apps on ARM Linux vs using Wine + an x86 emulation layer.
LollipopYakuza 11 hours ago [-]
A few years back, I would have dreamt to run Photoshop on Linux.
But this and the mandatory utilities that come with it became so bloated that even if it was officially offered on Linux I am not sure I would be using it.
testing22321 10 hours ago [-]
You don’t have to run the latest photoshop. (Or Lightroom..)
I run the last version I could fully buy before it went subscription based. It’s great.
Alien1Being 10 hours ago [-]
Is there some really amazing Mac only software that would justify the effort ?
I genuiniely can't see why I would want to run Mac software on my Arch box.
I have used Linux since the 1990's and used the Mac back in 1988.
ashton314 6 hours ago [-]
Glyphs is like the only game in town for font editing. I’m an Omnigraffle enjoyer too.
wwweston 9 hours ago [-]
For me it’s mostly media apps - Fireworks CS 6, Reason 10, maybe some version of Garage Band. There’s alternatives but these apps hit a sweet spot that I could camp out on for decades if the tech treadmill didn’t like to make software an exercise in seeing shifting shapes in the clouds.
tensor 10 hours ago [-]
There are lots of amazing Mac only apps, but I'm not sure simply running them on Linux would be worth it. Without the cohesiveness of the UI as a whole you'd be losing a lot.
ghm2199 9 hours ago [-]
Why can't we just be satisfied with wayy old mac versions in VMs on linux, ones where you played prince or persia or oregon trail, the fun looking black and white versions and some later ones their steel windows UIs, the theming, the file explorer, the note taker app.
Isn't that level of fun one gets from looking at that enough?
BillStrong 5 hours ago [-]
Hardware acceleration for OS X era OSes, for one.
throwaway19567 9 hours ago [-]
Mac OS X binaries are the most susceptible to bit rot of any major OS. There's constant platform churn, all of it closed source, and there's nowhere near the community that exists around emulating older Windows.
You can reliably run DOS, Win, Linux applications of almost any vintage with the right translation layer / emulator, but there's a black hole of MacOS apps circa 2002-2012 that just no longer runs on anything, even later Intel Macs.
I used to enjoy a cute little Pacman clone called Pac the Man X, for example, and I just don't know how I could run this today. Seems to reliably take down any emulator I've thrown at it - presumably it's using some kind of graphics acceleration that's not emulated. (Suggestions welcome.)
BillStrong 5 hours ago [-]
VMs with GPU passed through. You can get Mac compatible GPUs that will work, look for the Dortania OpenCore guide GPU lists to find one that works for the version of Mac OS X it runs on. Looking on Macintosh Repository, that game will run on Intel CPUs and Snow Leopard, 10.6+. (IDK for sure.) You can emulate Intel Mac OS X using QEMU on linux machines, there are some scripts that make it easy from Proxmox that I use.
You can also emulate PPC Mac OS X and pass through devices, but I have not tried to do this, so your mileage may vary.
It is easier to emulate 10.7+ versions than 10.6, but you can get it to work from 10.4 with work.
This is the Darling project which aims to run macOS software on Linux for both Intel and ARM64.
But you are probably looking for this:
> Does it support GUI apps?
> Almost! This took us a lot of time and effort, but we finally have basic experimental support for running simple graphical applications.
It is still far away from running your favorite mac GUI apps like Logic Pro or Xcode, but it is a work in progress but can still run command line tools.
dylan604 12 hours ago [-]
What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing? I'd even be willing to limit to x86 apps. Or maybe there is and I'm just really out of touch??
tengwar2 12 hours ago [-]
At a guess: the "killer apps" are things like MS Office and Photoshop, and since they are usually available on both Windows and Mac, there's not such a pressing demand to support similar functionality for Mac apps if the Windows version is easy to obtain.
dylan604 12 hours ago [-]
That's such an obvious answer that I'm honestly embarrassed that it did not occur to me. <facepalm> Thanks for not rubbing it in!
stuaxo 10 hours ago [-]
Wine has been going for a very long time - since 1993.
When it started Windows was a lot smaller, so getting Windows 3.1 programs working was probably enough.
There's too much history to cover in a quick comment.
Wine has a lots of things that help - the compatibility database https://appdb.winehq.org/ is a good place for people to submit info on apps for instance, there's also a big test suite that runs against Windows + Wine.
Both of these have been around since the 1990s - Darling is at an earlier stage, but once GUI apps run better both of those are good ideas to adopt.
I think Darling probably needs more people working on it.
Also, Mac is a moving target. Each year, there is a new version that is basically its own little snowflake, with older things deprecated and newer things added.
Windows 11 will still run Windows apps from Windows 3.1, because they have a backwards compatibility effort that Apple eschewed.
Now that makes it more complex to emulate all the features, but the core features used by most programs get emulated, and then just add features for specific programs to get them to work. And games tend to use core features and DirectX or OpenGL, mostly, whereas productivity apps and other things can do lots of weird things that are non-standard.
For Mac OS X, you really need to handle each versioon of Mac OS X. There are some core features that may work across versions, and some features that are available only on certain versions, then some features that are unique.
crazysim 12 hours ago [-]
While the productivity apps are mentioned in the other comments of this reply, games are another reason. There are far more games on Windows to port and handle than macOS games. And in that case, you got a financial desire in the form of Valve and its Steam store. macOS games tend to be ports from Windows and are usually less featureful.
GeekyBear 12 hours ago [-]
GNUstep ran early MacOS apps on Linux after Apple bought Next and adopted their APIs.
I don't think the project kept up with changes to the APIs over the decades compared to how well the Wine project kept up with changes in Windows.
duskwuff 11 hours ago [-]
> GNUstep ran early MacOS apps on Linux after Apple bought Next and adopted their APIs.
No, it did not. There was no point at which GNUstep provided binary compatibility with Mac OS applications - while the two ecosystems shared some common history, it was much too far back to provide any form of compatibility. Additionally, Mac OS X used a different executable format than Linux or other UNIX-like operating systems, and GNUstep never attempted to provide that sort of low-level compatibility.
(For perspective: the GNUstep project started in the early 1990s. Mac OS X was first released to users in 2001.)
It may have been possible for some developers to port applications between Mac OS X and GNUstep while sharing some code, but that's a long way from running an unmodified application.
asveikau 12 hours ago [-]
Win32 has a little less churn than AppKit used to. If you support the API surface of winxp from 25 years ago you can run a lot of stuff. Most teams inside Windows at MSFT also try to leave older APIs alone and introduce stuff in an additive fashion. Apple, by contrast, historically has app compatibility as a non-goal.
I said "used to" because anecdotally, I had a personal project I haven't released anywhere target AppKit, I haven't been maintaining it because life is busy, I recently rebuilt it for the first time in a long time and I was shocked that everything worked. ~8 years ago, you would need to do some porting to a new major release once per year. I skipped that maintenance for many releases and didn't need to change a single line. This tells me that desktop apps are not at all an area of major focus for them lately. Maybe swiftui is getting all the attention. They are doing something more resembling Microsoft, leaving the old shit alone.
AdieuToLogic 11 hours ago [-]
> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing?
It is a technical thing.
The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instead are the GUI frameworks expected (i.e., Carbon[2], Quartz[3], etc.). These frameworks are intentionally written for Apple hardware/macOS distros. Which makes sense when viewing macOS as a selling point for selling Mac's.
No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.
AdieuToLogic 10 hours ago [-]
Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible.
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
bri3d 10 hours ago [-]
I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Certainly, vertical integration makes OS porting (ie Asahi) and lower level emulation more difficult, since the hardware and firmware's contract with the OS is entirely proprietary and can be freely changed from revision to revision, but something like WINE operates many layers above this anyway.
There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.
I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.
AdieuToLogic 9 hours ago [-]
>> Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
> I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier.
Here is my corroboration. Apple publishes XNU to the world in this repository:
https://github.com/apple-oss-distributions/xnu
There is no such publication of the GUI frameworks required by macOS programs.
> I do think there is an argument to be made that Win32 was more straightforward ...
I did not make that argument. Instead, the position I hold regarding Windows is:
... an independently derived emulation layer is
possible (not easy, just possible) ...
When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced.
In fact, you have made my point for me:
> ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.
BillStrong 5 hours ago [-]
There is a project to use the Snow Leopard kernel and open source components and some bits from the prerelease Snow Leopard on PPC to create a working PPC Snow Leopard.
I wonder if something like that might be a short term viable path to get working apps. Something like the non-opensource libraries as a download pack for certain each release of Mac OS X, for at least versions Apple no longer supports, to get working programs, then you could slowly work toward open implementations.
dosisking 9 hours ago [-]
> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS?
Backwards compatibility. Apple changes their API every year or so, usually for no good reason.
12 hours ago [-]
12 hours ago [-]
cyberax 12 hours ago [-]
> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS?
A lot of work done over 3 decades. Wine also started when Win32 was something comprehensible by one person, so they could build it up slowly.
tootie 11 hours ago [-]
Will it run xcode build tools?
stuaxo 10 hours ago [-]
From the FAQ on the Discord:
*Does Xcode work?*
Yes and no. The Xcode GUI definitely doesn't work yet; see *Will <<Insert_Random_GUI_Application>> Work?* above. However, the Xcode CLI tools like Clang, LLDB, Git, the Metal compiler, the Swift compiler, and more do work.
*What about `xcodebuild`?*
Some versions of `xcodebuild` (e.g. 11.7) are known to work for extremely basic XIB-based macOS apps. However, the vast majority of projects do not qualify as extremely basic and aren't supported yet.
yjuzz9 9 hours ago [-]
Finally, I can run Calculator.app and TextEdit on NixOS without buying a $3,000 aluminum cheese grater. Next up: emulating the spinning beach ball of death for authentic nostalgic immersion.
hstaab 9 hours ago [-]
Unfortunately you may never see the beach ball
dosisking 9 hours ago [-]
> Next up: emulating the spinning beach ball of death for authentic nostalgic immersion.
It looks more like a Magneto-Optical Drive, not a beach ball
Marchant_hq 7 hours ago [-]
Curious if this finally makes Sketch or Affinity Photo usable on my Linux box. Apple Silicon VM performance is usually the bottleneck.
SilentM68 12 hours ago [-]
Would be nice to run Final Cut Pro on Linux without having to pay an arm and a leg for the actual machine. It's a really expensive toy :(
adamgoodapp 10 hours ago [-]
For me its a shame to make the Mac apps look like linux.
xyst 11 hours ago [-]
The real/final test is running applications like Final Cut Pro using `darling`
> We do, and in fact, Darling is largely based on the original Darwin source code published by Apple. We use The Cocotron as a basis for our Cocoa implementation, along with the Apportable Foundation and various bits of GNUstep.
Apportable (<3) was a YC startup https://www.ycombinator.com/companies/apportable from 2011 - the Foundation repo last update was Dec 2014.
Darling only targets x86_64 stuff. Still, it's a cool project.
Kinda sad that there are very few updates though [1]
[1] https://blog.darlinghq.org/
It almost worked, unfortunately MacOS reserves x18 for platform purposes and Linux doesn’t.
The result is some sort of pretty mad contraption which works sufficiently often to compile aarch64 Linux VPP and its dependencies on the Mac using Linux gcc :)
I suppose with some polish it might be useful for something..
I believe you can find slightly more info on how to use it in some XNU (macOS kernel) tests, namely this one: https://github.com/apple-oss-distributions/xnu/blob/main/tes...
All I want for Christmas is Logic on Linux. But then you’d still need a Mac to legally download it from the App Store and DRM checks would probably only work on Macs
The strategy Apple has figured out with GarageBand pre-installed (or at least very low friction to install) seems really really smart in hindsight, give complete beginners a highly simplified but functional version of your professional utility, and provide an on-ramp to your professional programs. I imagine if Microsoft had some professional version of Windows Movie Maker it would've taken over a big chunk of the video editing market via the same method.
Anyway, regarding Linux DAWs, I am trying to get used to Ableton in Wine, but it's just not the same, and making it work in Wine is troublesome enough that I end up giving up before finishing anything of interest. Is there any DAW that feels like it actually belongs on Linux and doesn't either feel like you're maintaining a package by yourself, or has an awfully bad UI/UX like all FOSS DAWs I tried so far? I think in 2026 there's really a good opportunity here, with user interest genuinely rising for Linux on desktop.
Most DAWs barely work on the platforms they support.
I can’t see Linux as being a viable market since most Linux users except software to generally be free.
Vs OSX which lets you enter a credit card number and buy stuff right from the built in store.
If I recall Ubuntu might of once attempted paid applications on its built in store and it didn’t really work.
Logic is probably made at below cost, but it keeps you in the OSX ecosystem.
Need a 32GB OSX box with a 2TB drive, only one place to get it.
Very strangely fitting: using Jobs "bicycle for the mind" to compose this in his honor :)
The downsides are going to be the bland cross-platform UI and the general lack of plugin support on Linux. But the upside is native PipeWire support for application-specific channel audio and complex output routing options. The pack-in plugins are pretty good too, The Grid can replace a lot of your subtractive synths: https://www.bitwig.com/the-grid/
Linux has a terrible audio subsystem. First you'd have to write CoreAudio for Linux, which would not be easy.
If they had good GUI support then some more things open up but nothing really essential. Garage Band has no equal in terms of ease of use, if you are into that sort of thing.
The Firefox source tree has every tool available for cross-compilation from Linux → macOS, which is how Firefox is built for macOS.
https://hydraulic.dev/
It has built in support for Electron, JVM, Flutter and even native apps (although of course then you still have to compile the native binaries on macOS yourself).
That also works the other way around. You can ship to Windows from Linux or macOS.
I run the last version I could fully buy before it went subscription based. It’s great.
I genuiniely can't see why I would want to run Mac software on my Arch box.
I have used Linux since the 1990's and used the Mac back in 1988.
Isn't that level of fun one gets from looking at that enough?
You can reliably run DOS, Win, Linux applications of almost any vintage with the right translation layer / emulator, but there's a black hole of MacOS apps circa 2002-2012 that just no longer runs on anything, even later Intel Macs.
I used to enjoy a cute little Pacman clone called Pac the Man X, for example, and I just don't know how I could run this today. Seems to reliably take down any emulator I've thrown at it - presumably it's using some kind of graphics acceleration that's not emulated. (Suggestions welcome.)
You can also emulate PPC Mac OS X and pass through devices, but I have not tried to do this, so your mileage may vary.
It is easier to emulate 10.7+ versions than 10.6, but you can get it to work from 10.4 with work.
https://gist.github.com/JoshCooley/095b80f9639a4dc7e762208ae...
But you are probably looking for this:
It is still far away from running your favorite mac GUI apps like Logic Pro or Xcode, but it is a work in progress but can still run command line tools.When it started Windows was a lot smaller, so getting Windows 3.1 programs working was probably enough.
There's too much history to cover in a quick comment.
Wine has a lots of things that help - the compatibility database https://appdb.winehq.org/ is a good place for people to submit info on apps for instance, there's also a big test suite that runs against Windows + Wine.
Both of these have been around since the 1990s - Darling is at an earlier stage, but once GUI apps run better both of those are good ideas to adopt.
I think Darling probably needs more people working on it.
The whole are of Metal on Vulkan looks interesting https://github.com/darlinghq/darling/issues/390#issuecomment...
Windows 11 will still run Windows apps from Windows 3.1, because they have a backwards compatibility effort that Apple eschewed.
Now that makes it more complex to emulate all the features, but the core features used by most programs get emulated, and then just add features for specific programs to get them to work. And games tend to use core features and DirectX or OpenGL, mostly, whereas productivity apps and other things can do lots of weird things that are non-standard.
For Mac OS X, you really need to handle each versioon of Mac OS X. There are some core features that may work across versions, and some features that are available only on certain versions, then some features that are unique.
https://en.wikipedia.org/wiki/GNUstep
I don't think the project kept up with changes to the APIs over the decades compared to how well the Wine project kept up with changes in Windows.
No, it did not. There was no point at which GNUstep provided binary compatibility with Mac OS applications - while the two ecosystems shared some common history, it was much too far back to provide any form of compatibility. Additionally, Mac OS X used a different executable format than Linux or other UNIX-like operating systems, and GNUstep never attempted to provide that sort of low-level compatibility.
(For perspective: the GNUstep project started in the early 1990s. Mac OS X was first released to users in 2001.)
It may have been possible for some developers to port applications between Mac OS X and GNUstep while sharing some code, but that's a long way from running an unmodified application.
I said "used to" because anecdotally, I had a personal project I haven't released anywhere target AppKit, I haven't been maintaining it because life is busy, I recently rebuilt it for the first time in a long time and I was shocked that everything worked. ~8 years ago, you would need to do some porting to a new major release once per year. I skipped that maintenance for many releases and didn't need to change a single line. This tells me that desktop apps are not at all an area of major focus for them lately. Maybe swiftui is getting all the attention. They are doing something more resembling Microsoft, leaving the old shit alone.
It is a technical thing.
The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instead are the GUI frameworks expected (i.e., Carbon[2], Quartz[3], etc.). These frameworks are intentionally written for Apple hardware/macOS distros. Which makes sense when viewing macOS as a selling point for selling Mac's.
0 - https://en.wikipedia.org/wiki/XNU
1 - https://openlibrary.org/books/OL17205558M/Mac_OS_X_internals
2 - https://en.wikipedia.org/wiki/Carbon_(API)
3 - https://en.wikipedia.org/wiki/Quartz_(graphics_layer)
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.
I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.
> I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier.
Here is my corroboration. Apple publishes XNU to the world in this repository:
There is no such publication of the GUI frameworks required by macOS programs.> I do think there is an argument to be made that Win32 was more straightforward ...
I did not make that argument. Instead, the position I hold regarding Windows is:
When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced.In fact, you have made my point for me:
> ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.
I wonder if something like that might be a short term viable path to get working apps. Something like the non-opensource libraries as a download pack for certain each release of Mac OS X, for at least versions Apple no longer supports, to get working programs, then you could slowly work toward open implementations.
Backwards compatibility. Apple changes their API every year or so, usually for no good reason.
A lot of work done over 3 decades. Wine also started when Win32 was something comprehensible by one person, so they could build it up slowly.
*Does Xcode work?*
Yes and no. The Xcode GUI definitely doesn't work yet; see *Will <<Insert_Random_GUI_Application>> Work?* above. However, the Xcode CLI tools like Clang, LLDB, Git, the Metal compiler, the Swift compiler, and more do work.
*What about `xcodebuild`?*
Some versions of `xcodebuild` (e.g. 11.7) are known to work for extremely basic XIB-based macOS apps. However, the vast majority of projects do not qualify as extremely basic and aren't supported yet.
It looks more like a Magneto-Optical Drive, not a beach ball