iPhone Objective-C for the C# Developer

If you’re a C# developer making your first foray into the land of iPhone and Objective-C programming, you probably have a question or two.  I recently started working in earnest on an iPhone app, so I figured I would write down some of the tips I’ve picked up thus far.

Here they are in no particular order.  No particular level importance.  Just some things that I had to learn and which may help you as well.


  • It’s a strict super-set of C, so straight C code is compilable in Objective-C
  • Back to the old header and implementation files (.h and .m, respectively)
  • There are two types of methods in classes, instance and class methods.  Denoted by a prepended “+” or “-” on the method prototype.  Class methods are just like static.
  • All methods are public(!).  That’s right, read that again.  There’s a hack/technique having to do with Objective-C categories to help hide them in the IDE, but they are still callable.
  • NSObject is System.Object.
  • No garbage collection on the iPhone, there is  reference counting instead.  More on this later.
  • What we typically think of as constructors are “init” methods.  Destructors are “dealloc”.  There’s nothing special about these methods, it’s just convention.
  • Properties are denoted with @property lines in the header file.  Corresponding @synthesize statements in the implementation file generate the property code.  Special directives in the @property declaration determine the specifics of the implementation (nonatomic, retain, etc.).
  • Use #import over #include – it prevents a file from being indrectly #included more than once.
  • What .Net calls Interfaces are called Protocols in Objective-C.
  • this pointer is called self
  • base is super
  • Methods are referred to as selectors.  Calling a method is referred to as sending a message to an object.
  • Message sending syntax is [recipient method] or [recipient method:paramvalue] or [recipient method:paramValue param2name:param2value]
  • @selector() is for specifying what are essentially delegates.
  • id datatype is basically NSObject*
  • There are C strings and there are NSStrings.  C string constants are defined like “something”, NSString constants are defined like @”something”
  • [[someClass alloc] init] is the typical instantiation pattern. Sometimes there are parameters, as in [[someClass alloc] initWithValue:someValue].   Sometimes you can just call a factory method on the class as in [someClass someClassFromData:data].  The only real difference has to do with the reference counting of the returned object (again, by convention).
  • Events are achieved by what they call delegation – registering/attaching an object that adheres to a protocol (interface) to subscribe to events (called Actions).
  • No namespaces, but there are categories which I haven’t bothered touching.

Reference Counting

  • NSObject implements reference counting.
  • Calling alloc or copy sets the reference count to 1.
  • To decrement the reference count, call release.
  • When the reference count hits 0, NSObject calls dealloc.  NEVER call dealloc yourself.
  • Call retain to increment the ref count.  Basically, if you need to keep hold of an object for longer than the duration of one message event cycle (event handler), call retain.    You don’t need to call retain on an object that you directly created with an alloc or copy call – NSObject called retain for you.
  • Calling release one too many times is bad – dealloc will end up getting called twice and cause a crash. 
  • There is an AutoReleasePool and the ability to call autorelease on NSObject.
  • When you call autorelease, the release  call gets posponed/scheduled in the AutoReleasePool.  This is used when a function needs to return a newly created object to the caller.  If it doesn’t call release, the ref count will be incorrect.  If it does call release, it will immediately be deallocated.    Calling autorelease will give the caller time to call retain to take ownership.
  • When does the autoreleasepool finally call release?  The pool gets drained at the end of every message pump loop, cleaning up any autoreleased objects.
  • So, so summarize… if you call alloc or copy, you need to call release.  If you use a class factory method and need to keep the object around, call retain and be sure to have a matching release later.

Interface Builder

  • I have yet to see why Apple developers fall all over themselves about Interface Builder.  No comparison to Visual Studio.
  • Interface Builder writes to .xib files (which for some unknown reason are called Nib files).
  • It parses your header files for IBAction and IBOutlet on declarations to determine event handlers and variables for interface elements respectively.
  • IBAction is a #define for void.
  • IBOutlet is a #define for blank.
  • Just saving the .h file is sufficient for IB to reparse and pickup the changes.

Ok, I’m tired of typing now.  That ended up a little longer than I intended but I hope it helps you to get up to speed.

Chef 1.3.20

I just released the latest version, 1.3.20, tonight.  A few new things include: recipe rating; cooking times; preparation times; better search capability; ingredient preparations; bug fixes; and more bug fixes.

If you’re a user, go upgrade!  If you aren’t a user, give it a try!


And now it’s midnight, time for bed.

Some Chef Updates

Just a few Chef notes…

A couple weeks ago I reported that I had gotten rid of SWREG in favor of E-Junkie with PayPal and Google Checkout.  Since then I’ve processed a couple of orders successfully so it’s good to know I didn’t break anything.    That’s always a concern of mine when I make changes like these, Murphy has proven to be an evil guy at precisely the wrong times.

Early last month I decided to give Download.com a try so I signed up and submitted Chef to be listed.  So far it’s showing a whopping 53 downloads.

The past week has been pretty busy with bug fixes and other support things.  Tomorrow night I’m going to try my hand at connecting to a customer’s PC to see if I can check on a problem they’re having.  Since I haven’t done this before I decided to go with Fog Creek’s Copilot software to (hopefully) get us connected.  I use their (great) FogBugz software for Chef and at work, so I have high expectations for Copilot.

I just posted 1.3.18 with the bug fixes from the past week.

I think that’s it!

Visual Studio 2008

Earlier this week I received a free copy of Microsoft’s Visual Studio 2008 by being an Action Pack subscriber and completing a short little web tutorial and quiz. I installed it last night and decided to get the Chef code/projects converted so I could start using it.

The usual project conversion wizard popped up as soon as I opened the solution and prompted me to upgrade it to the new VS08 format (still targeting .NET 2.0 though).  When the wizard completed, however, I was getting a few compile errors in some of the WinForms designer files (.designer.cs).  It was easy enough to fix, the conversion just messed up namespaces during process, which surprised me a little bit.

I haven’t spent much time actually developing in 08 yet, but now that I have Chef converted I’m going to stop using 2005 in favor of it.  I’ll report any cool new features I run into.

Recipe Slideshows

Chef has a feature called Recipe Slideshows which allow you to view a recipe fullscreen in a PowerPoint-like format that’s much easier to read while you’re cooking than the small text of a cookbook, or the regular view of a recipe in Chef for that matter. I’ve had that feature around for a while, but I noticed that Ana never uses it!

Her main complaint was that the ingredients weren’t always displayed so she’d find herself constantly flipping between the directions and the ingredients, to the point where it was just much easier to deal with the small text of the regular recipe window. This past weekend I made a few changes – the ingredients are always displayed AND it highlights the ingredients that are used for the current step. Click for the full image:

Chef Recipe Slideshow

This is going into version 1.3 with a few other enhancements and fixes due sometime in January or February.

Requirements by Eavesdropping

I’m coining it. Defined as a process by which software requirements are gathered not by formal meetings and documents, but rather by hearsay.

They sure don’t teach you that at school.  Nor should they.

I can use it in a sentence, but I’d rather not.