Under MacOS X, you use Unix under the hood. This is basically the kernel (mach/bsd) which is open source plus the whole environment which originally NeXT has developed and Apple has adopted when taking over NeXT. This is a set of libaries in user space along with a lot of applications. The libraries are commonly referred to as Cocoa and are not open sourced by Apple (well some small parts are). Cocoa are the building block of all MacOS X desktop apps. Everything you do to open windows, to have menu bars etc is normally done using Cocoa.
Now if you port application from or to MacOS X you have various ways of doing this.
If you come from the Unix environment, you can write apps which use the Xwindow system environment to use as a gui. Apps will look different to native MacOS X apps and certain things are not really direct such as copy & paste from/to OS X apps etc. But I have seen some applications which work very well in this environment (wireshark for example) and some who behave very odd.
If you come from a Windows environment you could use Wine to emulate windows API calls to then use Xwindow again to get on to MacOS X desktop. It works but it doesn't look like Mac nor does it perform too well. Running Paralles and a virtual Windows machine with the same native app is usually faster (but you need to own Windows and Parallels or VMware Fusion or similar).
The easiest to port is command line stuff, that usually works 99% out of the box as there we're talking straight unix system calls.
Now imagine you do the other way around. From MacOS X to other platforms. Now again, command line will work the other way around. To bring the Cocoa environment to Unixes and Windows
Now if you want to write cross platform applications the other way around, you can't use Cocoa on other platforms. You could write your initial app under MacOS X using the Carbon framework which emulates the MacOS 9 layer and some folks have redeveloped that API on Windows. But frankly, Carbon is no longer supported so its not a good idea to base new development on it. Or you could use Xwindows to easy port it to other Unixes but then it doesnt look as geeky as it could under MacOS X. And we all want that right?
So there's basically no way around Cocoa. To have a cocoa like environment under unix there's the GNUStep environment which works nicely for older Apps. If you want to use the newest ObjectiveC 2.0 stuff such as @synchronized {}, @properties, for(object in collection) and the like (you know the stuff which saves you thousands of lines of lame repetitive ode you have to write otherwise) then you better go with Cocotron. Cocotron is another Cocoa clone. It runs on Windows and various Unixes. Its done in a way that you compile everything on your mac using cross compilers and then only run it under Windows or Unix. This cross compliation has advantages and disadvantages. The advantage is that you compile everything out of one source tree in one go and you can use the nice Xcode for that. The disadvantage is that you definitively need a Mac and that building working cross compilers is a messy process. This especially since Xcode 4.x and since Apple has switched to clang instead of gcc. Gcc is being phased out on MacOS X and lots of objective C 2.0 stuff is not backported yet into the mainstream gcc. Apple's own source tree of gcc however is not being further developed and its not able to generate code except its own binary format Mach-o. So you can not easy produce ELF binaries for Linux under MacOS X with a good objective-C 2.0 support without a lot of hacking stuff together. The developers of Cocotron have done a long way that road and got it amazingly well working for Windows cross compiling. The Unix world however has been left behind and has not been well maintained. So creating cross compilers for Linux for example was failing a lot of times for me. I have thus took another approach to compile cocotron and apps based on it directly under Linux and instead of using GCC I'm using clang / llvm which gives way better results in objective C 2.0 support. Furthermore clang gets all the blessing of new features from Apple automatically as Apple is putting their changes back into clang's source so we are way more long term safe. In clang, the compiler doesn't care if the output format is ELF or Mach-o or whatever. The llvm backend takes care of that. That's the big advantage of llvm. To get cocotron to compiler under Linux properly it took quite some work but now we have it working and its working great!
If you want to try to port your MacOS X code to Linux, then consider using Cocotron. How to get a working compiler and the libraries done, you can find on my separate page cocotron.fink.org where I have documented all the steps to get it working in detail.