Contents

CKContainer

A conduit to your app’s databases.

Declaration

class CKContainer

Mentioned in

Overview

A container manages all explicit and implicit attempts to access its contents.

Every app has a default container that manages its own content. If you develop a suite of apps, you can access any containers that you have the appropriate entitlements for. Each new container distinguishes between public and private data. CloudKit always stores private data in the appropriate container directory in the user’s iCloud account.

Interacting with a Container

A container coordinates all interactions between your app and the server. Most of these interactions involve the following tasks:

  • Determining whether the user has an iCloud account, which lets you know if you can write data to the user’s personal storage.

  • With the user’s permission, discovering other users who the current user knows, and making the current user’s information discoverable.

  • Getting the container or one of its databases to use with an operation.

Public and Private Databases

Each container provides a public and a private database for storing data. The contents of the public database are accessible to all users of the app, whereas the contents of the private database are, by default, visible only to the current user. Content that is specific to a single user usually belongs in that user’s private database, whereas app-related content that you provide (or that users want to share) belongs in the public database.

The public database is always available, regardless of whether the device has an active iCloud account. When there isn’t an iCloud account, your app can fetch records from and query the public database, but it can’t save changes. Saving records to the public database requires an active iCloud account to identify the owner of those records. Access to the private database always requires an active iCloud account on the device.

Using iCloud

Whenever possible, design your app to run gracefully with or without an active iCloud account. Even without an active iCloud account, apps can fetch records from the public database and display that information to the user. If your app requires the ability to write to the public database or requires access to the private database, notify the user of the reason and encourage them to enable iCloud. You can even provide a button that takes the user directly to Settings so that they can enable iCloud. To implement such a button, have the button’s action open the URL that the openSettingsURLString constant provides.

User Records and Permissions

When a user accesses a container for the first time, CloudKit assigns them a unique identifier and uses it to create two user records — one in the app’s public database and another in that user’s private database. By default, these records don’t contain any identifying personal information, but you can use the record in the user’s private database to store additional, nonsensitive information about that user. Because the public database’s user record is accessible to all users of your app, don’t use it to store information about the user.

While a user record isn’t the same as the user’s CKUserIdentity, the identity does provide the identifier of their user record that you can use to fetch that record from either the public database or the user’s private database. For more information, see userRecordID.

Testing Your Code Using the Development Container

At runtime, CloudKit uses your app’s com.apple.developer.icloud-container-environment entitlement to discover whether you’re using a Development or Production version of your provisioning profile. When you configure the entitlement for development, CloudKit configures the app’s containers to use the development server. The development environment is a safe place to make changes during the development process without disrupting users of your app. You can add new fields to records programmatically, and you can delete or modify fields using iCloud Dashboard.

Before shipping your app, always test your app’s behavior in the production environment. The production server generates errors when your app tries to add record types or add new fields to existing record types. Testing in the production environment helps you find and fix the places in your code where you’re making those types of changes. You can use CloudKit Dashboard to modify record types in the development environment, and then migrate those changes to the production environment.

Topics

Creating Containers

Getting the Public and Private Databases

Getting the Container’s Identifier

Determining the User’s iCloud Access Status

Requesting and Determining App Permissions

Performing Operations on the Container

Discovering User Records

Fetching Long-Lived Operations

Accessing Container Metadata

Instance Methods

See Also

Core objects