 development teams so that developers can be assigned to the appropriate team without destroying the security structure.
Figure 2.2 Manage certificates in Xcode account preferences
Figure 2.3 shows the list of Mac certificates for a developer on developer.apple.com. Note that each one has a name that you provide, a type that you choose, and an expiration date that is set and enforced by Apple.
Managing Your App ID
Unlike your developer signing identity, which can be edited on developer.apple.com through Xcode accounts, your App ID must be managed for the most part on developer.apple.com. You give the app a name, which can be changed later on if you want. (This is not the name the user sees.) What is important to note is that when you register your App ID, you can enable services that you want to use, such as Game Center, In-App Purchase, Maps, Push Notifications, and most important for this book, iCloud.
Although you cannot create an App ID through Xcode, when you turn on a capability such as iCloud, Xcode offers to update your App ID to add the iCloud capability automatically. (You’ll see this demonstrated in Figure 2.9 later in this chapter.)
Managing Your Devices
You can register a number of devices that can be used for testing your apps. (As of this writing, the number is 100.) When you recruit people to test your app, ask them for the UDID (iOS) or UUID (OS X) of the device they want to test with. These people do not need to be registered developers, and sometimes it’s a good idea to recruit one or two testers who are “real people” as opposed to developers. The rules for managing devices are detailed on developer.apple.com. There are limits to how many times you can change the list: this limit prevents you from allowing your app to be installed on a large number of devices without going through the App Store. (Ad hoc distribution is a specific option you may want to explore in this case.) You have one list of devices for your developer account. The provisioning profiles associate them with App IDs.
Managing Provisioning Profiles
Now that you have your App ID and a list of devices, you can create a provisioning profile to combine the two. As you see at the bottom of Figure 2.2, the provisioning profiles are listed by name and expiration date along with the various entitlements associated with them when you look at them in Xcode accounts. When you look at them in developer.apple.com, you’ll see that some are marked as being managed by Xcode. For the others, you can specify the devices and the services you want to enable on developer.apple.com.
Thus, at this point, you should have your developer signing identity; your app and its App ID; and your provisioning profile that brings together testing devices, your app ID, and the entitlements or services that it uses. You’re ready to start thinking about runtime.
Identifying Your User and Your Ubiquity Container at Runtime
As you saw in Chapter 1, iCloud helps users organize their data by app rather than by file and folder. Users can still work with documents, but those documents aren’t on a visible file system in most cases: they’re in iCloud. But where is iCloud?
As with all cloud computing, the cloud is an artifact of the Internet and large server farms. If you follow the trail of bits, you see that these server farms synchronize and store data so that it is accessible on an as-needed basis by users. The physical location of the data doesn’t matter, and in fact, the actual storage is so often duplicated across servers that there is frequently no single primary data store among the many stores that come into play.
A user’s data is available (subject to security constraints) whenever a user accesses the cloud with the appropriate account information and password. That’s not the model with iCloud. With iCloud, data is available with the presentation of two identifiers:
- Apple ID: This identifies the user.
- A ubiquity container identifier: A ubiquity container is the object that holds the iCloud data for the app. It typically is a bundle identifier such as com.champlainart