Filed under: Open Source, Developer
Cocotron: bringing Cocoa to Windows
Of course that in principle still leaves open a bunch of practical difficulties. The guys over at Magnetism Studio (developer of FileMagnet for iPhone) have a great account of how they used Cocotron to port their Mac FileMagnet Uploader to Windows. Of course it wasn't as easy as pressing a button and having a Windows executable pop out of Xcode, but after suitable adjustments (particularly to get rid of Mac-specific code) it did make a Windows version possible. In any case, Cocotron seems poised to make cross-platform development a much less costly and time-consuming process for Mac developers.
Cocotron itself is a free download and released under the MIT license.
[via Daring Fireball]

![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)


Reader Comments (Page 1 of 1)
pumpkin said 3:48PM on 10-28-2008
It's spelled cocotron :)
Reply
Mat Lu said 4:00PM on 10-28-2008
Fixed!
samrolken said 3:57PM on 10-28-2008
How is this any different or better than GNUstep, which has been around longer and is more cross-platform?
I like seeing Cocoatron supporting more of the Core* frameworks needed by modern Mac OS X applications, even if it only works on Windows.
Having open-source versions of these libraries would mean more commercial and open-source software for Linux. The Linux desktop crowd is heavily involved with Wine(lib) and Mono to bring Windows apps to Linux. Why no similar effort for Mac OS X apps?
Reply
robb said 7:31PM on 10-28-2008
I think you answered your question. I've been watching GNUStep for a long time, but it doesn't seem to be making a lot of progress and their (stated) goal isn't to support Cocoa anyway, but rather the NextStep libraries. That's like Cocoa ten years ago.
Cocotron seems to be concentrating on supporting the API in such a way that you stand a fighting chance of porting a Cocoa app to another platform.
Why no Wine equivalent? Probably because the OS X world is so small compared to Windows. There just isn't the mass of software that a good API translation layer would give you.
Kai Cherry said 4:21AM on 10-29-2008
I hipped Glen 'n Ken to cocotron because it *isn't* GNUStep, they are Mac OS X devs and not Linux or Windows devs.
The purpose and goal of the cocotron is for OS X developers to port their OS X apps to Win32 using the OS X tools they use everyday...as long as you aren't "getting too fancy with the spices."
cocotron works :)
-K
RobK said 9:42PM on 10-28-2008
Well one of the goals of GNUStep is to implement Cocoa. See their home page where it states:
"GNUstep is based on and completely compatible with the OpenStep specification developed by NeXT (now Apple Computer Inc.) as well as implementing many extensions including Mac OS X/Cocoa."
You should also to the very recent FLOSS weekly episode where the developers of GNUStep are interviewed. Implementing Cocoa is one of their goals.
But I don't think one of the goals of GNUStep is to implement all the new Apple Frameworks like Core Graphics, Core Audio etc.
IMHO the main reason GNUStep has not gone 'mainstream" is its lack of support for native widgets. Applications created by GNUStep have an ugly GUI. I wonder what the GUI will look like with Cocotron. If they are also ugly, Cocotron will likely not be that popular.
In any event, I am not thrilled with Cocotron and its emphasis on bringing Mac apps to Windows. What about Linux. I also wonder whether it would be more beneficial if the developers of Cocotron worked to make GNUStep better. I hate when work on the SAME "idea" gets forked into multiple projects.
When I think about it, I guess GNUStep is the way to go after all.
Uwe said 5:27PM on 10-28-2008
Funny. We are currently successfully experimenting to bring our Windows based .NET client for our uploading service "Zeta Uploader" - http://www.zeta-uploader.com - to OS X with the help of the newly released Mono from Novell.
Still some minor glitches, but in principal it is working. Great stuff, too!
Reply
Level 5 said 10:34PM on 10-28-2008
I'm really hoping in a twisted way that this will make for a much better Windows version of iTunes to replace the atrocity Win users have to deal with now.
Reply
Vega said 6:44AM on 10-29-2008
Only problem being that iTunes is a Carbon, not a Cocoa application.
It still gives you these nice retro touches like the small b/w watch symbol mouse pointer whenever the app is busy...
John B. said 1:32AM on 10-29-2008
As developers become more reliant on Apple's Core services, I think this whole cross-platform developing dream is going to die out. It will just be too difficult to be worth it. In a few years, the browser will unify all the platforms anyway as it seems we're moving closer and closer to a sad web app future.
Reply
Level 5 said 6:40AM on 10-29-2008
For consumers, yes. For instance, my sister, grandparents, girlfriend, etc. etc. all the way down the line use their computers for only the following
- Web Browsing
- E-Mail (which can be done via web)
- Music (ripping, syncing with the PMP of their choice)
- MS Office or iWork
This is all. For most of them, a Mac Mini, eMachine or most any netbook would handle their every need.
For a professional like myself or most of TUAW's readers, this isn't the case, and not only do we need cross-platform applications, we need multiple operating systems if we can't get them! How many Intel Mac professional users either dual-boot with XP, use EFit for Leo/XP/Linux, or use Fusion or Parallels? Sadly we're in the minority.
Jash Sayani said 6:43AM on 10-29-2008
So just like CrossOver Mac, we could run OS X apps on Windows... Or do we need to compile those apps in a special compiler..?
Reply
Will Stokes said 7:00AM on 10-29-2008
Or you could just use Qt, or WxWidgets, or even XUL.
Reply
oZ said 10:37AM on 10-29-2008
None of which play well with Cocoa. None of which will allow you to create a 64 bit Mac application. None of which play well with extended Mac controls.
Qt is especially ugly, XUL is completely non compliant /and/ slow as a UI handler.
Kelmon said 7:49AM on 10-29-2008
I like the principals of cross-platform applications but am very much opposed to them in practice. The problem always tends to be the "lowest common denominator" issue whereby you can't implement something that isn't available on all platforms. Mac-specific features/functions are what make Mac applications special. Apple has provided a rich and wonderful suite of services and frameworks that should be taken advantage of to make the applications that we love. Firefox is a wonderful example of this. It's a great application but it just doesn't support those things that we expect on a Mac, such as storing your passwords in Keychain. I don't mind, however, having a cross-platform core (e.g. Gecko used in Camino) as long as it is then wrapped in a true native application.
Reply
NickMtl said 10:18AM on 10-29-2008
UI-wise, Cocotron is very different from GNUStep. On Window, a Cocotron program uses native Windows Widgets while a GNUStep program will use GDI (non-accelerated drawing) to draw it's own NextStep-style widgets.
There are many ways to port an application and the Cocotron approach provides native Windows look and feel using Cocoa-compatible code.
Personally, I think that no matter what you do, you still have to learn the Windows and Cocoa APIs to get the best UI. Cocotron will save you time if you are writing an app that uses standard Cocoa widgets. Apps that use custom widgets (Delicious Library, Screenflow, etc.) will require knowing both APIs by heart.
BTW, iTune is "tour de force" because it does a lot of CoreAnimation/CoreImage stuff without Cocoa.
- Nick -
Reply
Greg said 11:14AM on 10-29-2008
Apple needs to push for projects like this, it's the best way to get people developing for the Mac OS platform.
http://gregstechblog.blogspot.com
Reply
NickMtl said 11:50AM on 10-30-2008
Greg,
The best thing Apple ever did to bring in more Mac developers was making Cocoa Touch *the* API for developing for the iPhone. I don't know a single developer who doesn't want to learn Objective-C now.
Apple is better focusing on advancing the state of Cocoa/Cocoa Touch than trying to be compatible with whatever Microsoft is doing. Microsoft is sure as hell not doing it.
- Nick -
guy@shaviv.org said 9:29AM on 10-30-2008
I wonder if someone will take a spin on cocotron and try to use it to port cocoa touch from the iphone to android. Now that would be a killer...
Reply
NickMtl said 11:55AM on 10-30-2008
...Except that Android uses Java, which syntax stands somewhere between C++ and Obective-C. This would require a new Cocotron-like project to convert Objective-C to Java and then port Cocoa.
There's a better chance for Qt pull this off since their approach is to code with teir own API while they do the translation to various systems.
- Nick -
www.songhacker.com