A developer's-eye view of Leopard, part II

Apple has always been pulled in different directions by factions of its user and developer communities. Set-in-their-ways Mac developers whose experience predates OS X have a predilection for the C language, legacy Carbon function libraries, and esoteric development tools in the tradition of Macintosh Programmer's Workshop and CodeWarrior. Meanwhile, Apple's UNIX developers and emigrants from Linux go for C and C++ for native code and Python, Perl, and Ruby for dynamic apps, and demand a command line toolset and source code portability so that they can assemble the tools they prefer. And then there are those doing Java client development and programmers writing AppleScript programs who bring their own expectations to tools.

Click for larger view.

But the most influential branch of the Mac developer family tree is that which wholeheartedly buys into Steve Jobs' vision of a Mac platform melded with Unix and the pervasively object-oriented NeXT environment and toolset. These developers use Objective-C, a native compiled language with dynamic properties; Cocoa, the core framework that is the Mac platform's object-oriented API; and Apple's Xcode IDE (integrated development environment). They write the vast majority of commercial Mac software, both inside and outside Apple.

With Leopard, Apple makes its most concerted run yet at drawing developers into creating applications that exploit the full Mac platform, starting with Xcode 3.0, a dramatic set of enhancements to Apple's free and official IDE. Xcode will be publicly released with Leopard, and it is available now to paid members of Apple Developer Connection.

Polishing Xcode 3.0

IDE editors are often burdened by new features, so I was wary when I learned that Xcode 3.0 was getting an editor overhaul. However, the changes Apple made are aimed at consolidation, not added complexity, and the new editor puts out a very comfortable welcome mat for developers who aren't big fans of IDEs with crowded toolbars and jarring edit/build/debug modes.

Click for larger view.

Recognizing that a great many Unix coders live in their editors, Apple decided to bake a lot of traditional IDE functionality into the editor itself. For example, after building a project, the developer can see errors and warnings in their code without opening a build messages window.

Inline balloons point to the locations of errors. During debugging, the editor window becomes the interface for exploring symbols at run-time and for the setting and clearing of simple and conditional breakpoints. And during the all-important editing process itself, Xcode 3.0 aids without interfering thanks to the integrated Code Sense and Research Assistant.