2009 / February 20/ Initial thoughts on Objective-C & Cocoa
I’ve been playing around with Cocoa the past few days, going through a lot of tutorials and pouring over the syntax. Overall, it’s been a very interesting experiment. The drawing API is very similar to Flash, and the language structure feels a lot like C# to me but with a completely different look to it. Thought I might jot down some initial thoughts here. Keep in mind, they’re probably wrong. I’ve only been writing Obj-C code for about a week.
First: the good
So far it’s been fun to get back into the desktop programming business. My previous experience was a lot of C# & XAML with WPF (Windows Presentation Framework), and some Actionscript & MXML with Flex/AIR.
It’s really nice to have an Interface Builder that doesn’t suck balls. Microsoft Expression is a joke (unless you’re defining a gradient), and Flex Builder’s GUI window is about as reliable as an Alpha Romeo.
Memory management is a glorious thing. Garbage collectors are great, but the biggest problems plaguing WPF & AIR apps are memory consumption. They aren’t perfect, especially when dealing with long-running application (think IM clients, Twitter clients, etc). WPF’s memory management is such a joke, it’s not even worth mentioning. In my eyes, it makes developing long-running WPF applications unrealistic.
Objective-C is also painful enough that it keeps the idiots out (for the most part). You actually have to deal with things like memory allocation, pointers, and crazy square brackets. I think the easy learning curve of Flash & WPF has lead to some of the worst applications out there.
Don’t forget to include that file
I’ll admit it: Flex Builder completely spoiled me. Anytime you use a class that hasn’t currently been imported, Flex Builder will automatically import the class if you use it in your code. XCode? Not so much… better remember you @class and #include if you plan to keep sane.
Warnings, really?
I remember running into this on very edge cases on WPF. A warning would be thrown for something that worked fine, but this happens all of the time with Objective C. Let’s look at a piece of code that will trigger this:
@implementation BigLetterView
- (id)init {
[super init]
[self prepareAttributes];
return self;
}
- (void)prepareAttributes
{
return YES;
}
This will throw a warning on the [self prepareAttributes] method because it was called before it was defined in the code. This basically equates to me ignoring all warnings. I could go through the hassle of throwing all private methods into a Category, but c’mon… really?
I miss my dots and parentheses
I’ll admit it: I just don’t like the feel of Objective-C. This whole square brackets and colons and spaces thing. It produces some really funky looking code sometimes. Here’s a made up method:
[foo bar:baz
alpaca:YES
context:[MyValues yellowValue]];
In Javascript, I might write this like so:
foo.bar(baz, {alpaca:true, context:MyValues.yellowValue});
I think the cosmetic differences are arguable, but I think what gets me is that indenting code on multiple lines to align along the colon is really hard to do in text editors. It means I usually end up keeping my methods on one line, making them very difficult to read.
This whole binding through IB is messy
Binding through Interface Builder feels really cool when you first start. But I’ve found it makes getting up to speed with projects much harder. In Flex, you can straight up see the bindings in the code, as with WPF. But if you’re opening up someone else’s Cocoa application, finding the bindings is a lot like going on a safari. You click around, have good hunches of where you might find your data, but at the end of the day, something happens that you just can’t explain.
XCode. What.
When I was writing WPF apps, I didn’t think it was possible to make an editor that was more infuriating than VS.NET 2005. I was wrong. (Thank god for Textmate)
Window management. What.
Schizophrenic Tab-completion. What.
Documentation browser. Are you kidding me?
I’d like some more scrollbars & clipping please.
A couple of WTFs
It seems all files are just in one directory. No organization or hierarchy. Seriously?
Function, variable, struct, object, whatever man. I mean is it NSBeep(), NSSize size, or NSString *string anyway? The inconsistencies are probably nice shortcuts down the road (and many arguably done in the name of performance). In the meantime, it’s a painful list of memorizations. Reminds me of Biology. I hated Biology.
On to better things
Hopefully I’ll have something to show in a few months. I’ve always had ideas for desktop applications, and started a few in WPF, but truth be told I just loathed the whole Windows environment so much I couldn’t continue. So here I am immersing myself in Cocoa… good idea? Probably not. But it sure is fun!
Know any good resources, forums, or anything else to help out a new mac dev? I’m all ears!
15 Comments
Make a Comment
don’t be afraid, it’s just text

Warpspire is the place that web professional Kyle Neath writes about the web. 



February 20 | #
I’ve been wanting to jump into Mac/iPhone development, but its hard to jump into such a fugly language and toolset. Looking at Objective-C code makes me want to cry, especially compared to modern languages like C#.
Sidenote, I prefer TextMate for my development, but Visual Studio is the best full IDE by a long shot so I’m a bit surprised that you find the text editor infuriating (I’ve never had any issues with it, plus the auto-complete is lightning fast).
February 20 | #
Ha. Sounds familiar. I started working with Objective-C a little less than a year ago now when I started working on the Pownce iPhone app, and have come across many of the same issues.
Warnings for undefined methods are annoying… but that’s a C thing. It’s how the compiler works, and I’m sure there’s no easy way around it. As you said, the easiest solution is to use a Category (at the top of your implementation/.m file). Alternatively, you can make sure your methods are defined before they are used within your class, in which case the compiler won’t complain. The whole notion of headers in C/C++/Obj-C annoys me though… it’s such a clear violation of DRY. I find myself wasting time b/c I changed a method’s signature in the implementation but forgot to change the header. It’s damn annoying.
Re: the syntax, I wouldn’t say I’ve come to like it… but I’ve definitely gotten used to it. I still prefer a more pure C/ALGOL-based syntax, but it’s not that bad. And if you use Xcode then there’s not much of an issue w/ lining up the colons since the editor does it for you. Which brings me to my next point…
What’s your beef with Xcode? As far as full-featured IDEs go, I don’t think it’s that bad. I’ve worked with VS.Net and Eclipse quite a bit, and I definitely prefer Xcode. I typically resize the editor window so the stupid file list panel is hidden, which actually produces an environment that is very similar to textmate. And the integration with build tools, debuggers, profilers, etc. is very nice. Also, there are shortcuts for opening the documentation for a class/function/whatever (option+doucleclick) and for going to its definition (command+doubleclick) which really come in handy.
February 20 | #
XCode does have a lot of nice things, but it still drives me absolute insane. I find that the window management is absolutely ridiculous. I either have to have each file open in a new window, or constantly be switching back out of debug-mode with my inline editor and force myself to always single click files (lest I double-click them and then open in a new window).
Autocomplete: holy shit. First off, I find it constantly trying to autocomplete stuff I don’t want autocompleted. For example, let’s say I want to call my variable in a method call
event. If I type “event” and hit return (so as to write a{), what I end up with isEVENT_Hlike so:The partial tab completion thing is just nuts to me. If I see that the editor knows what I want, my mind types fast enough that it usually just hits tab-space and goes on. Usually that ends up with something like
NSMutableinstead ofNSMutableArrayI also find that the auto-indention only works about half the time I try and use it for whatever reason. The other half, I keep typing expecting it to line up my arguments along the colons, and then it just never does.
There’s also no easy way to navigate between multiple files (ala Cmd-Opt-Arrow through tabs in Textmate) since there’s no concept of multiple open files (unless they’re in their own windows). This means I end up having to use my mouse a lot.
I don’t know, the whole editing experience is pretty infuriating me… perhaps I’ve just gotten too used to the niceties afforded by Textmate.
February 20 | #
First, I’d like to say that I share a lot of the pain with you all with regards to XCode. That said, there were a couple of comments that need addressed:
“I typically resize the editor window so the stupid file list panel is hidden”
Just click View -> Zoom In Editor or Shift+Command+E and the file list panel goes away.
“There’s also no easy way to navigate between multiple files”
Sure there is. Option+Command+Left/Right. There are also tiny little forward and back arrows at the top of the editor next to the filename:line number. Albeit it would be tons better visually if XCode had a tabbed view of all the files. But navigation is still possible.
February 20 | #
Gregg: Thanks for the note on navigating files. Now if only all the files weren’t in the same directory, that might be more useful :)
February 23rd | #
The files don’t have to be all in the same directory. I always create a directory structure for my source tree. XCode handles it fine.
February 23rd | #
tjsnell: are you referring to xCode groups, or can you actually have a real directory structure? I’d be really curious about the latter as I haven’t seen it on any projects’ source yet.
February 23rd | #
Hi,
I’ve similarly started my journey into objective-c programming this week. I noticed your comment on the ugly syntax of objective-c … I did come across this in the Apple guide about the dot operator which makes me think I can use it. Mind you I haven’t tried it yet.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter2section4.html#//appleref/doc/uid/TP30001163-CH11-SW17
Good Luck!
Alicia
February 28th | #
@Alicia
I believe the dot syntax is only used for accessing properties. As a matter of fact the description for that section of the guide states (emphasis mine):
“Objective-C provides a dot (.) operator that offers a compact and convenient syntax you can use as an alternative to square bracket notation ([]s) to invoke accessor methods“
The accessor methods, I believe, are the traditional getter and setter methods in Java or C#, or “properties” in Objective-C 2.0.
It should also be mentioned that Objective-C 2.0 is not backwards compatible and only works on Leopard and up. Existing code compiles and runs without any issue, but if you use 2.0 specific features, you’ll have to run the app using the 2.0 runtime, which is present on Mac OS X Leopard and OS X iPhone.
March 11th | #
While I was initially enthusiastic about Objective-C, I quickly found my way out of the cave, for reasons resembling those of yours.
Maybe if I hack my way to use Emacs instead of XCode… Nah, seems unlikely.
March 16th | #
I’m just starting down this route, I’ll have to let you know how I get on.
I’ve been a Windows dev for a while, so know VisualStudio like the back of my hand.
March 16th | #
I’ll go ahead and suggest my method – Check out MacRuby and try using that as your vessel into cocoa land. As a side-effect of doing that, I learned the basics of ObjC very quickly, and from there I started getting familiar with some deeper complexities at nearly the same pace. If you are already proficient in speaking ruby, then it may be a great codex for you too!
Good luck :)
June 8th | #
XCode is complete garbage compared to IntelliJ (IDEA). What a lumbering piece of garbage. And alas, I have to use it to develop an iPhone app. Oh well.
July 11th | #
I’m late to the party here, and hopefully you’ll have discovered some of this for yourself, but…
Feel free to structure the project folder how ever you’d like – handy for browsing files while in the finder. I’m not sure why you feel it necessary while actually working in Xcode, as the the project browser works exactly the same way as the finder…
Regarding multi-line method parameters, you’re not required to break them up – some find it easier to read that way, but most Objective-C folks I know of just use one line.
Autocomplete – you’re doing it wrong. Enter commits, space overrides. As for the sub-token completion, I dunno, I think the math works in its favor – I mean it’s one extraneous keystroke in a handful of cases, but it saves tons of typing on some of the longer methods.
Multiple documents / window management – you’re doing it wrong. Of course you can have as many documents open in a single editor as you’d like – either a pane of a multi-pane window or a dedicated editor window. Simple keystrokes tab through the open files, just like any other app. You can also access the open file list in the upper left corner, either with mouse or shortcut. Further, switching between .h and .m just requires a simple keystroke, you don’t have to “open” the alternate.
Oh, and if you don’t want to switch to the docs all the time (though option double click is awesome – and btw, command double click takes you straight to the class header file), use the research assistant panel.
Oh one more thing, the NS prefix indicates a class/method is Objective-C. NSObject variables are declared as pointers, hence the * prefix.
I do agree that setting up bindings kind of sucks, as it can be easy to forget to update the key values in IB and crash your build.
To date, I haven’t heard more than a handful of complaints about an actual functional problem with Xcode – almost all arise from not fully understanding the workspace.
PS. You can disable compile warnings is the preferences. They can get annoying.
January 26th | #
What about and easy way to generate a class?
In eclipse, I can enter just the properties and generate all the
hand-coded boiler-plate code. Seems like a no-brainer.
What am I missing?