CKRecord
A collection of key-value pairs that store your app’s data.
Declaration
class CKRecordMentioned in
Overview
Records are the fundamental objects that manage data in CloudKit. You can define any number of record types for your app, with each record type corresponding to a different type of information. Within a record type, you then define one or more fields, each with a name and a value. Records can contain simple data types, such as strings and numbers, or more complex types, such as geographic locations or pointers to other records.
An important step in using CloudKit is defining the record types your app supports. A new record object doesn’t contain any keys or values. During development, you can add new keys and values at any time. The first time you set a value for a key and save the record, the server associates that type with the key for all records of the same type. The CKRecord class doesn’t impose these type constraints or do any local validation of a record’s contents. CloudKit enforces these constraints when you save the records.
Although records behave like dictionaries, there are limitations to the types of values you can assign to keys. The following are the object types that the CKRecord class supports. Attempting to specify objects of any other type results in failure. Fields of all types are searchable unless otherwise noted.
Supported Data Types
CKRecord fields support the following data types:
- NSString
Stores relatively small amounts of text. Although strings themselves can be any length, use a CKAsset to store large amounts of text.
- NSNumber
Stores any numerical information, including integers and floating-point numbers.
- NSData
Stores arbitrary bytes of data. A typical use for data objects is to map the bytes that they contain to a
struct. Don’t use data objects for storing large binary data files; use a CKAsset instead. Data fields aren’t searchable.- NSDate
Stores day and time information in an accessible form.
- NSArray
Stores one or more objects of any other type in this table. You can store arrays of strings, arrays of numbers, arrays of references, and so on.
- CLLocation
Stores geographic coordinate data. You use locations in conjunction with the Core Location framework and any other services that handle location information.
- CKAsset
Associates a disk-based file with the record. Although assets have a close association with records, you manage them separately. For more information about using assets, see CKAsset.
- CKRecord.Reference
Creates a link to a related record. A reference stores the ID of the target record. The advantage of using a reference instead of storing the ID as a string is that references can initiate cascade deletions of dependent records. The disadvantage is that references can only link between records in the same record zone. For more information, see CKRecord.Reference.
Defining Records
The process for defining your record types depends entirely on your app and the data you’re trying to represent. It’s best to design records that encapsulate data for one unit of information. For example, you might use one record type to store an employee’s name, job title, and date of hire, and use a separate record type to store the employee’s address information. Using different record types lets you manage, manipulate, and validate the two types of information separately.
Use fields that contain CKRecord.Reference objects to establish relationships between different types of records. After you define your record types, use the iCloud Dashboard to set them up. During development, you can also create new record types programmatically.
Indexing the Fields of a Record
Indexes make it possible to search the contents of your records efficiently. During development, the server indexes all fields with data types it can use in the predicate of a query. This automatic indexing makes it easier to experiment with queries during development, but the indexes require space in a database, and require time to generate and maintain.
To manage the indexing behavior of your records in the production environment, use CloudKit Dashboard. When migrating your schema from the development environment to the production environment, enable indexing only for the fields that your app uses in queries, and disable it for all other fields.
Customizing Records
Use this class as-is to manage data coming from or going to the server, and don’t subclass it.
Storing Records Locally
If you store records in a local database, use the encodeSystemFields(with:) method to encode and store the record’s metadata. The metadata contains the record ID and the change tag, which you need later to sync records in a local database with those in CloudKit.
Topics
Creating a Record
Accessing the Record’s Fields
object(forKey:)subscript(_:)subscript(_:)setObject(_:forKey:)allKeys()changedKeys()makeIterator()CKRecordKeyValueIteratorCKRecordValueProtocolCKRecordKeyValueSettingCKRecordValue
Accessing the Record’s Metadata
recordIDrecordTypeCKRecord.SystemTypecreationDatecreatorUserRecordIDmodificationDatelastModifiedUserRecordIDrecordChangeTagCKRecord.ID