Chapter 5
Deploying to an iPhone, Debugging, and Testing

Key Skills & Concepts

• Registering for iOS developer membership

• Obtaining a certificate and provisioning

• Debugging an iPhone application

• Using zombies to debug

• Finding memory leaks

We won’t be covering the iOS’s UIKit or Cocoa Touch quite yet, but have patience, you begin these topics in the next chapter. Do not skip to the next chapter, though; this chapter is important. First, we’ll get you set up with Apple’s iOS Developer Program—a necessary step to install and test your app on any iOS device and submit your app to the iTunes App Store. You will also become familiar with many basic tasks required for compiling, debugging, and installing your app on an iOS device.

Throughout the next few chapters, we will talk about creating and running iPhone apps, but everything covered applies equally to any iOS device: all models of the iPhone as well as the iPod Touch and iPad. The deployment and debugging process and most of the UIKit functionality is the same for all iOS devices. In Chapter 19 we’ll cover how to create a universal application that recognizes and takes advantage of the larger screen and additional features of the iPad. Where it’s relevant, we’ll also talk about the differences in the iPhone 4 like the higher resolution display and how to take advantage of them while still running correctly on other iOS devices.

This chapter is not comprehensive, but it does show you the debugger, Xcode 4’s major features, and how to get your app on your device for debugging. This chapter covers two topics: installing applications on an iPhone or iPod touch and debugging iOS applications. Although you can perform basic debugging using the iPhone Simulator on your computer, truly debugging and testing your application requires installing and running it on an iPhone, iPod touch, or iPad. For instance, consider memory limitations. On your desktop computer, memory is virtually unlimited. Moreover, you probably have a dual-core, blazing-fast processor. Not so on your iPhone. The iPhone, iPod touch, and iPad all have fewer resources available than the iPhone Simulator, so you should test your applications on an actual device.

NOTE
You must have an iPhone Developer membership to complete some tasks in this chapter. If you do not, you can follow along, but we’d recommend getting membership as soon as possible.

This chapter briefly reviews obtaining membership to the iPhone Developer’s program. It then covers obtaining a certificate and provisioning for your application. This chapter’s coverage is not comprehensive, though, as the iPhone web site practically holds your hand through the certificate and provisioning process, and there is no need to duplicate its handholding here. After installing an application on an iPhone or iPod touch, you can truly debug and test the application. This chapter’s second half introduces you to debugging in Xcode and testing for memory leaks using Instruments. As with the certificate and provisioning discussion, this chapter’s debugging and testing coverage is not comprehensive, but it should be enough to make you comfortable with performing both tasks.

Installing Applications on an iPhone

Installing an application on an iPhone or iPod touch requires iPhone Developer membership. After you have a membership, installing an application is not difficult, as Apple’s Developer Portal provides step-by-step instructions.

NOTE
Apple’s “iPhone Development Guide,” available online, provides a good introduction to installing applications on an iPhone or iPod touch. The examples here illustrate installing an application as of fall 2010. Undoubtedly there will be differences in the web application by the time you read this chapter. The process’s fundamentals remain the same, though.

Membership

A basic membership in the iPhone Dev Center on the Developer Connection web site is a prerequisite to downloading the iPhone SDK, and you probably signed up for that while reading Chapter 1. However, to install applications and eventually sell applications on the App Store requires membership in the iPhone Developer Program. Apple offers two membership types: corporate and individual. You must apply, pay a $99 fee, and receive acceptance before becoming a full individual member. After becoming a member, you are granted access to the iPhone Developer Program’s Portal. This site is where you obtain certificates, assign new devices, create application IDs, create provisioning profiles, and submit an app to the App Store for approval.

If you are not a registered, paid iPhone developer, you should become one now. Go to the iPhone Dev Center (http://developer.apple.com/programs/iphone/) for complete instructions. You cannot debug apps on your device until you register.

Certificates, Devices, Application IDs, and Provisioning

A certificate is the first thing that is required. Log in to your iPhone Developer Program account and click the iPhone Provisioning Portal link. The Provisioning Portal is where you’ll create a signing certificate, register devices, create provisioning certificates, and more (Figure 5-1). Apple has provided lots of online help, including videos, for the Provisioning Profile. Take a little time to go through their documentation before proceeding.

You obtain your certificate by following the instructions on the How To tab in the portal’s Certificates tab.

Figure 5-1 The Certificates tab

After obtaining the certificate, you must register the devices you wish to use for debugging. You’ll need brief access to each of these devices to retrieve its unique device ID, but otherwise these could be iOS devices that belong to your friends or anyone you want to use for testing your new app (Figure 5-2). As with certificates, complete instructions are provided on the How To tab.

After registering your devices, the next step is to create an App ID for each of your applications. Any application you wish to test on a device must have an App ID (Figure 5-3). If an app will use Apple’s Push Notifications or require In App purchasing, then it must have a unique App ID. For other applications you can create a wildcard App ID that ends with a * and use it for multiple apps.

Figure 5-2 The Devices tab

Figure 5-3 The App IDs tab

After obtaining the App ID, you must obtain a provisioning profile (Figure 5-4). A provisioning profile essentially bundles together a signing certificate, a set of devices, and an App ID. It will be installed on your device so that your app can be installed and tested. The provisioning profile will be installed on your device(s) and allows you to install a particular application on a particular device.

Apple’s Developer Portal has a complete discussion of the provisioning process; the process is not difficult. What you can do when learning the process is to open two browser windows, one where you work through the steps and the other to skim the instructions as needed. In the following example, we take you through registering and installing a simple application on an iPhone.

Figure 5-4 The Provisioning Profile tab

Try This: Deploying an Application to iPhone

1. Create a new View-based Application named OnMyPhone. Keep track of the Company Identifier and Product Name so that you can create an App ID in the iPhone Provisioning Portal that matches.

2. Log in to the iPhone Developer Program Portal.

3. Click the Certificates tab. If you haven’t installed your certificate, do so now. These steps assume a certificate (see Figure 5-1).

4. Click the Devices tab. If you haven’t installed your devices, do so now. These steps assume a registered device (see Figure 5-2).

Figure 5-5 Adding an application to the App IDs

5. Click the App IDs tab and add the application (see Figure 5-3). Click the Add ID button on the page’s right, and add the OnMyPhone application (Figure 5-5). You’ll need to match the Bundle Identifier to what you used in Step 1.

6. Click the Provisioning tab and click the New Profile button on the page’s right (see Figure 5-4). Complete the form; be certain you select the certificate and the device you want to provision (Figure 5-6).

Figure 5-6 Provisioning the OnMyPhone application

7. Click Submit, and you return to the Provisioning page. The Provisioning Profile’s status for My On My Phone Profile should say “Pending.” Refresh the page until the status has an “Active” status. You are usually quickly granted a profile.

8. Download the profile by clicking the Download button next to the profile. The profile should have a title like “On_My_Phone_Profile.mobileprovision.” Move it to a safe location.

9. Ensure your device is connected to your computer.

10. Return to Xcode. From the Window menu, select Organizer. If your device is attached, it should appear under DEVICES (Figure 5-7).

Figure 5-7 The Organizer window

11. Drag the provision file to the Provisioning list.

12. With your iOS device attached, Xcode will probably default to building/running on your device. If not, choose OnMyPhone (your device name) from the pull-down menu at the top of the project window instead of OnMyPhone (iPhone Simulator 4.2).

NOTE
With new projects, Xcode will default to building for the latest version of the SDK. This is almost always what you’ll want. You should build your app for the latest SDK version but still specify in the build settings that it will run on a range of iOS versions older than the SDK if you don’t absolutely require a new feature only available in the latest OS.

Figure 5-8 Error message

13. You might receive an error the first time. If the build fails, click the Issues button in the navigation pane (the one with an exclamation point) and then click the issue to see details (Figure 5-8). If the application identifier that you chose when you created the project doesn’t match the one in the App ID of the provisioning profile, you’ll get a signing error. If that happens, you can change the application’s identifier by editing the file OnMyPhone-Info.plist (Figure 5-9) or you can go back to the Provisioning Portal and edit to create a new App ID or profile.

14. Close the Project Info window and open Info.plist. Change the bundle identifier to OnMyPhone.

15. Click Run, and the application should install and run on your device.

Figure 5-9 Changing the application bundle identifier

NOTE
For more information on provisioning, obtaining App IDs, and other program portal topics, refer to Apple’s “iPhone Developer Program User Guide.”

Debugging

Debugging and testing your application is paramount if you wish to provide users with a robust application. Xcode provides several excellent tools for debugging and testing your applications. In this section, you explore basic debugging using Xcode’s graphical front end to the GNU debugger.

NOTE
For a more complete introduction to debugging, refer to Apple’s “Xcode Debugging Guide,” available online.

Using the Debugger

Xcode’s visual debugger makes it easy to step through the execution of your app, examine variable values, etc. When you select View | Navigators | Debugger from the main menu, you’ll see the debugger’s panes (Figure 5-10). The left (navigation) pane shows the app’s threads and the call stack for each. This tells you where your application is currently at in any point in the application’s processing. The main pane on the right is the Text Editor pane, which displays the source code for the method, lets you set/remove breakpoints, and also permits you to view the values of variables by hovering over them. If you select View | Show Debugger Area from the main menu, you’ll see the debugger area at the bottom of the window. This pane lets you control execution of your app, see/edit the current function’s variable values, and view the contents of the console (log file).

Along the top of the debugger area, notice the buttons that control the debugger. From left to right, they are Continue, Step Over, Step Into, and Step Out. To the right of them you’ll see the current stack. Table 5-1 summarizes each button’s purpose.

Figure 5-10 The debugger window

Table 5-1 Debugger Area Buttons

Breakpoints

Breakpoints tell the debugger where to pause. If you set no breakpoints and then run the application in the debugger, nothing unusual happens, as you didn’t tell the application to pause. There are several ways to set a breakpoint, but the easiest is to click in the Editor window’s gutter next to the line of code you wish the debugger to stop at (Figure 5-11). If you wish to disable the breakpoint, click it again and it turns light blue, indicating it is disabled. If you wish to remove the breakpoint, CTRL-click and select Remove Breakpoint from the pop-up menu. Alternatively, you can drag the breakpoint off the gutter to remove it. When you run the application in the debugger, it will pause processing at the first encountered breakpoint.

Figure 5-11 Setting a breakpoint

Stepping Through Code

When an application pauses at a breakpoint, you can step through your code’s execution. Step Over moves directly to the next line, executing any function and stopping on the next line. Step Into also moves to the next line, but if the next line is a function, it jumps to the function’s first line, and you can either step through the function line by line or step out of the function. If you choose Step Out, the debugger jumps to the first line after the function call.

Debugger Datatips

One thing you can do while debugging is obtain a variable’s value and modify it while debugging. You can move your cursor over the variable in the source code, and a datatip appears with the variable and its value (Figure 5-12). You can even modify the value if desired.

Figure 5-12 The Debugger datatips

Watchpoints

Sometimes you might be interested in having the program pause when a value changes. A watchpoint pauses the program when the watched item’s value changes. Setting a watchpoint is tricky the first time, but then it becomes easy. To set a watchpoint, start the application in the debugger, and when the application pauses at a breakpoint, select the variable in the debugger window’s variable list. Right-click it and select “Watch address of” from the shortcut menu (Figure 5-13). After you click Continue, if the value changes, the debugger notifies you and pauses (Figure 5-14). It’s worth noting that watchpoints are not persisted across debugging sessions. Every application launch requires that you reestablish your watchpoints.

Figure 5-13 Setting a watchpoint

Figure 5-14 The debugger notifies you when a watchpoint’s value changes.

Try This: Debugging an Application

1. Create a new Utility Application named Debug.

2. Select FlipsideView.xib to edit it in the Interface Builder. Select View | Utilities | Show Utilities if necessary and then click the Connections button (tiny arrow in a circle). Remove the connection between the view and the File’s Owner by clicking the tiny X next to Files’s Owner (Figure 5-15).

Figure 5-15 Remove the view from the view controller.

3. Click the Run button to run the application. Click the Info button in the lower right of the simulator screen, and the application crashes.

4. Quit the iPhone Simulator and return to Xcode.

5. Open MainViewController.m and add a breakpoint at the second line in showInfo (Figure 5-16).

6. Click the Run button again to run the application. If the Debug Area is not visible, select View | Show Debugger Area.

7. Try stepping over the next few lines and the application crashes. You now know exactly which line in your code causes the application to crash. Something about presenting the FlipsideViewController caused the crash.

Figure 5-16 Debugger window stopped at breakpoint in showInfo

TIP
Forgetting to set a File’s Owner view outlet is a common mistake.

8. Stop the iPhone Simulator and return to Xcode. Remove the breakpoint.

9. From the main menu, select View | Navigators | Breakpoint.

10. Click the + in the lower-left corner to create a new breakpoint and select Add Symbolic Breakpoint from the pop-up menu. Type objc_exception_throw for the symbol and click Done (Figure 5-17). You’ve now set a breakpoint in the code that’s called at the moment the error occurs.

Figure 5-17 Adding objc_exception_throw as a breakpoint

Figure 5-18 Debugger window paused at objc_exception_throw breakpoint

11. Click the Run button to launch the application in the debugger.

12. Click the Info button, and the application halts at the newly set breakpoint. Open the debugger area, if it is not already open (Figure 5-18). You may want to drag the slider in the lower left of the window to increase the detail in the stack trace.

13. Notice the upper-left window. This contains the stack listing. Follow the stack down several items, and you see the last thing to occur prior to an NSException is loading the view from the nib. Follow the stack to row 12, click it, and you see the line of code in the view controller that was executed in the right pane (Figure 5-19). So you know trying to load the view from the nib caused the crash.

Figure 5-19 Following the stack trace takes you to an error’s source.

NSZombieEnabled

When an object is deallocated, if there are any objects with a reference to the deallocated object, they are no longer referencing a valid object. Any messages sent to the deallocated object result in errors. Often, the error is rather cryptic. For instance, the following code fragment is obviously an error.

FooBar * myFooBar = [[FooBar alloc] init];
NSMutableArray *myArray = [[NSMutableArray alloc] initWithObjects:

     myFooBar,nil];
[myFooBar dealloc];
[[myArray objectAtIndex:0] sayHello];

FooBar is allocated, initialized, and added to myArray. There are two references to myFooBar, so its retainCount is two. However, deallocating myFooBar makes both references invalid, pointing to deallocated memory space. The sayHello message is sent to the first object in myArray—the problem is that the object no longer exists. Although in this simple example it is easy enough to surmise the cause of the error message, in a real application, finding this type of error’s source is often difficult.

objc[1289]: FREED(id): message sayHello sent to freed

    object=0x521a90 Program received signal: "EXC_BAD_INSTRUCTION".

Zombies help avoid this nebulous error, helping you track down an error’s source. You enable zombies by setting the NSZombieEnabled environment variable in Xcode. Then, when debugging the application, rather than releasing an object, the debugger creates a zombie object. The zombie knows its original identity before joining the undead. The result is that you usually receive a more descriptive error message.

2009-02-28 12:28:38.749 Zombie[1316:20b] *** -[FooBar sayHello]:
    message sent to deallocated instance 0x52c6a0

Again, in this simple example, the difference is trivial; in a real-world project, the difference is not trivial. The following task illustrates using NSZombieEnabled.

Try This: Enabling Zombies

1. Create a new View-based Application named Zombie.

2. Create a new Objective-C class called FooBar.

3. Create one method called helloThere (Listing 5-1). Don’t forget to put the method’s signature in FooBar’s interface (Listing 5-2).

Listing 5-1 FooBar.m

#import "FooBar.h"
@implementation FooBar
-(void) sayHello {
 NSLog(@"Hello there...");
}
-(void) dealloc {
[super dealloc];
}
@end

Listing 5-2 FooBar.h

@interface FooBar : NSObject {
}
-(void) sayHello;
@end

4. Modify application:didFinishLaunchingWithOptions in ZombieAppDelegate (Listing 5-3). Don’t forget to import FooBar.

Listing 5-3 ZombieAppDelegate.m

#import "ZombieAppDelegate.h"
#import "ZombieViewController.h"
#import "FooBar.h"
@implementation ZombieAppDelegate
@synthesize window;
@synthesize viewController;
- (BOOL)application:(UIApplication *)application
           didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    FooBar * myFooBar = [[FooBar alloc] init];
    NSMutableArray * myArray = [[NSMutableArray alloc]
           initWithObjects:myFooBar,nil];
    [myFooBar dealloc];
    [[myArray objectAtIndex:0] sayHello];

    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
    return YES;
}

- (void)applicationWillTerminate:(UIApplication *)application {
    // Save data if appropriate.
}

-(void)dealloc {
  [viewController release];
  [window release];
  [super dealloc];
}
@end

5. Click the Run button to build and debug the application. Notice the first time you run the application you may not get an error at all (even though we sent a message to a deallocated object). This is part of what makes finding and fixing errors like this so hard—if the memory didn’t happen to get used for anything else in the meantime, it might remain valid for an unpredictable amount of time. Even if you do get an error message, it is not all that descriptive (Listing 5-4). The debugger only knows the sayHello message was sent to an object already freed. The debugger doesn’t know the object’s identity. To change this, you must enable zombies.

Listing 5-4 Debugger Console error logging when zombies are not enabled

Attaching to program: '/Users/bward/Library/Application Support/iPhone
Simulator/User/Applications/05688B53-AF22-4F21
-95D3AFFE2682A6EA/Zombie.app/Zombie', process 1351.
objc[1351]: FREED(id): message sayHello sent to freed object=0x521bd0
Program received signal: "EXC_BAD_INSTRUCTION".

6. In the pull-down menu next to the Run button, select Edit Active Scheme. Select Launch in the left column and then click the Arguments tab. This should let you edit the arguments passed to the app on launch (Figure 5-20).

Figure 5-20 The Executable Info window

7. Click the + and add the NSZombieEnabled variable to the environment variable list. Assign it the value YES and click OK.

8. Run the app again. Now the error message is more descriptive (Listing 5-5).

Listing 5-5 Debugger Console output after zombies are enabled

2010-08-21 15:10:57.345 Zombie[16692:207] *** -[FooBar sayHello]:
    message sent to deallocated instance 0x592b640

Instruments—Leaks

Instruments is a powerful suite of debugging and testing tools. This chapter cannot possibly cover it adequately. Tools include Activity Monitor, CPU Sampler, Leaks, Object Allocations, Core Animation, OpenGL ES, and System Usage (Figure 5-21).

Figure 5-21 Instruments

NOTE
For more information on Instruments, refer to Apple’s documentation “Instruments User Guide,” available online or via the Instruments Help menu.

However, one tool worth introducing you to here is Leaks. You can use Leaks without knowing much about it. The Leaks instrument allows you to easily find memory leaks in your application. It tells you how many leaks occurred, each leak’s size, the address of the leak, and the leaked object’s type. Using Leaks is fairly intuitive—rather than explaining, let me simply explain by example through the following application.

Try This: Find a Memory Leak

In the following task, you find memory leaks using the iPhone Simulator. If you didn’t do the OnMyPhone exercise in this chapter’s beginning, do so now.

Find a Memory Leak on iPhone Simulator

1. Create a new Utility application named Sieve.

2. Create a new Objective-C class named FooBar.

3. Open FlipsideViewController.m and implement the viewDidAppear method (Listing 5-6). Don’t forget to import FooBar.h.

Listing 5-6 The viewDidAppear method

-(void) viewDidAppear:(BOOL) animated {
    FooBar * myFooBar = [[FooBar alloc] init];
 }

4. Select Edit Active Scheme from the pull-down menu. Click Launch in the left column; then select the Instruments radio button and select Leaks from the pull-down menu. Click OK to save your changes to the scheme.

5. Run the application. Ignore the warning informing you that you never use the FooBar instance in viewDidAppear. Note that when you’re using Instruments, Xcode will run the iPad Simulator rather than the iPhone Simulator. You’ll also see the Instruments application automatically launch.

Figure 5-22 The Leaks panel

6. Click Info and Done repeatedly for about 30 seconds. When finished, click Stop in the Instruments window (Figure 5-22).

7. Click Leaks, and a detailed list of the leaked objects appears. Click one of the leaked objects.

8. Select View | Extended Detail from the main menu, and a call stack appears on the window’s right (Figure 5-23).

9. Double-click one of the leaks, and the source code will display with the line allocating and initializing FooBar (Figure 5-24).

Figure 5-23 The Leaks panel showing extended details

Distributing Your Application

After debugging and testing in the iPhone Simulator and on your own device(s), you’ll want to build a deployment version of your app for ad hoc testing by your beta testers (friends, family, etc.) and then a final version for submission to the iTunes App Store. The details of these deployment steps are beyond the scope of this book, but we’ll summarize them briefly here. For comprehensive instructions, refer to the Apple documentation and the built-in help on the Provisioning Portal web site.

Ad Hoc Deployment and Testing

Once you’ve tested your app as much as you can, the next step is to hand it off to some additional beta testers to make sure they understand how to use it and don’t stumble across any bugs. Apple’s number one reason for rejecting apps submitted to the App Store is crashing bugs they find during the review process—it’s worth your time to make sure your app is rock solid before submitting it.

Figure 5-24 Leaks showing source code where the object was allocated

The first step in doing ad hoc testing is to collect the device IDs for each of the test devices and add them in the Provisioning Portal. Note that you’re only allowed 100 ad hoc test devices and they only reset once a year, so make sure that you’re signing up people who will be available to test all of your applications. Once you’ve got the device IDs added, you’ll need to create a Distribution Certificate and use it to create an Ad Hoc Provisioning Profile that includes all of the device IDs. Download that profile and save it someplace safe—you’ll be sending it to each of your testers along with your app.

All of the nifty debugging tasks that you accomplished in this chapter were because your app was compiled for debugging with additional information embedded in the app. You don’t want this extra stuff in your released application; it will slow it down or worse. For instance, suppose you left the NSEnableZombie environment variable set to YES. Now when the application ran, released objects would be turned into zombies rather than the objects being returned to available memory. Your application would be sluggish and could be abruptly terminated by the device’s operating system. We get rid of this extra debugging information by building a release version of your app.

To build a release version for ad hoc distribution, you’ll want to create a new scheme (essentially a conveniently named collection of build settings). In the pull-down menu at the top of the window, select New Scheme, give it a name like “Ad hoc distribution,” and pick Launch Scheme from the two choices. This creates a new scheme where we’ll change some build settings, while leaving your original scheme easy to switch back to for additional debugging builds.

In the pull-down menu, select Edit Active Scheme, click Build in the left column, and change the Build Configuration from Debug to Release (Figure 5-25). Click OK to save the change to the new scheme.

Now select your app in the navigation panel on the left and then click Build Settings (Figure 5-26). Make sure the Base SDK is set to the most recent one available. Under Deployment set the Targeted Device Family to “iPhone”. Set the iOS Deployment Target to the minimum version of iOS that your app requires. Unless you’re using features only available in newer OS versions, iOS 3.0 is probably good, since it will allow anyone whose device is at least updated to iOS 3 to use your app.

Figure 5-25 Setting the Build Configuration to Release

Figure 5-26 The Build Configuration’s settings

Now we’re ready to build the App file that you’ll be sending to your ad hoc testers. Make sure that you’re building for a device rather than the simulator by checking the pull-down menu. Then select Product | Clean Ad Hoc Distribution from the main menu followed by Product | Build Ad Hoc Distribution. You can check the Xcode Preferences to see where your App file was written, but it probably defaulted to Library/Developer/Xcode/DerivedData/workspace-name/Build/Products/Release-iphoneos/app-name. This is the file that you can send to your testers along with the Ad Hoc Distribution Profile that you created earlier. They can just drop both files onto iTunes and then sync their device to start testing.

Distributing Your App via the App Store

To really build the final version of your app for submission to the iTunes App Store, you should check Apple’s current instructions for submitting apps. Complete instructions can be found on the iPhone Developer web site. You must have an iTunes Connect Account if you wish to sell your app on the App Store.

You will want to make another new scheme similar to the one we made in the preceding section, but this time, when creating the scheme, select Distribution Scheme rather than Launch Scheme. This will build an archived version of your app for uploading to iTunes Connect.

In addition to building a release version of your app, if you are submitting it to the App Store, you will also have to create an icon for it in several sizes, upload sample screenshots, write a description of your app, and pick a category for it. Complete instructions are available on Apple’s web site.

NOTE
Remember, installing and debugging on your test devices that can be attached to your computer do not require anything other than what was covered in the beginning of this chapter. You are not required to create a different build configuration (scheme) or Ad Hoc Distribution Provisioning Profile to debug and test on your devices.

Summary

Effective debugging and testing of your application requires installing it on a test device. It is also much more rewarding to see your app run on a bona fide iPod Touch, iPhone, or iPad. But getting your application on a device requires you to become a paid iPhone Developer Program member. You must then follow the instructions to getting the proper credentials so that you can install on your device. Trust us when we say you can muddle through the online instructions, they are easy to follow.

Many iPhone errors are cryptic at best. Rather than running and rerunning an application aimlessly until you eventually find the error, take some time to learn the debugging tools that Xcode has available to you. Refer to the documents referenced throughout this chapter. Use the debugger to find errors. After debugging your application, test its memory usage on the iPhone Simulator. After testing on the iPhone Simulator, install the application on your device, and debug and test again. Pay careful attention to memory and resource use, as an iPhone’s memory is limited. Also ensure your application runs quickly and is responsive. If you happen to only own a newer iOS device, be careful to also test on older-generation devices, since they have less memory and slower processors. Careful debugging and testing of your application can often be the difference between “just another mediocre app” and the “best app” in your category on the App Store. Chances are your application is not going to be the first of anything anymore, so try to make it the best.