This readable introduction to iPhone application development pays attention to the details. Hockenberry discusses in considerable depth the mechanics of provisioning and submitting applications and of shepherding them through the approval process, matters that might quickly go out of date but that are, for now, tricky and not widely discussed.

It is difficult to imagine who this book envisions as its ideal reader. The opening chapters – about a third of the volume – introduce Objective C and the Cocoa Touch framework. Little prior knowledge is expected, not even rudimentary object-oriented programming, about which readers are urged to visit Wikipedia. Hockenberry’s breezy, casual style is not notably concise, and so these 100 pages strike me as far too elementary for an experienced programmer, too incomplete for a novice, and too cursory for an advanced student or a Java coder to grasp. One of Cocoa’s most distinctive features, delegation, gets two or three pages, and these pages don’t make any attempt to place delegates in the context of related Smalltalk, Java, or PowerPlant concepts. Questions any CS major would ask immediately – call by reference or value? ordered or labelled arguments? – go unanswered. Some valuable hints about the debugger are a promising start, but that topic is then abandoned and nothing much is said about profiling, leak detection, or exception management. The treatment of collections is equally sketchy, and while a few Cocoa objects are described a bit, whole catalogs of capability go unmentioned.

The treatment of design as a separate and superior activity to programming is, I think, misguided. The author is a designer and is writing, I think, for people who are not; he urges them to hire themselves a designer and then do what the designer says. Since the book clearly envisions individual developers or very small teams, this model may be unrealistic. Design and code are not separate things, and attempts to separate them are misguided. At times, the author’s contempt for the audience is palpable:

As a developer, you tend to look at problems from the implementation outward. A designer thinks about the final product and works inward toward how it’s constructed. When the logical left side of your brain encounters the designer’s artistic right side, great things can happen.

This is completely misguided – the flip side of the hard-nosed managerial outlook that always wants to control the creatives, suspecting that they only want a budget in order to buy cool clothes and then persuade each other to take them off. Everyone knows you’ve got to design the final product, just as everyone knows you’ve got to design a product that can be built. This preaching is wasted space, but since nobody is really going to be deceived by it, it’s harmless.

In any case, we hear a good deal of a designer’s thoughts on good coding practice and on the importance of employing designers, where I’d have preferred to hear more about graphic design.

The sample application developed here is an elaborate flashlight app. This might seem a placeholder, but it seems to me the choice is well considered: this is a book for people who want to write iOS applications which do almost no computation.