Xcode is the latest iteration of
Apple's
IDE. It replaces
Project Builder. It was first demoed at the 2003 Apple Developers' conference (
WWDC), where pre-release versions for both
Jaguar and
Panther were demoed and given to attendees. The final version is only available for Panther.
The old
Like its predecessor, Xcode has strong ties with Interface Builder; one can create instances of classes in IB and have the relevant source files generated automatically and so on. Like Project Builder, Xcode works with gcc and gdb to do its actual work (although Xcode comes with a newer version of gcc) (except of course if you are writing in Java), and allows you to write programs in C, C++, Objective-C and Java.
And the new
A major feature is Xcode's distributed builds system. This allows one to spread compile jobs among machines on a local network. It is ridiculously easy to setup, one only has a checkbox to tick to enable builds to be sent to other computers and another to allow the computer to be used by others. Xcode takes care of the rest. Other copies of Xcode with the option enabled are found via Rendezvous, no faffing about with ip addresses needed. Optionally one can specify the computers that are used for distributed builds, and the nice level at which jobs from other computers will run. If any of the remote computers are dual processors then they appear as 2 separate computers. The potential benefits are obvious, although do not apply to all situations. For example, for a very small project with few files the extra overhead and time involved outweigh the benefits. Xcode provides a quick an easy way to get this all working, but the grunt of the work is actually done by the open source tool distcc.
Another much touted addition is the ZeroLink system. In a nutshell this means that the linking phase is somehow magicked away (executables generated this way will only run on the machine that produced them) saving precious seconds that do eventually add up. At the WWDC presentation someone asked if the debugging phase could be eliminated too, but apparently that's still here to stay.
In the same time-saving line of thought, Xcode allows one to modify source files and for the changes to take effect immediately, without relaunching (Apple calls this "Fix and Continue"). Although other IDEs have had this feature for some time (for example Microsoft's Visual Studio, neither Project Builder nor CodeWarrior have it.
Lastly, Xcode introduces an SDK system which allows one to target a version of Mac OS X other than the one hosting the development system. In a nutshell folders are created in /Developer/SDKs which contain the directories relevant for development (i.e. /usr/lib, /usr/include and portions of /System). While building, the appropriate SDK folder is used when searching for headers or libraries. CodeWarrior can also use this system (by setting the volume root for the project to the appropriate SDK folder).
Playing nice with CodeWarrior
Although once long ago several companies made development environments for the Macintosh, today it boils down to Apple's suite and CodeWarrior (developed by Metrowerks). Each side has its fans, it is usually reckoned that CodeWarrior compiles faster and produces better code (although gcc is catching up), but Xcode integrates better with Interface Builder, can generate code optimised for the G5, was until CodeWarrior Pro 9 necessary for building kexts and has an awesome documentation look-up feature. Xcode is free, whereas CodeWarrior starts at $400 and with OS X being very much a moving target recently the yearly updates have been pretty much compulsory. While the price may be a show stopper for the enthusiast, it is not an enormous amount to pay for one's main work tool (especially when compared to Photoshop, Final Cut Pro, Matlab ...). Another significant factor for the potential "switcher" is that many developers may have a large number of projects created by CodeWarrior, and moving them across to Xcode could be quite a hassle. Here however, Xcode scores points, as thanks to some Applescript magic it can import CodeWarrior projects. It doesn't always work 100%, and the 2 compilers can behave differently, but it's definitely a step in the right direction.
Xcode may have its flaws (personally I find the interface clunky, but then I'm a long time CodeWarrior user), but it is definitely going in the right direction. It is certainly encouraging to see Apple put large amounts of effort into its tools (Apple also has a large team working on gcc) and catching up with (and in certain areas, overtaking) CodeWarrior.
Roughly 6 months after I first wrote this, I went to the WWDC 2004, where Xcode 1.5 and 2.0 were demoed and given to attendees. Forget all I said about the flaws of Xcode. 2.0 has several different "workspaces", which enable it to work more like other IDEs, in particular CodeWarrior. CodeWarrior hasn't changed a lot in recent years, but Xcode is surging ahead.
The compiler is getting better and better, debugger support is also improving vastly. It is excruciatingly easy to have custom data formatters, for example if one is viewing an opaque data type, entering "foo is {$VAR foo}" will cause the debugger to display the result of calling the foo method of the viewed object. Xcode of course remembers all of your formatters. I could go on and on about the great features of Xcode but suffice it to say that as far as I am concerned it is now the number 1 IDE for Mac OS X (admittedly I am not a C++ programmer and I am told that Xcode's C++ debugging is iffy).
http://developer.apple.com/tools/xcode/