Dr. Xcode or: How I Learned to Stop Worrying and Love Cocoa Touch

During the past eight months I have been working on a somewhat large project. I was in charge of programming an application to aid patient care at a hospital in Toronto. This application was to run on an iPod Touch, be easy to use, and effectively solve the problems caused by previously having no standards in note-taking. I had never programmed in objective-c. I had never used a Mac for more than 10 minutes.

Enter the Mac Mini borrowed from a friend's friend. This device saved our team's bacon as we had no other feasible way to program this application; we were given remote access to a machine that we could only connect to on campus. This tiny computer and I would go through a lot in these eight months, in fact, we became quite close and hard to separate.

Getting used to the Mac wasn't too much of an issue. A huge problem I faced was not having the latest version of OS X that was required to install the latest version of Xcode that was required to develop for iOS devices.


Turns out that when OS X's software updater says Your Mac is up to date, they really mean Oh hey, you're going to have to run out and pay thirty bucks on an upgrade disc that gives you new wallpapers! I obviously obtained the disc image in another way and updated with great success. Onwards, I ventured.

I immediately fired up Xcode and began working through this book. By the way, if you're looking to get started on iOS development, this book is an amazing resource. Pressing on, the book strongly urged me to read the book on objective-c, but knowing me, I ignored that recommendation and continued without it. Let me tell you, there were some nights I'd finish a project in the book and have no idea what I just did. I would have to sleep on it, wake up the next day, and look at it again before I could understand it at all. Slowly though, I began to understand how the Cocoa Touch framework came together to create applications.

The book walks you through some applications and, at times, tells you to use Interface Builder to construct the layout of your application. This is probably the best route for a quick application, but later on I found myself creating the user interface completely using code. I started to dislike Interface Builder, not because it was bad- it was actually very well-made. I disliked it because it made the process too easy. Not only that, it doesn't really encourage you to create custom elements and work with them in interface builder. I was only able to go so far with the default UI elements before I abandoned the SS Interface Builder.

Making UI elements in code is actually really easy. Since Cocoa Touch's function names are really... erm, intuitive, you don't have to do any guessing. For example, StringWithFormat creates a, well- I don't need to explain. So away I went, creating my UI elements in code so I could construct them whenever I wanted, however I wanted. But wait, another advantage of creating UI elements in code is that you can extend the default class. In my case, I extended a UIButton to contain an array of children UIButtons that in turn contained an array of children UIButtons, and so on.

This is where the power of Cocoa Touch really shines. Every element is basically extending another element. All visual UI elements can be traced to the UIView object. This means that every element built upon UIView share common properties and can be easily manipulated in code. Everything from event handlers to the addition of labels and additional UIViews for images can be added with just a few lines of code. If Apple had not created a framework this good, I'm sure other mobile devices would have quickly surpassed iOS devices in sales. For once I am pleased with Apple and their software development practices.

Onto Xcode! Xcode is wonderful. Complete with the provision management and built-in tools that can remotely monitor my device's hardware while I am debugging, Xcode delivers and does not stray from what I am used to in the newer versions of Visual Studio- other than the fact it is available for free (before Xcode 4, but that's not needed yet!). Xcode's version of Intellisense, Code Sense, is really good and isn't as intrusive. Tools like Instruments let me track memory leaks and allocations, since memory management is left to the programmer in objective-c, but I feel the lack of garbage collection forced me to understand the language better and forced proper habits and convention on me.

This is getting long-winded. I'm just going to finish this postmortem stating that developing on a Mac, although a little hard to adapt to for a Windows user, is a pleasant and extremely rewarding experience. It is always good to get out of your comfort zone and tackle something you would never imagine yourself doing. I feel like I have come out of these eight months with more than just another language and framework under my belt, I learned to cope.