OSX intel.
OSX is cross platform by design. This is because it's basically a version of NeXTStep, which supported 68k, PPC, x86, and PA-Risc simultanously. In practice (shipped retail versions) it's been PPC only except for what has existed in a secret Apple lab. BTW, since I know how NeXTStep did cross-platform, I'd have spotted a dual architecture version of OSX in a heartbeat. I have friends who'd find it faster than that.
For an OS install disc to boot on a platform, (x86 is an ISA which makes up part of what a platform is) the installer disc must have some very platform specific code. A bootstrap, which is the OS loader, will be entirely different for nearly every platform even if they use the same CPU. Further, it takes more than recompiling to make a bootloader work on multiple platforms, since each platform expects different things from a bootstrap. This is one reason why OSX will not install on an IBM RS6000 (PPC). This is the first thing that is required to support a platform. This is basically BIOS dependant.
The second major thing is drivers. Some of which can be generic. Example, DOS used the generic MCDEX.exe driver for most cdroms. This is because most of them use the same commands. The same is true for hard drives. A standard IDE HD driver will take care of nearly every hard drive in existance. Some features may not be available, however the drive will still work. Also while many pieces of hardware require a specific driver, ethernet cards for instance, many cards can use the same driver (NE2000). This is because they use the same controller (processor), as well as other componenents.
The third major requirement is that the libraries (DLLs, .so files, etc) have been ported to the platform (this part is mostly CPU specific). This has to be done before the main part of the OS and included programs can be generated as executable (compiled). This can be very time consuming and obnoxious. In many cases however, as with the standard C and C++ libraries, they've already been ported to nearly every architecture under the sun. This would leave, in Apple's case, keeping the Objective C frameworks/libraries up to date on the target platform. Apple would only need to keep them up to date instead of porting them, because before NeXTSTep became OSX, the newest version of the libraries had to be ported to PPC from x86!
Another major requirement is that the kernel or basic OS can be booted on the hardware in question. This requires that the kernel is compiled for the CPU, and that it has the basic drivers it needs to load (IDE/SCSI, etc).
Lastly, third party application code would have to be written using good programming practices which generally removes any nasty gotchas when porting to another architecture. The only change most Cocoa programmers have had to make is dealing with the endian-ness issue, which is amazingly simple. Even knowing the little amount of C++ I know, I thought that the endian fix was ridiculously simple. The author of Delicious Library said that it took 40 seconds to recompile it, since it didn't need any changes at all!
note: generic C++ command line apps can be compiled for different architectures with few changes if any. I'm working on a program to generate Towns for a RPG I play. Compiles and runs perfectly on OSX, Linux x86/PPC, and DOS/Windows. I may pull out the Sparc and the SGI at some point and compile for IRIX and Solaris as well. It requires no changes between architectures. This will change when I add the GUI.
--- end architectures, porting, and OSes 101 ---
