The application I have busy building is called 42 Restaurants and it was a concept my girlfriend, Margarét, and I came up with one day while sitting in a sushi restaurant. It goes along the lines of producing a really beautiful iPhone application that showcases recipes from some of the best restaurants in the world. You can read more on the 42 Restaurants website here.

The concept started out simple. My knowledge at the time of the iPhone SDK was very basic and we didn’t want to be too ambitious. The main features would be amazing pictures, simple functionality and great recipes; all the while providing good marketing for the restaurants involved.

Now that we are nearing the end of developing the application, I can let everyone in on some tips to hopefully help their progress with their own application.

1. Read, Read, Read

The main thing that stood me in good stead for learning the SDK was reading. I read everything, from the Apple developer documentation to blogs and online tutorials. The two books that really helped me the most were - The iPhone Developers Cookbook By Erica Sadun and Cocoa Programming for Mac OS X by Aaron Hillegass. The best thing about these two books is that the former teaches you how to build and use components in the SDK without needing to worry about things like code structure and development tools. The latter teaches you the fundamentals of Cocoa programming – even though it contains no coverage of the iPhone SDK.

Understanding the basics is key to using the iPhone SDK.

2. Get To Know XCode

Coming from a development environment from Eclipse, XCode seems at first very different and at times a bit clunky. Now that I have figured out how to use a large portion of it, I can honestly say that I love it. Its simple, fast and it isn’t intrusive while you are coding. One tip which I think most Eclipse & Netbeans programmers will appreciate is to change the Layout Mode. Go to XCode->Preferences->General and change the Layout to All-In-One. All your XCode windows will then be grouped into one place and the interface will alter itself depending on whether your are debugging or coding.

Another important thing to do is download all the SDK documentation to XCode. Take a look at this great blog post to see how to do it without having to use XCode’s built-in documentation downloading mechanisms.

3. Understand How Interface Builder Works

From reading numerous forums on the topic, programmers seem to find it difficult to understand Interface Builder (IB). I was one of them. My distrust of WYSIWYG interface tools led me to building all my view code manually. This, as you can imagine, took me forever until I spent some time trying to understand IB. Now, I pretty much build all my components in IB.

The main concept I had difficulty grasping with IB was what piece of code fitted with what. Each XIB file has two parts, a File’s Owner and a View. The File’s Owner is a class that inherits from UIViewController and the View can be any class that inherits from UIView.

If you want to initialize a XIB file all you need to do is instantiate your view controller with the method initWithNibNamed and then add the view of that view controller as a subview of whatever view you are currently displaying. If you want to do any post instantiation initialization, such as setting text for a UILabel or applying an image to a UIImageView then you override the method viewDidLoad in your view controller.

Don’t forget of course to wire up your IBOutlets and your IBActions in your File’s Owner to your View and to set your File’s Owner to be the custom view controller that you have created in XCode. Otherwise, your view will load and nothing will happen.

4. Don’t Do Cut-and-Paste Coding

This seems to be the number one problem in the development community. There are too many programmers that try to code by searching the Internet looking for solutions to their particular problem. Cutting some sample code from a blog or forum post. Pasting it into their project only to find A) it doesn’t work, B) it is full of bugs or C) badly written.

Understand the principles of what you are trying to do before you go on the web to find a solution. Often you will save time writing the component/algorithm from the ground up and even if you don’t, you will have learnt a lot in the process. The next time you have to build something similar you can use that knowledge.

5. Don’t Be Scared to Rewrite Code

My application was about 80% complete when I realized I was coding around my solution. The architecture that I had designed was firstly, very inefficient memory-wise and secondly, limiting me in terms of the functionality I needed to add. When I started the project I had a very basic understanding of Objective-C and the iPhone SDK, and my solution thus far had evolved into a big, code beast. So I spent 2 days rewriting the core of the application. I lost 2 days but I gained a whole bunch of functionality, improved memory usage and reduced my code base considerably.

6. Lessons

42 Restaurants will hopefully get into the App Store at the end of April. Although the idea seemed simple to start off with, it has grown into a fully fledged recipe application. The sheer amount of design work that Margarét has put into it, makes it in my mind, a masterpiece. Each individual recipe has been custom designed and the application is looking amazing because of it. We both wanted to the application first and foremost to blow the user away with how great it looks and I think we are there.

I hope the code-work on my part will live up to the task. Keep watching this blog and the 42 Restaurants website for news on the launch. We are also on the threshold of starting a round of user testing, so if you have an iPhone and would like to check what we have built so far, post a comment and I will add you to my list of testers.