It comes up a lot on the mailing lists, so I thought I'd write a little piece on the best approach to port an application from another platform (like Windows or a Linux) to the Macintosh. I won't go into much detail, but outline the general way and the most common pitfalls.

Do not use Carbon or Cocoa-Java

Apple has, for historical and political reasons, provided several different programming APIs. One of them is Carbon, which is a C-based API that many cross-platform developers want to use because it's more like MFC and other frameworks they already know. At this year's Worldwide Developers' Conference (WWDC) a long-running fight inside Apple finally came to a close, and Apple effectively announced they were killing Carbon. There is still some old documentation up on Apple's developer web site that says otherwise, but don't let that fool you.

If you are just getting started programming the Mac, use Cocoa to write your end-user application with a graphical user interface. A few of Carbon's prettiest cherries have been "rescued", but look for a Cocoa solution first. In particular, any GUI code written in Carbon (control manager, HIToolbox) is not a good investment of your time at this point.

There are also a number of bridges that allow you to use Cocoa with other languages. They're a great technology, but most of them are fairly new, and you will face issues. Also, since they map Cocoa/Objective C concepts to another language, there will always be something lost in the translation. You will have to know how Objective C does things to understand these oddities. So why not go for Objective C in the first place, where Apple spends its main effort? All the documentation is for Objective C, too.

Don't even try to use the Cocoa-Java bridge. Apple has already made clear it will see no more development.

You can use C++ with Cocoa

Many people think they will have to rewrite their application in Objective C to make it use Cocoa. That's not true. Apple has taken great care to make it possible to mix Objective C and C++ in a project. The key here is the "Objective C++ compiler", which is part of Xcode. You will still have to write the Mac-specific parts in Objective C, but the rest of your application can stay in C++ and can be easily shared with your Windows or Linux developers.

Don't be afraid of Objective C, Objective C is essentially C: It has a few simple extensions to the language, which are quickly learned. These extensions may seem like a fancy way of duplicating C++ just for the heck of it, but actually, they're completely different. Objective C essentially is a very elegant and simple way of wrapping the features of COM or CORBA, Qt's preprocessor, and many other neat things that are done separately on many other platforms. Moreover, the Cocoa frameworks have been designed with Objective C's particular strengths and weaknesses in mind. Porting Cocoa to C++ would result in such an ugly mess of nested template code you wouldn't want to do it.

There is no MFC on the Mac

If you've never before ported an application to another platform (and I don't count Windows CE as a different platform than desktop Win32), don't think you can just look at each function and map it to "the Mac equivalent". Each platform has been designed at a different time, and thus incorporated the currently accepted programming practices. To create a usable application, you will have to do things the way they are intended to be done on a particular platform. For the Mac, this means making sure your application is split up into a model-, a view- and a controller-layer, according to the MVC design pattern. This is not a Mac-ism: It is a standard design pattern listed in the GOF book, and commonly accepted as the best way to structure a cross-platform application.

If you find that something seems impossibly hard to do in Cocoa, chances are that you're doing something that you're either not supposed to be doing, or that you are supposed to be doing in a completely different way. The benefit of this is that you will find yourself being boosted by the framework in ways you didn't think possible, instead of finding yourself fighting it every step of the way.

Cross-platform frameworks

There are frameworks that have been designed to sit on top of a platform's native frameworks and hide away the details, for example Qt, Quaqua or wxWidgets. In short: If you aren't porting a game, where all user interface is custom and you're full screen without a menu bar anyway, don't do it. Most of these frameworks don't really behave like Mac users expect them to. Menus look subtly wrong, don't scroll and don't indicate overflows correctly. Keyboard shortcuts don't work as expected. Pushbuttons are used with the wrong style, disabled icons look black-and-white instead of faded out...

The long story: There are ways to make them work, but in the end, you can't really share much code regarding UI behaviour, so you might as well go fully native on each platform. Most cross-platform toolkits get the look and the basic behaviour right, but at some point fall into an uncanny valley where they frustrate Mac users. However, of course you can wrap the Mac's drawing APIs to share code for some of your custom views and displays.

Resources for Mac programmers

I already mentioned Apple's developer web site above, which contains a lot of resources. In particular, you can find documentation, sample code etc. there. A lot of this stuff gets automatically installed on your Mac when you install the Xcode tools (in /Developer/Examples you'll get a lot of the sample code, though not all of it, and the documentation can be found in Xcode's Help menu, and it will automatically download the newest version periodically).

There is a whole section on porting from other platforms on Appe's developer web site. Just keep in mind that anything suggesting Carbon is probably outdated.

Apple also runs a bunch of mailing lists for developers. These are mainly a place to meet other developers, and are not an official support channel. Nonetheless, make sure you post on the right list: Many people post Cocoa questions on the Objective-C mailing list, which is mainly about the language itself and the language standard, and rarely the one you want to post on as a Mac developer.

Finally, if you find issues, use Apple's bug reporter, also known as RADAR. You need a free "ADC Online" account, but that's just so you don't have to enter your info twice. You can use the same account in Apple's store and iTunes, BTW. Do not post your bug reports to the mailing lists. You can ask if someone has found a workaround, but the mailing lists aren't an official bug report channel, and unless you bother filing a bug, Apple will just think you're venting and it's not important enough, and will focus on the bugs somebody actually filed and thus indicated they matter to them.