Provisioning and code signing are two key technologies you need to understand when you want to distribute your applications.
In this series of articles, we will try to explain the concepts and process behind provisioning and code signing your applications. In the first article, we will explain all the different elements that are part of the code signing process.
Code signing your applications confirms you as being a valid developer or company. It also guarantees that the application has not been tampered with or altered after it was signed. Each application you create will need to be verified as a legitimate application created by a verified creator; you, the developer or company.
Code signing is based on cryptography. There are basically two types of cryptography: symmetric cryptography and asymmetric cryptography.
With symmetric cryptography, there’s only one key. So if you have a secret key and encrypt a message with it, only a person who knows the secret key can decrypt it.
In asymmetric cryptography, there are two keys – a public key (which can be known by everyone) and a private key (which is kept secret to you only).
One of the nice things about asymmetric cryptography is that you can use it to prove that a message did indeed originate from you. If you encrypt something with your secret private key and someone can decrypt the message with your public key to get something that makes sense, they know that you, being the only person who knows the private key, created the message. This is what is the term “signed application” refers to, the basic technique behind codesign applications on iOS.
Private keys on MacOS X live in a utility called “Keychain Access” which can be found under “Applications/Utilities”. If you open Keychain Access, you can go to e.g. “Certificates” and see all the private keys there:
Certificates are about trust. They guarantee that you, the developer or company built this code and that you are a member of the Apple Developer program. They also guarantee that Apple issues you with a certificate to be a developer.
To obtain a certificate, you need to generate a Certificate Signing Request using the Keychain Access application, then send it to Apple and in return you’ll receive a certificate. The Certificate Signing Request automatically generates a public/private key for you if you don’t have one yet.
Note that Apple makes a distinction between a developer and a distribution certificate. Just remember that a developer certificates points to a person (a developer) and that a distribution certificate points to a company.
Certificates can also be found in “Keychain Access” under the category “Certificates”.
Application Identifiers (App IDs)
The application identifier (also called Bundle Identifier) uniquely identifies an application. Each application on iOS has a unique identifier which stays the same, even if the application gets an update. They are usually constructed as reverse DNS-names.
E.g. if Twixl media were to release an application, the application identifier would most probably start with “com.twixlmedia”. Adding your company reverse DNS as the prefix of your application identifier will ensure that it’s unique. Example: com.twixlmedia.myfirstapp
Device Identifiers (UDID)
Each iOS device gets a unique identifier (UDID) assigned from Apple. it is a 40-character string.
The device identifier is important when you create what Apple calls an “Ad Hoc” build (which we will cover in detail in an upcoming article). Ad Hoc builds can only run on a list of specific devices, based on their device identifier.
There are two ways to find out your device identifier. The easiest is to hook up your device to your computer and open iTunes. Open up the summary screen and click on the serial number. That will reveal your device identifier:
If you want to get the identifier as text, just press CMD+C to copy it to the clipboard.
The second way to find out your device identifier is by opening Xcode. Then open the Xcode Organizer from the Window menu and select Devices in the toolbar.
Provisioning profiles is what links everything together. A provisioning profiles combines the following elements so that:
- An application with a specific application identifier
- can run on this restricted set of devices (UDIDs)
- with trust based on the signing by a developer (Certificate)
The combination of these 3 elements is what is called a provisioning profile. This is the file we need to create a build with Twixl Publisher. When you build the application, this provisioning profile will also be embedded within the application.
Please note that the private key is not part of the provisioning file. The private key only exists on the computer that issued the Certificate Signing Request (see under Certificates).
In the second part of this article, we will see how the provisioning and code signing is handled in Twixl Publisher.
For more information, please refer to the documentation available in the iOS Provisioning Portal (requires you to login to the Apple Developer Portal).