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.champlainarts.colby. It is prefixed automatically by your developer Team ID.
When the user connects to iCloud (usually this happens through the iCloud System Preference panel whenever the user logs in), the Apple ID is made available to all apps that are entitled to use iCloud. The ubiquity container identifier is usually set in the Capabilities tab of the target in Xcode. As you will see in Chapter 18, “Completing the Round Trip,” a shared ubiquity container may have an identifier that does not correspond to an app bundle identifier. In the case of the Round Trip, the two apps are com.champlainarts.ColbyOSX and com.champlainarts.ColbyiOS. They share a ubiquity container called com.champlainarts.Colby. It is the last component of the ubiquity container identifier that shows up in the System Preferences iCloud pane shown previously at the left in Figure 1.5.
With these two pieces of information, you can connect to the appropriate iCloud ubiquity container. That is your first task when your app starts to run.