Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Since the Apple OS-X operating system is a UNIX derivative (BSD), and the underlying (Intel) Mac architecture is the same, why isn't it very straightforward to get Apple-specific applications running on Linux?

share|improve this question
add comment

4 Answers 4

up vote 20 down vote accepted

OS X is actually (mostly) the proprietary graphical shell on top of BSD. To create an OS X GUI application, one has to follow the api which Apple has exposed, and hence this is not cross platform and not easily portable.
That's why most libraries are easily ported (actually most are developed on Linux) to Linux but not their graphical shells.

On a side note: There are frameworks out there with which you can create cross platform GUI applications. Qt comes to mind. But the fact that those frameworks are cross platform also makes the applications created with them less user friendly on a specific platform than a "native" GUI application. Those frameworks tend to make everything look generic across platforms, which in the case of Apple is bad, because Apple created a very specific user experience which not easily "fits" into other platforms.

Edit (to incorporate the comments in the answer - thanks @Nick, @kbisset and @John):
A solution would be to port the whole OS X graphical shell (the closed source Cocoa/Core libraries - which is what makes OS X truly unique) to Linux. And technically, Apple could do that quite easy, but they have no reason to, as their entire business model is the uniqueness of their entire platform - hardware and software.
It's CONCEIVABLE that someone could attempt to clone the libraries, but that would take man-decades to do, and probably would never be right due to all the undocumented calls which would have to be replicated.

share|improve this answer
    
Why can't the proprietary graphical shell be relatively easily ported to Linux if it is running on BSD? I understood the issue when the underlying architecture was different, but now the underlying architecture is just Intel then why isn't the graphical shell just one more library? –  Nick Pierpoint Aug 14 '09 at 12:36
8  
Two reasons. First, it is more that just a graphical shell. It is an entire layer above Unix, that Apple has been working on for years. Second, the code is not available. So it would need to be rewritten from scratch. Apple could probably do it in a short amount of time, but there is not reason for them to. –  KeithB Aug 14 '09 at 12:44
    
So... for Apple at least there isn't really a technical issue - they could migrate OS-X to run on Linux relatively easily as they already have it running on UNIX. Obviously a big deal for everyone else as the code is closed source and there's no fully-published API. Is that a fair summary? –  Nick Pierpoint Aug 14 '09 at 13:36
2  
Nick: Essentially, yes. Apple has no interest in moving OSX to a Linux platform; why should they when they've invested so much in their open source Darwin platform (the BSD layer) and their closed source Cocoa/Core* libraries (which is what makes OSX truly unique). Their entire business model is the uniqueness of their entire platform -- hardware and software. It's CONCEIVABLE that someone could attempt to clone the libraries, but that would take man-decades to do, and probably would never be right due to all the undocumented calls which would have to be replicated. And to what end? –  John Rudy Aug 14 '09 at 13:45
4  
GNUStep is an open source implementation of many of the core libraries that are now in OS X, however Apple's added many since then so porting still isn't that easy: wiki.gnustep.org/index.php/Cocoa –  TRS-80 Aug 14 '09 at 15:07
add comment

By Apple-specific applications do you mean GUI apps? Once you move above the command line there are Apple specific APIs for everything (graphics, sound etc.) that are not supported on Linux hence you cannot easily port applications.

share|improve this answer
add comment

The graphical layer is not the same, at all. OS X uses a proprietary graphical framework, linux uses X (X11/X.org)

Almost all native OS X applications use frameworks such as Cocoa, CoreAnimation and so on, which are only available on OS X.

For example, say you have an application which stores a password for the user - on OS X, this would use its Keychain system and relevant APIs. If you were to port this to Linux, there is no direct equivalent, so you would have to re-impliment this entire feature. That is a tiny feature, and would require a large rewrite.

If you write your application using a cross-platform GUI library like GTK, Qt or wxWidgets, and porting will be much easier (or, "possible") - but the operating systems are still very different in terms of UI (for example, OS X uses a separated menu bar, whereas Linux tends to have its menu bar for each window)

One of the best cross-platform ports I've seen is Transmission, which implements its main functionality as a library (which contains as little platform-specific code as possible), then creating native GUIs for each platforms, separately. This means each port shares a lot of code, but all have good, native interfaces (rather than a single interface which fits nicely on Linux, but is out of place on OS X, or vice versa)

There is a project called Cocotron which "aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation" which would potentially make porting much easier, but there seems to be very little activity of late (the last blog-post was in December 2008)

share|improve this answer
add comment

Because most applications depend on a lot more than the processor and underlying architecture of the machine they're running on. They also depend on user interface toolkits and other platform-specific libraries.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.