urity has changed insofar as the developer interface is involved (the underlying security mechanism is not changed). The changes make it easier for you to set up your app’s security, but for many developers, it is a new process. Once again, there is an unlearning process involved when you use the new and simpler tools. Because iCloud requires security to be in place and because the way in which you implement it is changed, this chapter begins with an introduction to the new, improved, 2013 version of app security.
Managing App Security on iOS and OS X
The heart of the app security system is digitally signing your code with two digital signatures. Both of these signatures are generated by Apple, and each one references the other. (This is a common security mechanism that you can read about on Wikipedia in articles such as “Code Signing,” which explains the process.) These signatures will not match if either the one identifying Apple or the one identifying the developer has been altered; in addition, part of the digital signature contains a checksum mechanism that causes the security system to fail if the code has been altered since it was signed.
Part of the complexity arises from the use of these digital signatures. The security for apps is built on a combination of developer.apple.com tools, Xcode tools, and Keychain Access tools. It is important to note that Apple IDs are used to identify people, and there are two categories of people (thus Apple IDs) that come into play: During development, you as a developer have an Apple ID. At runtime, the user’s Apple ID comes into play with iCloud.
Identifying Yourself and Your App on developer.apple.com
Along with changes in Xcode 5, during 2013 developer.apple.com was revisited to consolidate the process of managing certificates, identifiers, devices, and provisioning profiles. These are the components of the security system for apps on iOS and OS X. Although the terminology hasn’t changed, the layout of developer.apple.com has changed. Furthermore, with Xcode 5, it is easier to manage these security features, but the process is slightly changed.
Here is an overview of the process. It is required for you to set up your app to use iCloud as well as to ultimately distribute it.
After you register on developer.apple.com, go to Certificates, Identifiers & Profiles (currently at the right of developer.apple.com). It handles security for both your iOS and OS X apps. However, you can now do this through Xcode 5 and later: it’s much easier there.
- You must identify yourself as a registered developer with a signing identity.
- You must identify your app with an App ID.
- You must identify the devices that you want to use for testing your app during development.
- You must create a provisioning profile that brings together your developer ID, your app ID, and the IDs for your test devices.
Managing Your Developer Signing Identity
A key part of the security mechanism is the certificate that you can download for each signing identity that you create. That is the link between developer.apple.com and Keychain Access on your Mac. The certificate is a portable and secure representation of your signing identity. In developer documentation, you may find the terms used interchangeably.
You can manage your signing identities in Xcode or on developer.apple.com. Xcode 5 introduced the ability to manage one or more Apple IDs for developer accounts, as you can see in Figure 2.1. A given Apple ID does not uniquely identify a specific developer account because a developer can be invited to join one or more development teams. You normally continue to use your developer Apple ID even though you may be working on several teams. Figure 2.1 shows the simplest scenario: a single developer Apple ID working on a single team. For iOS and Mac, one developer can have different roles.
Figure 2.1 Manage your accounts on Xcode
Perhaps the most important point to take away is that you must use your own Apple ID to avoid compromising the security system for apps. Use the tools described on developer.apple.com to manage