A Brief Primer for Objective-C

When I’ve chatted with fellow programmers and mentioned that I code in Objective-C, I tend to get the same general response: “you’re crazy; have fun with that…” In an effort to demysticize the language, and talk about what makes it so different, I’m writing a very brief primer to coding in Objective-C. This Primer is written for someone who is familiar with managed, object-oriented programming languages, such as C#, Java, or ActionScript 3.0, as I will be focusing on the differences between those kinds of languages and Objective-C.

Native, or non-managed language

What is a native, or non-managed language? In the basest of terms it is a language that does not implement automatic memory management, such as garbage collection. Where this comes into play when programming in Objective-C is memory management, and how this is handled by the programmer. Thankfully, you don’t have to deal with this as much as you used to, at least if you are using the last two versions of Apple’s Xcode IDE (the current publicly available version as of this writing is Xcode 4.5.2), as Xcode’s updated compiler has a fantastic technology called Automatic Reference Counting (ARC). For a more thorough explanation, check out this article from Apple (Transitioning to ARC Release Notes), suffice it to say it makes life as an Objective-C programmer much, much easier; but there are still some things to think about.

.h versus .m; and public versus private API

One of the first things noticed by programmers coming from languages such as C# and Java, is that there are two files that make up every class in Objective-C; a header file, whose suffix is .h, and an implementation file, whose suffix is .m. The header file contains the *public* declarations for instance methods, class methods, and Properties, and the implementation file contains the *private* declarations for instance methods, class methods and Properties, as well as the implementation code for both public and private instance methods and class methods. Take note of how public and private API is determined not by a keyword, but by the location of the declaration for that API.

Weak versus Strong

When declaring Properties in Objective-C (more on that in a bit) you have to tell the compiler if the data within the Property, what is going to be stored in memory, is Strongly or Weakly pointed to; this is what the compiler uses to correctly determine the necessary allocation and deallocation of objects in memory under the ARC system. When an object is Weakly pointed to, it is kept in memory as long as at least one other thing is pointing to that object; whereas when an object is Strongly pointed to, it is kept in memory until what is Strongly pointing to it is no longer pointing to it, or that pointer is set to nil.

A quick note on nil…

Unlike any other language I’ve personally coded in (C#, Java, ActionScript 3.0), when you send nil to a method, instead of the method immediately raising an exception, or even crashing your application, the method simply doesn’t do anything. You did read that right: sending nil to a method will have the method do nothing, and it will not crash your application.


With nearly no exception, every time you would use an instance variable in Objective-C, you use a Property instead. I’ll go ahead and get it out of the way, Properties are my second most favorite thing about Objective-C; the reason for my favoritism is that Properties allow you, the programmer, to be involved whenever anything touches the data stored in your Property. How awesome is that! Here’s how this works:

After declaring a Property, you can implement two methods, a “Setter” and a “Getter”, which are called each time the Property’s value is set or accessed, respectively.

Syntax for declaring a Property in Objective-C:


Syntax for the Setter for AStringOfSomeLength:


Syntax for the Getter for AStringOfSomeSort:


Syntactical confusion…

Now that we’ve seen some Objective-C method implementations, let’s talk about how Objective-C presents its method syntax. In the above methods, you can see that the return type precedes the method name, but even before that is a minus sign. The minus sign indicates these are instance methods; if these were class methods they would have a plus sign in front of them. Next thing you’ll probably notice is the asterisk after the return type on the Getter method, AStringOfSomeLength: ; this is telling you the programmer, as well as the compiler, that what will be returned is a pointer to an object in memory, not the actual object in memory; in practice there is little difference you will notice when using pointers versus actual objects, you just have to remember to add the asterisk when appropriate (which is nearly 99% of the time).

The pointer shows up again for the argument that is being passed into the method. You can see the colon after the method name; this is what is used to separate method names and arguments. The number one thing that trips up new Objective-C programmers is the language’s nesting of method names and arguments, more on that in a moment.

Another oddity about the Setter method is the variable we are returning: _AStringOfSomeLength. There is a little wizardry going on here, as Xcode understands that generally the backing instance variable for the setter of a Property is the Property’s name with a prefixed underscore; because Xcode knows this and we aren’t implementing any special code here, we don’t have to declare the instance variable ourselves. It’s one of many things Xcode does to ‘help,’ which unfortunately usually only serves to confuse newcomers to the language.

One last thing to note about method syntax. In what I’ve read was an effort to increase the human readability of Objective-C, as well as make the language as self-documenting as possible, its creators decided to nest arguments inside method names. Let me explain. In the Getter method for the Property we declared above, the colon before the argument acts as a separator for the method name and the arguments; there can be numerous colons separating numerous arguments. The simplest example, which also highlights one of the better use cases for how highly readable and self-documenting Objective-C can be, is the following method: InsertObject:atIndex:

When used with a Mutable Array (which is similar to a List in C#) this method would look something like the following, where AnArray is an NSMutableArray* Property and anObject is any object:


In conclusion…

My hope is that this primer has shed some light on some of the differences between Objective-C and other object-oriented languages. It probably raised more questions then it answered, but now you have a good start towards coding in Objective-C. I plan on posting a tutorial for Objective-C and iOS within the next week, and hopefully that will allow for more in-depth information on key aspects of Objective-C.