Objective-C: The Good, The Bad, and The Ugly

, ,

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.





Interesting to read your experiences. What’s your take on the new features on iOS5, namely ARC for memory management? Do you feel it makes up for the lack of GC?

My own, albeit quite limited, experience of the community has been overwhelmingly positive. Sure, it may not be as big as Java or C# community, but helpful nonetheless.

Then, with regards to the Xcode, I don’t agree with everything you wrote. It has weak areas, and I probably have grown accustomed to some of the weirdnesses, but I’d like to point out that it does support version control, unit tests, debugging with variable watches etc. so for that part I think you made some erroneous claims. There is a lot to improve, and as you mention bug reports and such interactions with Apple would be very welcome.

Another aspect that you didn’t really get into is the core APIs and documentation. I really like Cocoa Touch, and I also think the documentation is really good. Then again, I only have very limited exposure to other languages, but Apple’s documentation, IMO, beats Java (and VB) documentation by a mile. I really appreciate the level of thought that has been put into the structure of the core APIs, and I feel that once you spend a month or so programming, you’ll easily find and understand new APIs.



@Mikko: Thanks for reading and taking the time to write a comment.

ARC will be sweet, but I’d need many months of every day use to make a good statement about ARC vs GC. As far as Xcode goes, I wrote this under Xcode 3 which double sucked. Xcode 4 is certainly better, but it still sucks. It could be that Obj-C is just not a very toolable language…but that’s not a good excuse in my opinion. I’m gonna take JetBrains AppCode for a spin on a new project and see how it goes.



Pretty interesting article, but I’ve got a couple points to disagree on:

- Xcode doesn’t generate setters/getters for ivars, but that’s not really required – properties exist, and are a language feature, and @synthesize generates setters and getters for them automatically (you don’t even need to make an ivar for any given property, the compiler handles it)

- Xcode (4) has refactoring tools, which run the usual gamut of features of other IDEs.

- The same memory management dance is required of C and C++ – malloc/free and new/delete are just different words for alloc/retain/release. Objective-C is by no means meant as a nepenthe for memory management woes, and is not billed as such.

- To say “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” really bolsters the above point, and the key word is “my” – it *is* possible to write leak-free code when you pay close enough attention to your memory management (not to say that you don’t). Instruments is there for when you don’t, or when the frameworks put you in a bad position. Every (*every*) language has these sorts of niggling failings.

- The toolchain is likewise pretty aged, and is not really the problem. You can build an Objective-C-using binary from the command line, with a single invocation of gcc (or clang/llvm). The additional weight of bundle packaging is NEXTSTeP’s fault (and thereby Apple’s) – bundles are not a language feature of requirement.

I am by no means an Xcode, Apple, or Objective-C apologist, but credit should be given where it is due.




I’m having voodoo with this ARC I think. Object pointers are mis pointing, sometimes not.




I have a different take on XCode. I’ve used Eclipse as an IDE for work for about 6 years. After having used XCode for the past 4-5 months, it has become my all time favorite IDE.

As an example, XCode will automatically refresh/reload changed files for you without need to ask you. To this day, I can’t figure out why Eclipse requires you to manually press F5 to refresh all files. Out of hundreds or possibly thousands of times that I’ve changed files outside of Eclipse, there was never a case where I would have needed Eclipse not to refresh the file automatically.

Fortunately, with Objective C, I caught it at the right time, after Apple had added ARC (automatic reference counting). The pre-ARC code looks scary and a bit too close to the metal for me (and I’ve been a professional programmer for 20+ years !). With the inclusion of ARC, Objective C has replaced Java as my all time favorite language as well.
Java’s pretty good except that sometimes it seems to take a lot of lines of code to do fairly simple things — I think it may be due to all the strict formalisms put in make certain things difficult or impossible to do. Example: Objective-C categories — I can’t think of a straightforward Java equivalent to it, probably because Java tends to err on the side of extreme caution.

And, for real time games, Objective-C + cocos2d makes for a superlative combination. I wrote a Java/Android game a while back where I didn’t have to worry about garbage collection, except that I did. Turns out that allocating objects inside the game loop is pretty much a no-no in Java. Basically the game loop runs 30-60 times per second, so anything you allocate will tend to fill up memory fairly quickly. And when garbage collector runs, it introduces delays of 100-200 milliseconds into the game loop, basically causing very noticeable pauses during game play.

With Objective-C + ARC + cocos2d, memory management has extremely easy, in comparison.



I pretty much agree this article. I have used a lot of IDEs and xcode is a big behind the rest. I don’t think it’ll catch up very easily.

The biggest gripe for me the way .xib’s with the interface builder / storyboard are so separarte from the code and requires developers to link variables. Why aren’t variables for all components made available? They’re there in memory and on the storyboard, we should have access to all of them (why do we have to link them all the time?).

It would be good if the interface builder / storyboard editor could understand the code better so that we can right click and jump into touch event code. Pretty much all other IDE’s do this and they can create the events method declaration for you.




@Clive you can, view has a handy method called subviews, which lists all the subviews. Having a link is needed, how will you know which label text your setting self.view.subviews[5]? not very readable.

Also, you can just not use nibs…you can pragmatically make UIViews and there are big arguments over which is better then the other.




As a multi-platform web & apps developer who’s used a lot of IDEs, I feel like XCode’s UI is a joke… It’s a bunch of awkward overlapping windows with 95% of the tools/features sitting somewhere on a drop-down menu. Zero design went into XCode as far as I’m concerned.

I’m a PC guy, so it’s also super frustrating that I have to own a Mac (or possibly set up an OSX dual-boot if the hardware allows) to code Objective-C iOS apps in XCode… Why can’t there be a PC development path with Eclipse or something???





Is there a way to use Eclipse editor importing UIAutomation libraries? Can anybody help me on this?





I’m new to Xcode, Objective-C, Macs and Apple products. My previous experience includes coding in C, Java, C++, Perl, etc. I’ve used many different IDEs and (VI/Notepad/etc) to develop small and large programs. Personally, I found pushing into Objective-C much harder than other programming languages, probably exacerbated by the new dev environment, but I’m happy about how well it shapes up if you give it a chance.

By far the worst and most time consuming problem is the auto-layout/constraints/UI design grief. Everything just seems to clash, and just when you think you have a good layout it can quite easily be undone. I’ve read that becoming an expert at XCode layout design takes time, but I’m so used to a friendly WYSIWYG UI builders that such a touchy one is like torture.

© 2014