So one of the things you run into when y… 

So one of the things you run into when you develop for the iPhone or iPod Touch is code-signing, and the various things that come with this. After a crash-course in certificate signing from Senior Engineer, Steve, and many days of fiddling around with Apple’s developer portal trying to figure out how to get it all working, I think that a full writeup is called for.

One of the first ways that you’ll know you need to spend more time fiddling around with this stuff is the classic ‘codesigning’ error when you try to build your project and test it on your ipod. It can take a while to figure out where the issue lies when the code-signing error pops up, but after working quite extensively figuring out how to run and test applications, and subsequently how to build and upload them to the app-store, I have a little check-list of code signing things that I go to now when things go wrong. I’ll go into each item in detail a little later on.

  1. An appropriate certificate
  2. A public key that matches this certificate
  3. A private key that matches the certificate and the public key
  4. A provisioning profile that matches all of the above, AND is correct for your build.

      5. So what does each of these things do, and how do I get them?

      1. Certificates:
        A certificate is a data file, signed by a certificate signing agency. You don’t need to interact with the signing agency directly, Apple will take care of that for you. To get your certificate, you send a certificate signing request to Apple. More on that in a moment. First lets look at exactly what a certificate does, and how it works.

        A certificate gets rolled into your code when you build your application. It provides an end user’s computer with information about where the app came from and who built it. In order to verify that what the certificate says is true, certificates are ‘signed’ by an agency. One can self-sign a certificate, but this provides the user no guarantees that you are who you say you are. A signed certificate matches information stored in your public and private keys, and adds a layer of authority that comes from an external signing service. When you build your app X-Code checks for all three of these things. This can be misleading if you have downloaded a certificate that somebody else generated (say you are working as part of a development team and somebody else generated all of your certificates). You may see Keychain entries for the correct certificate, and items called public key and private key. It does not necessarily follow that these three items match one another.

        There are two ways to get matching certificates and keys. Firstly, one generates the certificate signing request oneself, and submits it to Apple. When a certificate signing request is generated, matching keys are also created. For more details on this, see the walk-throughs in the apple developer portal. Alternatively one downloads the correct certificate from the developer portal, and crucially obtains the matching keys from whoever created the certificate. This might be good things to keep in a development repository of one is working as part of even a small team doing iPhone development. That way, each time somebody wants to install an app, they don’t have to go about creating certificates from scratch. This is particularly sensitive when it comes to distribution certificates. Each development account can have a number of development certificates attached, but only one development certificate. If your boss is on vacation, and he created the certificate, but didn’t share the private and public key before leaving, you will need to create the certificate anew for yourself. Only the owner of the development account can create distribution certificates; registered team members cannot.

        In order to deploy an application to the app-store, it must be signed with the distribution certificate.

      2. Public key
        In order to get a public key, you create a certificate signing request according to the process outlined by apple, or import one created by somebody else when they generated the code-signing certificate.

        The public key states the identity of the signing authority, and contains all of the public information that verifies that you are who you say your are.

      3. Private Key
        The private key contains information about the machine that compiles the code (in theory). As such it’s actually not very good practice to share private keys around the development team, and is probably better practice to generate new signing certificates each time a team-member submits code to the app store.

        However, if you find Apple’s certificate and provisioning system cumbersome, then particularly for development certificates, it’s an option.

      4. Privisioning Profile

        The final puzzle piece is the provisioning profile. Getting this right can be quite a balancing act, given that the provisioning profile takes into account not only public and private keys, and the certificate needed for code-signing, but also the purpose of the build. Development profiles are locked to individual device ID’s, and are distinct from distribution profiles. I have found that if in doubt, it has been best to generate a new profile.

        There is an important reason that I list this item last: it needs to be the very last thing you create on the developer portal before you try to build your app. When you generate a provisioning profile, Apple locks it to a particular certificate. If you haven’t generated the certificate your program is going to use yet, you can’t download a provisioning profile that will work for that certificate. Furthermore, if you re-generate a particular certificate, you will have to open your provisioning profile on the apple site, and hit save, to update it for the new certificate, then re-download and feed it to x-code. I repeat, do this last.

      If you want to know a little bit more about the mechanics behind all of this, check out the Wikipeda page on code signing.
      Also Jeff Crouse spends some time walking through this process in his excellent tutorial on getting openFrameworks running on the iPhone.

      If you have specific questions please comment and I’ll do my best to answer them!