Things to Think About When Starting iPhone/iPad Development

A co-worker recently asked me what to learn and what to watch out for when starting iPhone development. There are key decisions that you need to make early on that can make or break your project. I’m also thinking about porting my existing iPhone app to the iPad, as well as writing a new app, so now is a good time to revisit those early decisions and start on the right track.

The first decision point is native vs. non-native. Native iPhone apps are written in Objective-C and use the iPhone SDK Cocoa Touch libraries. Non-native apps can be written as web apps running in the Safari browser, developed in other development platforms like Flex and compiled for the iPhone, or developed as hybrid web/native apps using a bridging framework such as PhoneGap.

If you don’t know Objective-C it is tempting to make the native/non-native decision based on your current skill-set, but that is shortsighted. If you want to make a quality app you need to understand if your app really demands native integration or not. Obviously, if you’re doing a game or anything with significant graphics you must do a native app (although in the case of games they are often mostly C or C++, which runs fine on the iPhone anyways). But even if your UI just has complex interactive screens you’re probably going to wish you had gone native.

Non-native is fine for apps with simple, informational screens that do not have a great deal of interaction beyond basic navigation. Fortunately, getting access to hardware specific features is not a blocker. PhoneGap exists to bridge between the device capabilities and a web app. It exposes the GPS, accelerometer, camera, and other features through a javascript API. Basically it is a minimalist native app that is a framework to run a web page running in Safari. You download the source, point it at your web app, and compile it.

However, if your app is complex then you will thank yourself later if you just bite the bullet and learn Objective-C and Cocoa. In this case, there are a few considerations:

• Interface Builder (IB). How should you use it, if at all? Options:
  • Don’t use it at all, create all views programmatically.
  • Only use it to layout major screens, do event manipulation in code.
  • Go all in and do UI layout, properties, event wiring, etc. in IB.
• Programming style. Stick to Objective-C 2.0 unless you have prior experience using older idioms.
  • Watch out for out-of-date tutorials on the web that contain mixed programming idioms.
• Memory management strategy. Think about your window and resource ownership structure. Stay consistent!

Doing all of the UI programmatically can lead to huge amounts of unreadable code and cut’n’paste setting of properties. But the result is very predictable. You know exactly what is going to happen and where things are set. Here is a brief example setting up a label:

UILabel *myLabel = [[UILabel alloc] initWithFrame:CGRectMake(50, 100, 200, 100);
myLabel.backgroundColor = [UIColor grayColor];
myLabel.font = [UIFont fontWithName:@“Ariel” size: 14.0];
myLabel.shadowColor = [UIColor grayColor];
myLabel.shadowOffset = CGSizeMake(1,1);
myLabel.textColor = [UIColor blueColor];
myLabel.text =@“label text”;
[self.view addSubview:myLabel];

Not too bad, but now consider a medium complexity screen may have a half dozen widgets on it. My current preference is to do screen layout and properties in IB, but to do all events and manipulation in code. This allows me to layout complex screens with multiple widgets and images visually while still not relying on IB too much. The downside is it can lead to some inconsistency. For a trivial screen with one image and a button (e.g. a tutorial screen) it seems pointless to create and manage a XIB file. But if you create it programmatically then some of your screens are represented in IB and others are not. Overall it seems worth the trade-off — all of the important screens can be mocked up and rapidly edited in IB.

Programming style is another topic to pay attention to when you are in the learning stages. There are many tutorials on the web, but not all use the same idioms. It is easy to learn from multiple sources and end up with a mixed style that can lead to inconsistency resulting in bugs. In particular, pick an approach to handling properties and stick with it. Objective-C 2.0, introduced not too long before the iPhone was first released, includes features to create properties declaratively. Unless you know what you are doing, learn this well and and stick with the 2.0 conventions.

Objective-C is the type of language that greatly benefits from consistent coding style, particularly when it comes to memory management. Your approach will depend greatly upon the application you are building, but similar to C++, the main thing is to think it through in advance. Don’t expect to do it as go you and refactor on the fly. Think through which resources are memory intensive and which are not and plan your memory management strategy around the memory intensive resources.

So, in a nutshell:

• If you are doing a non-trivial app and you care about quality, strongly consider doing it natively in Objective-C.
• Interface Builder is great for layout and setting properties on complex screens. Use it for that but do everything else programmatically. If you screens are simple, avoid it altogether.
• Learn Objective-C 2.0 idioms and use them consistently.
• Learn good memory management techniques and plan your app around memory intensive resources.