Learning iCloud Data Management: Setting Up iCloud for Development
- Managing App Security on iOS and OS X
- Looking Inside the iCloud Basics
- Using iCloud in Your App
- Chapter Summary
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
In Chapter 1, “Exploring iCloud and Its User Interface,” you saw how iCloud looks to users. For many users, it’s just a logical way of working, and iCloud really isn’t an issue that they think about. For other users who have become used to managing their own files and folders on their various devices and desktops, there can be a significant effort at familiarization—an unlearning process. As technology advances, these unlearning events happen from time to time, but in the long run, the old way of doing things is forgotten. You may have had to configure a dial-up modem with bit rates and parity settings, for example. Now, even dial-up modems are automated and managed with handshakes to adjust their own settings. Dial-up modems are (fortunately) becoming artifacts of the past. And reports are surfacing of mystified children who don’t know what a computer mouse is in the world of touchscreens that they inhabit.
This chapter looks at iCloud from the developer’s perspective. As noted in the Introduction, iCloud isn’t a monolithic API or framework that you just plug into your code. It’s a collection of additions and modifications to many parts of Cocoa and Cocoa Touch. In this chapter, you’ll find a high-level view of those additions and modifications with particular emphasis on setting up iCloud in your app.
iCloud involves synchronizing data across a user’s devices, and as soon as you start thinking about sharing data among various devices, you have to consider the security issues involved. Fortunately, the engineers at Apple have done this: iCloud takes advantage of the security mechanisms that are built into the App Store and the Mac App Store. App security has not changed dramatically over time; however, configuring security has been difficult for many developers. In part, this is because it is a relatively complex process that, for most developers, is done relatively infrequently. That combination is a classic recipe for difficulty.
With the introduction of Xcode 5 in 2013, the implementation and setup of app security 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 development teams so that developers can be assigned to the appropriate team without destroying the security structure.
Select the team you want to work with, and click View Details (shown at the lower right of Figure 2.1) to see its signing identities and provisioning profiles, as you see in Figure 2.2.
)
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.
)
Figure 2.3 Manage certificates on developer.apple.com
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.)
){kind=link}
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.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.