Update: Brian Reiter has written a detailed analysis of how to use Xcode 4.2 while reading 4.0 documentation that references Window-based iOS applications.

Update 2: The Pragmatic Programmers released a series of introductory videos for Xcode 4 in March. These are still pre-ARC, but they should at least help get users familiar with the changes to Xcode since v3.

I’ve been a UNIX systems administrator for, well, let’s just say over a decade and leave it at that. I’ve been programming in C for even longer.

Still, getting started with Mac and iOS development was like quitting smoking: it’s so easy to do so, I do it all the time!

So over the years I accumulated many books, mostly used, some good, some crap. I’m not great at getting over the initial hurdles in learning a new set of skills, so I hoped the books would help me get serious about it.

Last week I decided to use my vacation time and get serious this time. Because, y’know, deciding to get serious always works, right? This time it did, more or less, but only after I stumbled across the Holy Grail: a book that covered Xcode 4.2 and ARC (Automatic Reference Counting). (For the untutored, these technologies were just released within the last couple of months.)

All those old, dusty books I’d accumulated covered Xcode 3 at best, which is quite significantly different from 4, and didn’t know of the existence of ARC, and I expect that any serious Objective-C developer would tell you that memory management is one of the most daunting obstacles to mastering the language.

So I’ll certainly plug the great book that I found, but more importantly, I’d like to share a dirty little secret with other beginning developers who are similarly stuck without any idea what to do about memory management now that Apple has introduced a new system and practically no books are available yet that cover it: you don’t have to understand ARC to use it while experimenting and learning. You just have to remove all the memory management that your books show in their sample code.

Don't get me started on my Ruby, Perl, OO, and database books

Before I go any further, the plug: Aaron Hillegass of Big Nerd Ranch fame was ahead of the curve and published his new book, Objective-C Programming: The Big Nerd Ranch Guide this November; so far as I can tell, it’s the only book out there currently which covers the latest and greatest tools by Apple. Fortunately, not only is he fast, he’s very, very good at this. He’s been doing NeXTSTEP development since long before many of us had heard of Objective-C.

If you can, just grab a copy and get to it. It covers the C underpinnings of Objective-C up front, so half of the content wasn’t necessary for me, but the jump start was well worth the price.

Alternatively, wait until the next edition of the Big Nerd Ranch Mac and iOS books: they’ll cover the same topics in much more detail. This book just covers the essentials.

So if you don’t grab Aaron’s latest book, how do you deal with memory management and Xcode 4?

Well, as I’ve already stated, you can largely ignore memory management, at least until you get closer to needing to do real work. Rules for code you want to use from books that predate ARC:

  • If you see invocations of dealloc, release, retain, retainCount, or autorelease, leave that code out entirely. Feel free to override dealloc in your classes as instructed, but don’t call dealloc on other objects (or on super).
  • Don’t use NSAutoreleasePool. Xcode 4.2 will generate @autoreleasepool { } in your main.m file: make sure all your code is initiated from that block, and you’ll be fine.
  • You should be able to leave @property and @synthesize statements as is.
    • This is the guideline I’m least comfortable asserting is absolutely true, but it certainly seems to be true from reviewing Apple’s Transitioning to ARC Release Notes.

Of course, the above rules go out the window if you’re not using Xcode 4.2 (or higher), or if you uncheck the Use Automatic Reference Counting checkbox. You can always choose to continue performing manual reference counting using the old retain/release mechanisms, but you really shouldn’t. Let the compiler do the hard work.

Will following those rules mean you’re doing it right? No, not really: you really do need to learn more about ARC, because you’re creating memory leaks all over the place otherwise. But for now, feel free to let sleeping dogs lie.

As far as using Xcode 4 goes, you’ll definitely run into preferences that have moved (or been removed), and of course Interface Builder is now embedded in the tool itself, but overall you can do the necessary mental translations with a little poking around. There’s a new mechanism for connecting GUI objects to IBAction and IBOutlet code, but you can ignore it and continue to do it the old way.

A few less-obvious features that you’ll need to know about:

  • When working with the new integrated GUI builder, you’ll want to enable the assistant editor to see the assembly frame and your code side by side. Look for the “tux” icon (and I don’t mean Tux).
  • Because the project navigator isn’t always visible, practice using the breadcrumb and forward/backward arrows above each editing frame to navigate between files.
  • When you’re editing a .xib file in the GUI builder, if you don’t see the object tree and placeholders (like File’s Owner), click the button that looks like the iTunes Play button (or the Xcode Run button) in the lower left-hand corner of the builder frame.

Using out of date documentation just makes this more of an adventure, so don’t be daunted. First world problems and all that.

Best of luck!

P.S. If you do purchase any of Aaron’s books, and I definitely recommend that you do so, register with the Big Nerd Ranch forums so you can get assistance and help others as well. I’m doing a fair bit of damage on the forum dedicated to Objective-C Programming under the username “macintux”, so feel free to come correct me when I screw up.