iPhone in Action

The iPhone Simulator & Performance

In iPhone in Action we talk about some about using the iPhone Simulator as a testing & debugging facility for your iPhone programs. It's certainly an easy and convenient way to work on your programs. You hit command-r and with no additional work on your part, your program compiles, the Simulator starts up, and everything runs.

However, in iPhone in Action, we also talk a bit about the places where the iPhone Simulator comes up short. It includes: using the accelerometers, using the location manager (though you can do simple tests as the Simulator reports back Apple's Silicon Valley headquarters), and downloading streaming audio.

In the last two months I've been working on a card game, which I expect to write about more here when we're ready to release. It's shown me another pretty grave short-coming in the Simulator: performance. The issue? It's too good.

I mean, we all know that the iPhone is a mobile platform, and that by nature it'll ultimately be limited in its CPU capabilities. But, it's easy to forget that with all of the sexy animations and graphics that Apple pushes back and forth around the screen. Indeed, if you're just making simple use of Apple's more front-facing frameworks, you may not hit performance problems at all.

The problem arises when you start using more in-depth frameworks like Core Data and Core Graphics. You may end up with programs which work great on the Simulator but which seriously bog down when you put it out to a real iPhone or iPod Touch device.

Here were the top two performance problems that I hit when working on my card game:

• Rounded Corners. My cards are laid out as CALayers. When I used the new 3.0 property, cornerRadius, to round the corners of my cards, I discovered that a real iPhone got dragged to a blinking, laggy halt. I thought I was just going to need to square my corners as long as I used CALayers, but eventually discovered that if I rounded the corners myself, using a clipping area on the CALayer's context, everything worked pretty good.
• Too Much Core Data Writing. At one point, I accidentally set my program to rewrite the Core Data ordering property for my cards any time a deck was touched, rather than only when they were actually reordered. Until I resolved the inefficiency, my game felt like it was moving through molasses.

The important fact that I intend to convey here is: these problems did not show up in the Simulator, only on an actual device. This was particularly frustrating for the second problem, which I discovered after a half-day or so of programming lots of different changes.

So the moral? If you're using simple frameworks, don't worry about it, But, if you're doing more complex work, every couple of compiles, send one over to an actual hardware device. The first time you hit a performance problem that didn't show up in the Simulator, you'll be happy you did.

Next Up: I'll be back after the Thanksgiving holiday, probably talking about NSSets: how they work, why you'd want to use them, and how they integrate with Core Data.

Creating an Ad Hoc Distribution

In iPhone in Action we only briefly touch upon distribution methodology (see pages 429-431), mainly because Apple maintains extensive documents on their whole "Program Portal". However in today's post I'm going to supplement our distribution information a bit by highlighting how you create an Ad Hoc Distribution.

Why Ad Hoc?

If you're distributing through the Apple iPhone Store, you might think that you'll never need to release via the ad hoc mehcanism ... and that's probably not correct. There are a number of good reasons to create an ad hoc distribution:

• It lets you easily send a program to other team members, without them having to compile the program.
• It allows you to send pre-release copies of a program to a licensor, for their approval.
• It offers a way to get your App to reviewers prior to release.

The last point is particularly important if you're trying to get on the top-100-program escalator to success--though I personally have grave concerns over the economics of advertising costs versus top 100 returns. But if you decide to go that route you want to get copies of your program out to reviewers so that they can release reviews on the day of your release (or very close thereafter).

The Ad Hoc Process

The ad hoc process is described thoroughly in the "Program Portal User Guide" which can be found in your "iPhone Developer Program Portal" at developer.apple.com. What follows is largely a summary of the material contained in pages 50, 56-58, and 65 of that book.

Here's what all you need to do:

1. Prepare for a Provisioning Profile. This generally means that you need to follow the steps from Appendix C of iPhone in Action. You must have already created a distribution certificate, which you'll use to sign the profile; you must have chosen an AppID for your program; and you must have entered UUIDs for any devices that you want your program to run on. You should already be familiar with these items, and have them in hand, from the work you did to either create a developmental provisional profile or an app store distribution provisional profile. The only notable difference here is that you'll probably need to enter some new UUIDs, since you need to enter the data for every device that you want your program to run on--which means the devices of reviewers, licensors, co-workers, and whoever else you're working with.
2. Create a Distribution Provisioning Profile. Click the "Provisioning" option in the Program Portal, then the "Distribution" tab. Choose "ad hoc" as your distribution method, then enter data on your certificate, app id, and devices, as appropriate.
3. Create a new Ad Hoc Distribution Profile in Your Project. This relatively simple process is described at length on pages 51-56 of the Portal Guide. In essence, you duplicate the "Release" profile, then set it to use your new ad hoc profile as its code signing identity. You've probably already done the other work of this section, such as setting up your project to use your app id.
4. Create an Entitlements File. This is the major new element required to prepare an app for ad hoc distribution, and it's described on pages 56-58 of the Portal Guide, which you should read at length. In essence: you create a new "Code Signing" file of type "entitlements." Then you uncheck the "get-task-allow" property of your new file. Finally you go to the Build tab of your target and enter your new file into the "Code Signing Entitlements" section of the "Code Signing" setting.
5. Build Your Project. Now you can build. You'll of course want to make sure that you've set Xcode to compile for a device of the correct OS version, using your ad hoc distribution profile.

That should produce an ad hoc version of your project that's ready to go ...

Distributing Your Ad Hoc Program

If all of your potential ad hoc users have their iPhones or iPod Touches hooked up to Macs, you can just send the compiled product (program.app) and the provisioning profile. Your users can drag the two files to the iTunes icon on their doc, and the program will automatically copy into iTunes, then download onto their device as soon as they sync.

However, if a user has an iPod Touch hooked up to a Windows machine, the above will probably fail. The .app file will simply refuse to drop on iTunes. At the time of this writing, you need to create a special .ipa file as a replacement for the .app file for Windows users. This turns out to be just a .zip file with a specific structure.

To create an .ipa file, you need to go to the directory containing your ad-hoc-compiled app. You can find that by clicking on the app in Xcode, then right-clicking to choose "Reveal in Finder". Alternatively, it should be easily accessible in a special "ad hoc" subdirectory of your project directory's "build" directory.

In either case, once you're there run the following commands, substituting your app's name for "program":

mkdir Payload
mv program.app Payload
zip -r ~/Desktop/program.ipa Payload

(Thanks to the folks on the iphonesdk list for solving this problem, and in particularly to David Morris, who offered the above script.)

This should create a .ipa file on your desktop, which you can send out. A windows user will then be able to install your program by dragging the provisioning profile and the .ipa file to their iTunes icon.

As it happens, Mac users can use the .ipa file fine too, so if you ever need to create one because some user has a Windows machine, you might as well just send the .ipa file and the provisioning file to everyone, rather than sending the .app file out to any one.

Last step: sit back and wait for the comments to come in.