The Case for Objective-C

For my iPhone Application Programming course I have become quite accustomed to using Objective-C; mostly because Apple strongly recommends requires that you write all of your code in it. Let me just begin by saying that Objective-C can be one of the most confusing and, at least at first glance, poorly designed programming languages that I have come across. Rather than using the standard C-like syntax of instance.method Objective-C uses a message passing syntax which looks a little something like [instance method]. Or… at least it used to. With the introduction of a new feature set Objective-C has also gained a ‘dot’ syntax similar to more classical languages. See what I mean about confusing?

So why on earth would anyone program in this language? Well in my opinion there are a number of good points that make Objective-C an ideal language to use for certain scenarios.

  • It is one of the few high-level languages that still compiles to native machine code.
  • It was built from the ground up as an object oriented programming language. This stands in contrast to C++ which effectively tries to tack OOP onto classic C.
  • Because it wasn’t trying to preserve any backwards compatibility, as was the case with C++, Objective-C did not inherit problems of an earlier language.
  • Objective-C can interface with standard C libraries and can even include C code inline for ease of use.
  • While Objective-C does make use of pointers, it does not suffer from the ‘pointer hell’ that C/++ does. What I mean by this is that it is more intelligent about its use of notation. For example, you don’t need to remember that you need to grab the memory address of an object (&) and then pass that as a pointer (*) to a function or, god forbid, make use of a pointer to a pointer (to a pointer to a pointer…).
  • Like C/++, Objective-C gives you complete control over memory management. However if you choose to you can enable automatic garbage collection for your code as well.
  • Unlike C’s #include pre-compile directive,which always forces a full copy of the source at be added at that point, Objective-C’s #import directive only adds the source once resulting in a smaller footprint.
  • When you finally do get Objective-C’s syntax it becomes a very straightforward and easy to read language.


On the Mac setup is basically as easy as installing Xcode. If you happen to use that platform I would highly recommend that you use Xcode as it is the absolute best Objective-C IDE. However for the rest of us we get to dig into the command-line!

Following this excellent guide I was able to install the required libraries and tools for both Windows and Linux. Essentially just follow the instructions on, the open source implementation of NeXT’s Objective-C libraries, and you should be off to the races. Just remember that for Windows you only actually need to install GNUstep System and GNUstep Core (in that order!). Once everything is installed just open up your terminal (Linux) or start GNUstep Shell (Windows). This is where we will be compiling the programs from.

First program

Everyone needs a classic ‘hello, world!’ example program! Here is a very simple way to do this in Objective-C. Create a file called main.m (.m is like .c or .cpp) and place the following code in it:

//Link into the Foundation library which contains a lot of useful functions
#import <Foundation/Foundation.h>  

//the main program function that will be run
int main(void)
    //log our string out to the console
    NSLog(@"hello, world!");

    //return success exit code
    return 0;

Then to compile it follow the instructions back on this post. I have found that for me the best Windows command line arguments are as follows:

gcc `gnusetup-config –objc-flags` -o [output name i.e. “test” produces “test.exe”] [input .m files i.e. “main.m”] -I /GNUstep/System/Library/Headers -L /GNUstep/System/Library/Libraries -lobjc -lgnustep-base -enable-auto-import

Your results may be different though. For the above example I used “hello” as the output name and “main.m” as the input .m files. On my machine this resulted in a file called hello.exe that was 478KB in size. If we change the first line of the program to #import <Foundation/NSString.h> instead and then recompile it we can shrink this down to 417KB. This is because we only really use the string library in our program, so importing the rest of Foundation is simply unnecessary.

Using objects

Rather than write a whole tutorial here I have created a little demonstration about the different ways you can use objects. While I don’t claim that this is the best way to do things, in fact if you read main.m I claim quite the opposite, it does give you an idea of the flexible nature of Objective-C’s OOP and memory management systems.

Download Here

Wrapping it up

Essentially what I am trying to get across here is that Objective-C is far from perfect, but it is quite a mature language and as such should probably have more wide-spread support. As a Computer Scientist who grew up in the post-C++ world, see: Java, I completely understand why many people are opting to use sandboxed or ‘virtualized’ programming languages, like .NET, Java and even things like PHP, over native languages like C/++, Objective-C or assembly. On the other hand there is something to be said for still writing code on the metal if for nothing else than the performance improvements you get by default. A lot of people are afraid of C’s pointers but if you can program in Java then I think you can easily program in Objective-C.

Give it a shot, you just might like it 😉