How hard is it to get a Cocoa application to run on Windows?

Question

In the wikipedia article on Cocoa it says:

There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.

Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:

Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.

I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:

• Which implementation is the most suitable for getting a cocoa app running on windows?
• How much work is it likely to take to get the app running under windows?
• How easy/hard is it to maintain a common code base for Mac and Windows?
• (any other considerations I've missed?)

Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.

Answer 1

There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.

Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.

Answer 2

Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows. Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.

It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.

Therefore, two possible solutions:

• Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
• Start a new GUI at all, no common code base. two choices here
  • Start a cross platform project with cross application framework such as Qt, or Java.
  • Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.

Answer 3

I am pretty sure Apple has major parts of Cocoa for Windows, but they wouldn't give those out for obvious reasons. This is the way they have made Safari and iTunes for Windows to work (this is only my guessing, though).

As to your actual issue, no chance. Like it or not the current OS X API is way better and more consistent in things like graphics. There is a group of applications that almost cannot be done for Windows, but can so for OS X. Guess it's the different focus of the two OS'es that causes this. Or that some people can and some never learn.

Answer 4

Don't forget:

1. “Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
2. Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
3. These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
4. Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
5. You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.

So, even with these Cocoa-like frameworks, the answer is: Hard.