iOS Code Signing: Under The Hood

This is a guest post by Adam Eberbach, a mod on the forums and a full-time iOS developer in Melbourne, Australia for Intunity, a local consultancy.

Learn all about how Code Signing works!

Learn all about how Code Signing works!

Many beginner iOS developers cringe when they think about bundle identifiers, provisioning profiles, App IDs, or certificate signing requests. It’s a lot of new and confusing terminology coming all at once, and it’s easy to make a mistake during the process and be unsure where to turn.

That’s where this article comes in! Here we will demystify the various terms related to iOS code signing and explain step by step how everything fits together. When you’re through reading this article, you should have a much better understanding on how things work, and be ready to apply the knowledge when building apps to run on devices.

This article assumes that you are a member the iOS Developer Program and have a basic familiarity with Xcode and iOS development. If you are completely new to iOS development, you might want to check out some of the other tutorials on this site first.

Allright, so let’s dig into iOS code signing and see how it works!

Why Should I Care?

The main reason you should care about how code signing works is that you need to use it to run apps on real devices, whether it be your own, those of clients, or for customers on the App Store!

If you don’t use code signing, you will only be able to run your code on a simulator or a jailbroken device – and if you want to reach a wide audience, that’s simply not enough.

And just as important, to properly test your code you really need a physical device. The simulator does an excellent job for an initial level of testing, but there are three main reasons you need to test on an actual device before you ship:

• A physical device is usually slower
• A physical device has far less memory
• There are some APIs that work only on a physical device

Let’s go through each of these in detail.

A physical device is usually slower

The simulator uses the full power of your Mac processor, while a physical device has far less capability. As such, it’s important to run on an actual device to make sure that your app will perform the way you want it to.

For example, make a new View-based application in Xcode, and put the following code in your view controller’s viewDidLoad:

int count = 200000;
NSMutableArray * array = [NSMutableArray arrayWithCapacity:count];
for (int i = 0; i < count; ++i) {
    [array addObject:[NSString stringWithFormat:@"%d", i]];
}

If you run this on your simulator, the app will start up within a second or two, but if you try running this on your device it will take considerably longer (around 7 seconds on an iPhone 3GS). If you were testing only on the simulator, you might not realize the performance problem.

A physical device has far less memory

Similarly, the simulator uses all of the memory available on your Mac, while the memory available for your app is quite limited on physical devices.

This is especially important for games (so listen up Cocos2D fans!), which usually include a large number of images, and hence are quite memory intensive. On older devices, there’s an upper limit of 24MB of textures that can be loaded at a time, which would be just enough to fit 3 1024x1024 8-bit textures, so it’s quite easy to exhaust!

Update: As Stuart from the forums points out, newer devices have a unified memory architecture, which gives you a lot more storage for textures. For more details check out his full comment!

Exhausting memory is something you don’t want to happen in iOS apps, because if you use up too much memory the OS will shut down your app, which appears to users as if your app crashed.

So when you’re testing memory load and usage, you really need to use a physical device, as you’re won’t see as many issues on the simulator.

There are some APIs that work only on a physical device

The final reason why you need to test on an actual device is that sometimes you just have to!

For example, most of the In-App Purchase API works only on a physical device, and you can’t use some Instruments, like Core Animation, on the simulator because it requires hardware.

In summation, it is absolutely true to say that you haven’t really tested until you have tested on the device!

Why Shouldn’t I Care?

Sometimes you might wish you could just ignore all of this, because it can be complicated. And sometimes you can, because later versions of Xcode are making it easier to handle all of this for you behind the scenes, by choosing options such as “use this device for development.”

If you haven't seen this already, open the XCode 4 organizer, select devices and then right-click on “Developer Profile” you get this menu. It will take you to instructions on how to do most of what this article discusses automatically.

True - you can sign into your developer account and automatically provision apps to run on your device. Now if this worked perfectly every time this article would not have been necessary, but equipped with the knowledge of what might have gone wrong when or if it does, you’re set. And as a developer you want to know how things work anyway.

On almost every project I know a client is going to want a build on their device. I get the UDIDs up front, I make sure I can provision for that device with a bare project template and at the end of every sprint I aim to be able to build and pass on that build without wasting a day on working out which bit of the provisioning process I got wrong. It’s a lot easier to get all your ducks in a row when a clean build only takes seconds.

So the answer - there’s no good reason why you shouldn't have a basic understanding of how things work. Read on.