A C# Developer’s Adventures in Objective-C

The other day, my father asked me how to get started developing for the iPhone and iPad. He is looking for a technical hobby that he can do while he travels in his upcoming retirement. I had no idea really how to get started so I asked around. I learned quickly that it doesn’t take much to learn if you have an Apple computer.

All that I did is:

  1. Download XCode 4 which is a free download from the Mac App Store.
  2. Download the Stanford University iPhone and iPad Application Development Collection for iTunes U.
  3. Watched the first 2 lectures from the course.
  4. Fired up XCode 4.
  5. Attempted the Reverse Polish Notation Calculator targeting the iPhone described in the second lecture.

Of course, this was a very simple iPhone application that was built with only about three ours exposure to Objective-C (the programming language), Cocoa Touch (the iOS framework), and XCode (the integrated development environment). It was a fun exercise. However, if you are only familiar with .NET and/or Java there are some uncomfortable moments with the Object-C syntax that you are bound to encounter. Mind you I am a complete novice with the language, the framework, the development environment, and the platform. Nevertheless, these are my experiences.

First things first… The iPhone application makes heavy use of the model-view-controller (MVC) pattern. I like this. I am familiar with the MVC pattern and I can work with that. What was surprising is that the only code I really touched was the model objects and controller objects. The view was entirely created with the visual designer which generated a storyboard file to describe the view. This file is an XML file. This wasn’t difficult to get used to as I only really worked with the native Cocoa view objects. I am curious to find out what the story for creating your own view objects is.

After dragging and dropping controls on the storyboard, I started working with the controller. This experience was mostly clicking and dragging connections from the visual designer to the controller source code and implementing a few properties and methods. Take a moment to review the controller header file:

Even with some exposure to C and C++ over a decade ago, this header file appeared strange to me. It’s purpose is similar to C or a C++ header file as it serves to declare class, type,  function, and constant declarations.

Now look at the source file:

This is the source file which contains the implementation details of the declarations in the header file. There really is a lot going on in both of these files that are needed to compile the view controller.

To be honest, at first glance I was really confused and it took me some time to understand the high level basics of the syntax and what it was doing. The @notation did not make sense. There are many keywords here that don’t translate directly to C#, or Java. I didn’t understand what the dash (-) in front of method declarations and implementations was for. What was the difference between the @interface structure in the header file and source file? I was really lost. The syntax was extremely foreign. Did you notice all the square brackets?

I will summarize what I can here, but really at this point I would recommend looking at a good Objective-C primer like the Learning Objective-C Primer found the iOS Developer Library. By the way, the documentation packaged with XCode 4 and the developer libraries found in the Apple Developer Center are your friends!

Concepts in the Header File


The header file is small and concise and is not too hard to understand. The first think you should notice is the #import directive. This directive is similar to the using keyword in C#. It tells the compiler that you want to include code defined somewhere else in your header. In my header file, I am telling the compiler to include the UIKit header file where the interface of the UIViewController class is declared.


The @ symbol indicates a compiler directive. The interface directive is used to presents the class name (CalculatorViewController) and begins the declaration of the class interface. This should not be confused with the concept of an interface in C#.

It is my understanding that the declarations made in the header file are accessible to other header and source files when they are imported.  So in C# terms, you can think of these declarations to have the public visibility modifier applied to them.

@property (weak, nonatomic)

The property directive is a convenient way of declaring a property backed by an instance variable. The closest think I can think of is a the declaration of a property in a C# interface like this (even though it is a really far stretch):

The next thing are the custom options contained in the parenthesis. These options define how the accessor methods behave. If you want to find out more, check out the declared properties documentation.


This directive is used to close other opening directives. In this case, it closes the @interface directive.

Concepts in the Source File


Here we see the #import directive again. In this file we have two of them. The first is the header file for this source file. The second is the header for a Calculator class that is used in the controller.


Again we see the interface directive. This time it is followed by parenthesis. I have no clue what these are for yet. Again my understanding here is that the declarations in this interface block are only visible to my implementation in this source file (somebody please correct me if this assumption is incorrect). Nothing really new here besides those things I don’t quite get.

Within this interface I declare two more properties and introduce some more custom options. I suppose these would be how you declare private properties in C#. But again it is a really far stretch that is not an accurate translation.


The implementation directive is similarly structured to the interface directive as it begins with the presentation of the class name. The difference is that this directive contains the implementation details of the class. It is closed with the @end directive at the bottom of the page.


The synthesize directive the implementation counterpart to the @property directive. This directive tells the compiler to generate the setter and getter methods for the property according to the custom options presented in the interface declaration. In addition, we can also specify the instance variable that backs the property.

– (ReturnType)methodSignatureKeywords:(ParameterType)parameterName moreMethodSignatureKeywords:(ParameterType)parameterName

What the heck is this? Tons of stuff going on here. What you have here is the pattern of a method prototype. It starts with a dash (-) or a plus (+). The dash makes it an instance method while the plus makes it a class method (or a static method). In the first parenthesis we present the return type. This is followed by the method name interlaced with parameter types and names. I found this very hard to read at first. But with a little practice you can get some really readable methods.

When declaring a method with in the context of the the @interface directive you would terminate it with a semicolon. By contrast, within the context of the @implementation directive it is followed by an open curly brace, the method body, and terminated with a closing curly brace.

For instance, take a look at this method:

This method specifies the getter method for the calculator property. Yes, the compiler would have created a simple getter for the calculator property since I used the property and synthesize directives. But since I implemented the getter, the compiler will only generate the getter method. But moving on to talk about the method. Here I am declaring an instance method that returns pointer to a Calculator object. The method name is “calculator”. This is followed by curly braces that contain the method implementation details.

A loosely translated C# equivalent might look like this:

I added the auto setter in the translation to give you an idea of what the @property and @synthesize directives did for me in this source file.

Let’s look at one more method in the source file:

This example method takes a single parameter. And may be loosely translated to C# like this:

You will notice the return type here is void and that is because the IBAction return type is a constant in the UIKit that the compiler translates down to void. The constant is used for integration between XCode and the Interface Builder tools. I probably don’t have this right either, but it is my understanding at this time (again if I wrong please point it out to me).

[targetObject methodSignatureKeywords:parameter moreMethodSignatureKeywords:parameter]

I’m sure you are asking about these now. The brackets are another notation that just did not make sense to me until some discussion in the Stanford lecture discussed them and even then I had to do a little reading in the documentation. The bottom line is this is the syntax for sending a message to an object. You can also think about this notation invoking a method.

So there you have it… my first experience with Objective-C, Cocoa, and XCode. I have much more to learn, but I am really happy that I tried it out. It was fun working with something new. I am still curious about how refactoring will work and I am sure I will miss my ReSharper features (if I do get into this I will probably try AppCode). I am also interested to investigate the unit testing options available.

[Update 4/17/2012] The walkthrough for the iOS calculator is available in PDF on the Stanford Course web site.