Kicking Off iPhone Development

The first items we’re going to need are Xcode and the iOS Software Development Kit (SDK). These are the basic tools you’ll need to write your app.Apple maintains a degree (well, several degrees) of control over their developer tools, so you’ll need to sign up for the Apple Developer Program. Don’t worry, it’s free to start with; there’s no fee until you want to test your app on Apple hardware (the first hit is always free).You’ll have to create an Apple ID if you’ve yet to do so. You can use an existing iTunes, Apple Online Store, or MobileMe account if you have any of those, which will save you a bit of typing.A confirmation email should arrive fairly quickly. When you receive it, sign in to the Apple Developer Member Center. You’ll be greeted by the Member Center dashboard, your one-stop point for downloading tools, development kits, and documentation. Once you have a fully paid iOS Developer Program Account, this dashboard also lets you provision devices for testing and development purposes. It’s also where you’ll prepare your App for distribution, and eventually launch it to the App Store.For now, we’ll just download Xcode and the iOS SDK. Click iOS under Dev Centers.Next, choose Downloads, and finally Xcode 3.2.4 and iOS SDK 4.1 (or similar—by the time you read this, the version numbers may well have increased). Be warned: it’s a hefty download, weighing in at 2.3GB.The installation is standard for a Mac OS X app. Note, also, that you’ll have to quit iTunes towards the end of the install process.

Now the fun begins!There are a few ways to develop an iOS application. Apple provides a set of pre-built application templates to get you started. Most of them use Interface Builder, Apple’s WYSIWYG iPhone and iPad interface creator. At present, it’s a separate application that works alongside Xcode, linking visual elements to code elements via special XML files that iOS can parse.In the next version of Xcode, Xcode 4, Interface Builder will become an integral part of the development environment. It will be more like the Forms interface of Microsoft Visual Studio, if you’re familiar with that environment.Using Interface Builder has some clear advantages:

There are a number of cases where there’s no benefit in using Interface Builder. If you’re making games or highly interactive interfaces, the standard tools won’t cut it. If your view is going to contain a number of dynamically generated elements, Interface Builder will also fall short of what you need.I’d also argue that you should know what’s going on “under the hood” as much as possible before you let the tools generate code for you. You’re less likely to feel lost later on as a result.Addressing the specifics of Interface Builder goes a bit beyond this article. For now, we’re just going to write a very simple “Hello, World!” application to prove that everything works. In a later article, we’ll look at using Interface Builder and Xcode together to build applications that are more exciting.Start Xcode, and you’ll come upon the welcome screen; the left side will look like Figure 1, “Xcode’s welcome screen”.

Figure 1. Xcode’s welcome screen

Click New Project. You’ll see the New Project dialog, shown in Figure 2, “Xcode’s New Project dialog”. You can reach this dialog at any time by selecting File>New Project.

Figure 2. Xcode’s New Project dialog

You’ll see a few options for the different types of Application you can create. The options are:

Note that the above are just templates, starting points for you to develop your apps. Many apps include elements from several of these templates; Tweetie, for example, has both a Navigation Bar and a Tab Bar. It’s even possible to include an OpenGL ES 3D view within another view—you’re positively spoiled for choice.For now, select Window-based Application. We’ll start with the bare bones and work up from there. Name your project as you see fit and click to proceed.

Here we are, in Xcode. There’s a lot going on here.Up top we have the toolbar, shown in Figure 3, “The Xcode toolbar”. From here, using the dropdown on the far left, you can select your target Architecture, Executable, and Target (if your project includes more than one), Configuration (Debug or Release) and Device (a hardware device, or the software Simulator).

Figure 3. The Xcode toolbar

Initially you’re going to want to stick to a Debug Configuration. These builds include a lot of code specifically intended to help you track down problems in your code; however, they run a lot slower than a Release build. There’s also a special class of bugs that can creep into your code, which only show up in a Release build, so it’s worth testing your app in Release configuration now and then.For now, we’ll gloss over the rest of the toolbar—save for the most important button: Build and Run. This compiles your app, and sets it to run on your selected device (or the simulator). Feel free to click it now; all you’ll see is a blank screen. You can safely quit the Simulator once you’re done.On the left we have the Groups & Files pane. This shows the structure of your app, including the raw stuff on the file system, and some more virtual information; for instance, under Targets, you can unfurl your project and see the how the build process will occur.

Figure 4. The Groups & Files panel

The important bits in the Groups & Files pane, for now, are under Classes, Other Sources, and Resources. We can ignore the rest for the moment.The Editor, shown in Figure 5, “The Editor window”, is where you’ll be doing most of your coding. If you hit Shift+Command+E, it’ll zoom up and take over the space occupied by the file browser. If you’re in a header file, you can switch to the implementation file (or vice versa) with Option+Command+Up.

Figure 5. The Editor window

You can pop individual files out into windows of their own by double-clicking them in the Groups & Files pane. Personally, I don’t care for lots of windows flying around, so I was gratified to hear rumors of tabs coming in Xcode 4.

iPhone apps all have a fairly common structure. Each app will typically have a main.m file (under Other Sources in the File Browser) that instantiates the AppController (more on this in a bit).The Resources directory is where all your non-code files should live. Once you start developing more intricate apps, you’ll want to put images, text files, and other miscellanea here.The AppController is the first entry point for OS messages into your application. It’s worth taking a look through ApplicationNameAppDelegate.m for an idea of the events your app will need to respond to. Some of these methods are more or less optional if you’re creating very simple applications, but if you’re planning to store data based on user input that’s of any significant complexity, you’ll want to implement methods like applicationWillResignActive and applicationDidBecomeActive. These methods allow you to respond to changes in your application’s life cycle, such as when it’s about to terminate.An AppDelegate on its own doesn’t do much. We need to add a View. And because iOS apps follow the Model-View-Controller pattern, we’ll also need a ViewController.Create a new file: File>New File (or Command+N). One of the options Xcode gives us is a UIViewController subclass. Neat! Select that, and give it an appropriate name. Xcode will automatically generate a header file for us, too.

Figure 6. Creating a new file

You’ll have two new files, as expected. These comprise your ViewController, which is in charge of receiving input events and responding to them by manipulating the View. Typically, one ViewController should be responsible for one View. That’s not a hard rule, though; it’s up to you if you want to organize your application differently.If you take a look at your ViewController’s implementation file (that’s the .m file) you’ll see Apple has provided us with a bunch of pre-built functions, commented out. We can implement the ones we need—but which ones will they be? We have a ViewController, but we need a View. Let’s go ahead and create a View in our ViewController. Uncomment loadView, and make it look like the following:

- (void)loadView {  self.view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];  self.view.backgroundColor = [UIColor greenColor];}

If you hit Build and Run now … you’ll be disappointed. We’ve built our view, but we still need to tell our AppDelegate about the existence of the ViewController we created, and ask the AppDelegate to instantiate the view.Switch to ApplicationNameAppDelegate.h. We need to add the ViewController as a property of the AppDelegate, like so:

#import <UIKit/UIKit.h>#import "AndysExampleApplicationViewController.h"@interface AndysExampleApplicationAppDelegate : NSObject <UIApplicationDelegate> {  UIWindow *window;  AndysExampleApplicationViewController *viewController;}@property (nonatomic, retain) IBOutlet UIWindow *window;@property (nonatomic, retain) AndysExampleApplicationViewController *viewController;@end

You’ll notice we added the ViewController as a property of the AppDelegate in the @interface definition. Later, we use @property, which is a bit of syntactic sugar to automatically declare getters and setters for that property.Switch over to your AppDelegate implementation file now (ApplicationNameAppDelegate.m).First, we need to create the getter and setter methods for our AppDelegate’s viewController property. We could declare these methods ourselves, but there’s a simpler way to do it, using @synthesize:

#import "AndysExampleApplicationAppDelegate.h"@implementation AndysExampleApplicationAppDelegate@synthesize window;@synthesize viewController;#pragma mark -#pragma mark Application lifecycle

@synthesize calls should, by convention, always follow your @implementation declaration and precede any method definitions.We’ve declared that we want to use our new class in the AppDelegate, and created accessor methods to get and set it on our AppController. Now we need to tell the AppController to instantiate the class. We’ll modify the method applicationDidFinishLaunchingWithOptions to do so:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {  // Override point for customization after application launch.  [window makeKeyAndVisible];  self.viewController = [AndysExampleApplicationViewController alloc];  [window addSubview:self.viewController.view];  return YES;}

We added one line to allocate (alloc) the ViewController, and one to add the ViewController’s view to the window. This is critical—the window needs to know about views that it contains, and views need to know about any other views or UI elements they contain.Hit Build and Run now. You should see an eye-shatteringly bright-green screen. Well done! You’ve created a view. It’s quite boring here, though … let’s spice it up a little.Let’s add a label. This is a simple visual element that contains some text. In your ViewController’s loadView method, add the highlighted code below:

- (void)loadView {  self.view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];  self.view.backgroundColor = [UIColor greenColor];  UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(50, 200, 200, 80)];  label.text = @"Hello, World!";  label.textAlignment = UITextAlignmentCenter;  label.shadowOffset = CGSizeMake(1,1);  label.backgroundColor = [UIColor greenColor];  [self.view addSubview:label];  [label release];}

We’ve allocated memory for a UILabel element. We’ve initialized it with a width of 50 units and a height of 200 units, offset at X 200 (up and down the screen) and Y 80 (across the screen). Hit Build and Run and you should see the label appear in your view, as shown in Figure 7, “Our bright-green “Hello, World!” app”.

Figure 7. Our bright-green “Hello, World!” app

What happens if it fails to work, or it doesn’t behave as you expect?Xcode ships with a full-featured debugger. You can set breakpoints within the Editor at specific lines of your code. A breakpoint tells your application to halt execution at a particular line of code, and report to the debugger. You can, from there, inspect the variables and objects your application has instantiated and set to gain a clear idea of what’s happening.Set a breakpoint in your ViewController’s loadView method by clicking on the large gray bar next to your code, as shown in Figure 8, “Setting a breakpoint”.

Figure 8. Setting a breakpoint

Now fire up your application again by clicking Build and Debug. Wait, what’s that? By adding a breakpoint we’ve indicated that we want to run the debugger, so the Build and Run button has changed to read Build and Debug. Your code will execute to the breakpoint, and stop. Press the Show Debugger button at the top of your Project window (it looks like a spray can of insecticide).Lo, the debugger. On the left, you can inspect the sequence of functions your code has run through to reach this point; on the right, you can see the contents of your app’s memory (including local and global variables). You can even change their values from here.This gives you the power to diagnose changes your app is making in a step-by-step, methodical manner.When you’re ready to continue, hit the Continue button at the top of the debugger.

We’ve learned how to set up Xcode and create a very basic application. We’ve also looked briefly at the simulator and the debugger, both essential tools in app creation.Apple has a wealth of documentation available via the Apple Developer Center. There’s everything from tutorials to API documentation in there, and it’s a must-read if you want to continue developing apps. Here’s some of the key reading I’ve found:

If you want to go further in app development, I’d recommend taking this example application and adding a button or two that a user could interact with. Learn the UIKit and how to implement responsive controls, and then move on to using Interface Builder to create your UI and hook it into your Controllers in Xcode.Last year, Stanford University ran an iPhone Application Programming course, the videos of which are available through iTunes U. These videos are very informative and well worth watching.

We’ve run you through your first steps as an iOS app developer. From here, you can access a wealth of resources that will teach you how to produce increasingly complex functionality and create an application that people will really enjoy using.A subsequent article will look at creating a more involved application, including the use of the Interface Builder to create a UI, and accessing information from the Web via HTTP. Stay tuned!