I wonder how hard it would be to implement the Apple Obj-C runtime's ABI for GNUstep so that this could be used to run obj-c programs and perhaps eventually actual Mac apps. If it were shown to be feasible, I would expect the combination to get a lot of attention as an alternative to Wine for running proprietary apps on Linux.
The actual Objective-C API is very small and can be (naively) implemented in an afternoon. I'd expect programs that already work in GNUStep like GNUmail could be had running by someone who has knowledge of how LD_PRELOAD works but no other experience with GNUStep and OSX in a week or two.
The only significant thing missing from Objective-C itself is garbage collection, I think (which completely changes the game on Mac OS X). Blocks work, of course, and besides that, Objective-C doesn't actually add that much to C (that's sort of the point).
The Cocoa APIs are, of course, fairly incomplete. From a quick Google search, they don't seem to have finished Core Data, and I'd imagine things like Core Animation are quite a ways off. Then, there's the integration problem. People that are likely to develop with an alternative implementation of Cocoa are likely to be "Mac people", that is, user interface evangelists (Lion's iCal design aside). GNUStep apps don't fit in with Gnome, or KDE, or, well, any desktop environment that a large group of people care about.
As a person (admittedly, I'm just a student) that has developed both in Cocoa and GTK+, I've found convincing myself to work on my GTK+ projects to be a chore. To put it only somewhat mildly, Cocoa is probably the best framework I've ever used. Want something to smoothly slide to the left? You can do that, in one line of code. Want to pull down some data from the web and parse the XML response, all in a background thread? That's easily achievable with Cocoa, and you don't even have to think about the threading issues. It just happens.
GTK+ et. al. are, of course, open source projects. They're created by volunteer developers (let's leave Red Hat out of this, for convenience). In the end, though, does it matter to developers? Cocoa is fun. GTK+ has mostly directed me into hours of reading C API documentation while I'm writing code in languages that are not C.
I'm not really sure where I intended to go with this - it has little to do with the original post, which I think is an incredibly impressive piece of work, solving a task that make my API and UI concerns seem like minor squabbles.
GNUStep also has garbage collection (albeit Boehm, not the same as the collector in OS X). Yes, it is missing from the language, but it doesn't make OS X special. And all that needs to come along is a version of GNUStep that fits in with the desktop environment on a platform before people start developing for it.
Off topic: asking for some advice, since this loader sounds close to what I want. The problem: I need to use a huge C++ codebase that is developed on the Mac, and is used to generate a shared library used in a Java app with JNI, SWIG, and loaded with loadLibrary. It would be fantastic to be able to build a shared library on the Mac, and be able to use it on both Macs and Linux servers. Maintaining and building 2 versions is a nuisance. (A complete build takes a couple of hours, even on a fast box.) Probably not possible because shared libraries are very different on OS X and Linux, but long term it would save me a lot of time if it is, even if I had to patch the Linux JVM.
This loader will be buggy and incomplete, by it's nature, and won't really solve the problems inherent in loading a shared library from another OS into an existing native process.
Thanks for the response! It was a long shot, but I thought that I would ask in case someone new of a stable and reliable way to use OS X shared libraries on Linux. I imagine it would be easier on NetBSD.
Not really. The problem is the binary format itself - Linux, *BSD, and pretty much every Unix but AIX these days uses ELF, but OSX uses MachO. The two aren't compatible.
The easiest way to do this reliably would probably involve writing your own mini-linker load the Mach-O binaries in Linux from the JVM, bypassing dlopen() and friends.
For now. In theory, with enough emulated libraries, you could probably run anything with this. But I don't think the point is to run "random mac app" on Linux: it's probably more likely to enable something like iPhone development, which right now is Mac only.
I don't consider the 3.3.1 situation to be relevant, as in this case you would be running the official Apple toolchain.
If you had brought up the section of the iOS Developer License Agreement relating to "non-Apple-branded hardware" you might be in the right ballpark, but the legality of a similar clause in the Mac OS EULA was cast into doubt in the Psystar case. Psystar aside, the (non-commercial) OSx86 scene continues to thrive, unhindered by Apple.
At the end of the day, given that you would be running the official Apple toolchain, how would Apple be able to prove that a particular iOS app was not built on a Mac?
However, GCC and friends are licensed under the GPL: the code is published at http://opensource.apple.com; their only technical barrier so far is actually making it run on another OS.
That's not to say they couldn't block something like that, but with GPL code it does become significantly more difficult, if not (technically, not "this would take forever to port back to Linux") impossible.
I agree that this is a fair piece of precedent, but I would also like to note Apple eventually removed this clause and developers are again free to develop in other languages.
I don't know how exactly it all comes together, but I would hope that Maloader and Cocotron (http://www.cocotron.org/) would enable many Cocoa apps to run on Linux (on Intel) without recompilation.
From the Cocotron website: "The Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation."
