Xcode

And Project Builder before that.

The best development environment to ever be belched up by the Beast was Microsoft C 11.0 with Visual Studio 5.0. There's never been anything better; everything else has been worse.

The only development environment associated with NextStep through the years has been Project Builder. Project Builder has been the mainstay of the NextStep platform throughout that platform's history.

For the world of event-driven programming, documentation is essential. Gone are the days when the developer opened the manual twice a year at most, because there were only twenty system calls to worry about.

Today's APIs contain thousands of functions, and the API of Cocoa is estimated to be four times the size of that of Windows. You don't have to memorise the exact APIs - only know how the system works, remember the names of the functions, the classes, and the methods, and then your documentation should take you from there.

The Microsoft documentation system worked well. Others, such as Premia's CodeWright, worked better, until Microsoft broke them, but that's not pertinent here. Microsoft's system was, if not brilliant, more than enough to get by.

Microsoft could never make up their mind whether their documentation would reside inside the IDE or outside it. Prior to Visual Studio 5.0, it was outside - and it hurt. With 5.0 it was brought inside - and it worked well. Starting with the next version it was out again, and all the pain returned.

This is how the Microsoft documentation system works, whether or not the window for it is inside the IDE:

You place your caret (your edit cursor) inside a word and hit F1. If your word matches something exactly, you go immediately to that page. If it's close to one or more matches, a dialog comes up, asking you to choose.

And even though the API is case-sensitive, you don't have to be case-sensitive here: a single missed capital or lower case letter and you'd be lost.

Microsoft puts huge index files on the hard drive, and then lets the developer opt to have the rest of the documentation either on the hard drive too (you need a big hard drive) or let it remain on the CD, where it's still eminently accessible.

You can start up Visual Studio from scratch, open a text window, type in a single word or a portion thereof, hit F1, and immediately get to the documentation you want.

The Project Builder documentation system has never been good. Project Builder has no indexes for its documentation on disk, but creates them for each and every project opened. These are huge files, and creating them takes time - about fifteen seconds of spinning pizza time on a 500 MHz Mac.

The punch line here is that none of this documentation is accessible until Project Builder has created the indexes, and Project Builder does not create the indexes until you build the project. Paradoxically, you have to succeed (at least somewhat) with your project before you can consult the documentation to see what you've done wrong.

The Project Builder documentation search engine is case sensitive. Get one letter in the wrong case and the program will act dead. Take, for example, the commonly used NSAutoreleasePool class. Is it NSAutoreleasePool, or is it NSAutoReleasePool? Only one of these will get you joy.

And you can't put your caret in a word and click a key either: you have to select the entire word and then 'option-click'.

Which, if you're lucky, will unleash the Project Builder documentation engine.

All the Project Builder documentation is in HTML, and if you dragged any one of Project Builder's files to your favourite browser, it would load and render immediately. But not so with Project Builder. We're back to that spinning pizza again.

Worse still, Project Builder keeps all open HTML pages in its viewing window, and sees somehow to forget how to render them when they're not visible, so when you close a window in front of one of these pages - you get the spinning pizza again.

And it's completely possible to fool Project Builder to never build these indexes. This is not a feature: it's a bug, and a bad bug, that's been with Project Builder for ages.

Sometimes it's as if at random, but you can generally fool the program by hitting the Run button, and then when the build gets underway, hitting the Stop button and then the Run button again.

Project Builder will forget it was supposed to create the indexes and just go on and build the program.

Or you can hit the shortcut for 'build' as soon as you see Project Builder's menu on screen, and here again it will hop over the indexes as if it never knew it was supposed to create them.

Other times the program is more ornery, and in extreme cases you have to reboot your computer to get Project Builder to create the indexes so you can see your documentation.

So things haven't been all that great for the Cocoa developer, and when compared to the Beast, it gets a bit embarrassing.

Enter Xcode. Xcode is the successor to NextStep's classic Project Builder. Its window and ergonomics look nothing as good as Project Builder, but its functionality and speed are supposed to be better.

When first loading a project with Xcode, the program spins seemingly out of control, creating indexes for the specified source files. This can take a few seconds - but you don't get a spinning pizza, and when this is done, the actual compile and link will literally not take more than a few seconds.

Xcode is huge on disk - just having it around, with all its associated files, slows a disk down considerably. And it takes time to see how good the documentation system really is. And it's noticeable that Xcode picks up small errors in code that Project Builder never saw. And it's possible that Xcode is a bit of a nit-picker when it comes to syntax.

Whatever. Developers shouldn't get a spinning pizza when compiling an ordinary program. They should have access to their documentation at all times. And they should have a streamlined system for invoking their documentation.

Project Builder did not have that, despite being the IDE for the clearly superior platform; Xcode does.

A Closer Look

Xcode always comes up in the same rinky-dink position, with the same screen width and height.

The popup in the upper left hand corner is too narrow to display the project name, and several of the standard nodes in the outline on the left are likewise cropped.

With the PLIST mania hitting this company, you'd think they'd save screen coordinates, to make the program a little more pleasant to work with, but no.

The first thing Xcode will do when loading a project (after asking to update it from the 'Project Builder format', which Xcode calls 'an earlier version of Xcode') is to create the indexes.

There is no sign of this flotsam and jetsam on disk, but virtual memory gets sucked up pretty quickly, leading one to hazard a guess as to its location.

Compiles are almost instantaneous.

Xcode has a very welcome feature in that it remembers exactly where each file was last edited, so if the file is opened again, you're right where you want to be.

Actually this would appear relatively easy to implement, but that's not the point; the point is it's there.

Using documentation is faster than with Project Builder, but not by a lot. Both Project Builder and Xcode stand in shame next to Andy Lee's incomparable AppKiDo (which Apple succeeded in breaking with Panther - get version 0.891 right away).

Editing is 'OK', but Xcode doesn't like to list header files, and even if Xcode doesn't realise it, they need to be edited too.

And there is no multiple choice when it comes to window layout, as there is in Project Builder: Xcode just strews your windows all over the place.

It's impossible to turn Xcode down, when it works faster than Project Builder, and when its executables are smaller (although this should be credited to gcc 3.3), but the UI is still very shaky and needs a lot of work.