Over the past three years, I’ve been programming mostly Flex and Java, with few other languages sprinkled on top (Javascript, PHP, Erlang). Recently, I’ve made the transition to doing exclusively iOS development and slinging Objective-C all day long (I’ve even taken over the Boulder iOS meetup). Here’s my take on Objective-C as a programming language, along with a snapshot of life from the trenches of a professional Objective-C developer.

The Good

Using square brackets to call methods is a little wack, but you’ll get over that in about 20 minutes. Honestly, the syntax is a little bumpy for a day or two, tops…after that, there’s a lot to like about Objective-C.


Objective-C is a very dynamic language, not quite at the level of Ruby, but it’s pretty dang close. You’ve got the id data type when you need dynamic typing, but you can also use static typing for some compiler love. You’ve got Categories for extending classes. And you’ve got full-on runtime meta-programming that allows you to create new classes at runtime, create new methods on existing classes at runtime, and swizzle methods at runtime. Objective-C’s also got message forwarding (just a more verbose method_missing if you know Ruby) for handling unknown method calls at runtime.

Not to shabby. With the exception of the id data type and using @selector everywhere, I seldom use the dynamic features. Since dynamism is completely unobtrusive in Objective-C, I don’t have to worry about it, but I know it’s there if I need it. Basically, it’s a big warm fuzzy.


Closures are pretty sweet in any language, but the Objective-C implementation, called Blocks, is better than most. The addition of Blocks means that functions are now first class objects in the runtime, meaning they can be created, saved, executed, copied, or passed to other functions at runtime. Blocks are directly supported by the base Objective-C classes and in some iOS APIs too (examples include NSArray‘s enumerateObjectsUsingBlock: or UIView‘s animateWithDuration:animations:).

But the coolest thing you can do with Blocks is to use them to create chucks of work that can be executed in parallel. The hard part is breaking a job out into independent chunks of work, but once you have that implementation is trivial in Objective-C. You just use NSArray‘s enumerateObjectsWithOptions:usingBlock: with the NSEnumerationConcurrent option to do work on the chunks concurrently, like this:

[myArray enumerateObjectsWithOptions:NSEnumerationConcurrent
                          usingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    //do chunk of work on obj

And if you really need to some concurrent kung-fu, Objective-C provides NSOperationQueue along with Grand Central Dispatch to really kick some ass. If you can forgive the Charlie Sheen reference, I like to think of Blocks as the tiger blood of concurrent programming. Winners use Blocks.

Good references: Drew McCormack’s 10 Uses for Blocks; Make Ash’s part 1 and part 2; Mike Clark’s basic blocks and advanced blocks.


UIAutomation is not much to look at. And it actually starts looking pretty bad as a functional testing tool when compared to Selenium or FlexMonkey or FoneMonkey. But it’s there, it works, it’s full-baked, and it appears to be Apple’s way forward. Automation is so powerful, particularly on big apps developed by big teams. UIAutomation’s integration with Instruments is it’s achilles heel right now, so hopefully Apple brings out an update that is happily command-line-runnable soon. Until then, it’s still super awesome to have an automation tool.

The Bad

There’s a lot of not-good-yet stuff in Objective-C development. For the most part, I’m optimistic that much of stuff will get fixed over time.

The Community

With the exception of Stack Overflow (and that’s a major exception because it’s just awesome), the Objective-C community is just getting started, for the obvious reason that it’s so new on the radar. The number of books, bloggers, libraries, frameworks, et cetera is just not there yet. From my own personal experience, I find it very analogous to the Ruby community circa Rails 1.0. A few, well known, super dev bloggers, a few good books, a few widely used frameworks (Three20, cocos2d), and a lot of eager wannabes (like me then with ruby, and me now with iOS) [Note to self: Am I just a career wannabe? Discuss.] But look at ruby now…the community got so big that they are now experiencing contraction (the Rails/Merb merge is the big example).

I’m always googling while writing code, but with Objective-C I often find myself coming up empty. A lot of first time never-been-done-before stuff is going on in Objective-C and iOS, which is certainly exciting, but not without its challenges to day-to-day development. I don’t doubt things will improve in the future, but right now I find the community lacking.


Much like the community, the tool chain is just getting started. There’s a ton of Makefiles out there, along with piles of bash scripts. And I swear people are still jumping to the command line in gdb. Of course, this is all the C/C++ heritage, but come on people! Who uses this stuff and actually likes it? It’s not like Ant and Maven were forged by the gods, but Makefiles? Save me.

And what’s up with Other Linker Flags? This whole thing to totally idiotic. Why can’t we invent some new packaging format that knows it must be added with -lstdc++ or -ObjC? Super lame.

I’ve been getting pretty dirty with Rake, Ivy, and Sonatype’s Nexus to bring some serenity to the situation. Definitely a work in progress, but it’s getting there.

The Ugly

The ugly parts are rather unfortunate, especially given the beauty of Apple’s hardware. It’s also a little hard for non-programmers to see, because the user-facing bits of the software can be made so beautiful too. But I would certainly argue that the beauty of the UI is done despite of some evil ugly warts in the code. Maybe I’m being a little too Zen, or maybe I’m a hopeless romantic, or maybe I’m just being naive, but it sure would be great if inner beauty at the code level eventually lead to beauty at the surface.

Memory Management

Everyone loves to hate on Objective-C’s lack of garbage collection on iOS. I’m on the bandwagon on this one too, because memory management just plain sucks. The constant dance of retain, release, and autorelease is unrelenting, and so hateful! For an alternate data point, with the release of Gingerbread, Android has a new concurrent garbage collector. Come on Apple, give us some love.

Writing leak free code on the first pass is basically impossible, especially on a big app. So now I’ve had to expand my toolbox to include tools like Clang and Leaks and UIAutomation to find and fix all my memory bugs. It’s just ugly plain and simple.


By far the ugliest part of Objective-C is the Xcode IDE. By far! I’ve used the question, "Tell me about some of the warts of iOS development?", a couple of times in recent interviews. It turns out to be a great differentiator between professional developers that are familiar with team development and professional tools and people that know how to code. All the candidates I’ve asked can easily point to memory management as one of the ugly parts, but almost no one says the Xcode.

If you’ve ever used a real IDE (Eclipse, IntelliJ, Visual Studio), then you are probably familiar with various code-level helpers like generate getters/setters, rename class, automatic code formatting on save, just to give a few examples. Xcode doesn’t generate getters or setters from ivars. Nor does it do class rename, only file rename, how pathetic is that? It doesn’t do any intelligent code formatting either on save or otherwise. And these are just my code-level gripes…

You are also probably familiar with the various development tooling integrations that put the I in Integrated Development Environment. Things like using source control, viewing graphical diffs, running unit tests, running scripts, debugging with variable watches, writing tickets, submitting bug reports, doing code reviews, and more. Nope, Xcode doesn’t do any of those things either.

In the end, I give Xcode a "syntax highlighter plus" rating, which puts it just above vanilla Vim but below a super tricked out Vim setup.


I’m an iOS developer by choice, but just because I’m splashing around in the mud like a happy pig right now doesn’t mean I like being dirty all the time. [For more about "the mud", read my rablings here.] The ugly bits do have one positive effect: my value (and hence my salary) are improved. By setting the bar high, either intentionally or unintentionally, Apple is effectively keeping the riffraff out.

Hopefully, GC will arrive once all the iOS hardware gets multiple cores. Or maybe ARC might be decent. And JetBrains CIDR (Objective-C IDE from the makers of IntelliJ) will turn out to be awesome. Onward and upward.

Update 2013-04-17: Yes, ARC is pretty sweet. Yes, JetBrains AppCode is the real deal. And yes, Xcode is still an ugly wart on iOS development.


I always believe in the right tool for the job, so I’m not an Interface Builder hater per se, but I find it a little pathetic how infrequently IB is the right tool for the job. In addition, I’ve found IB to be at its worst whenever the development team is bigger than one. Don’t panic, just go nibless.

It’s very easy to go completely nibless (and a little stylish in my opinion) and eschew Interface Builder altogether. For all you Flexers out there, this is the moral equivalent of eschewing Flash Builder’s Design View. Honestly, who really uses Design View to build an app beside Adobe evangelists doing 30 minute demos?

A Completely Nibless App

Here’s how you can build a completely nibless app in five simple steps. First, you’ll want to start with a fresh Window-based Application in Xcode. Then follow these steps:

  1. Remove MainWindow from your app’s Info.plist
  2. Delete all .xib files
  3. Edit AppDelegate.h remove all the IBOutlet keywords
  4. Edit main.m, import AppDelegate.h, and set the UIApplicationMain‘s 4th parameter to @"AppDelegate"
  5. Edit AppDelegate.m to instantiate the main UIWindow in code

Here’s what main.m should look like after you’ve completed Step 4:

#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char *argv[]) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
    [pool release];
    return retVal;

And here’s what the application:didFinishLaunchingWithOptions: method in AppDelegate.m should look like:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] applicationFrame]];
    [self.window makeKeyAndVisible];
    return YES;

Now you can go about you view-creation business in a nibless fashion. I’d probably create a UIViewController subclass as my root view, construct my UI in loadView, and wire everything together in the AppDelegate.

Nibless App Xcode Template

But don’t do any of that stuff! Instead you can just use this handy-dandy Xcode template to do all the work. On of the very few things Xcode gets right is its template system. It is very easy to create a custom template for Xcode (see here and here for the basics).

Install the NiblessApp custom template in Xcode:

  1. Download nibless_app_template.tgz
  2. cd ~/Library/Application Support/Developer/Shared/Xcode/Project Templates/ (you might need to create the Project Templates folder if it doesn’t already exist)
  3. tar xzvf /path/to/nibless_app_template.tgz
  4. Quit Xcode and restart

© 2021