This post is an overview of what I have learned about security and scope when working with CloudKit.
At the top of the silo is a single Cloudkit container and it has three databases: Public, Private and Shared
With this post, I’ll focus on the first two and go into the Shared database in another post
The Public database is one big database that all of the app’s users have access to. The Private database is unique to each user of the app and is tied to that user’s iCloud account. The storage limits of each user’s iCloud account applies to their private database for your app.
Each Record Types has a Security setting. A matrix with roles (World, Authenticated, Creator, plus any custom roles you add) and types (create, read, write). By default, create is allowed for Creator and Authenticated. Read is allowed for World, and write is limited to just Creator.
These settings can be changed in the CloudKit dashboard. Each Record Type has its own security role settings (Individual records do NOT have security settings, only the record type).
World is what you would expect, everyone has access.
Creator refers to the creator of a particular record instance (NOT the owner of the CloudKit account).
Authenticated refers to any user who is logged in with their Apple account. No authorization is applied, any and all users with an Apple account will have permission.
Custom allows you to create your own roles in the Security Roles section. After creating a new security role, add users to the role in the User Records section. If your app doesn’t implement discovery, then you will only see users represented as hashes.
You can identify your own hash by creating a record, find it in the CloudKit database, look at the value in the Created By field and find the matching entry in the User Records section.
Security roles only apply to the PUBLIC database. Since the Private database is unique to an app’s user, then that user will be the creator for all the data and subsequently the sole person to read and write to the database.
Multiple records live in a zone and multiple zones live in a database. The Public database has only the default zone.
While Private databases have a default zone, they are also allowed custom zones. Your application can create and upload custom zones into the database.
The choice of the database and zone will have an effect on the types of remote notifications that are available.
In can be difficult finding answers to questions about CloudKit on the web. But A lot of CloudKit information is covered in the WWDC videos. Here’s a brief description of the videos available and what they cover.
What’s New in CloudKit - Session 704
CloudKit Tips and Tricks - Session 715
Descriptions and clarifications of databases
A detailed walkthrough of a CloudKit exchange (emphasis on error handling)
A description of the two types of subscriptions:
• zone subscriptions
• query subscriptions (based on a predicate).
Using CKOperations and batching requests
What’s New with CloudKit - Session 226
Improvements to APIs:
• long-live operations
• improved queries across multiple zones
A new Shared database
Overview of zones
Permissions and permission profiles
Deep dive into sharing
CloudKit Best Practices - Session 231
More depth on using CKOperations
Workflow description between client and server
• custom and shared zones
• integration with subscriptions
• remote notifications
• change tokens
References between records for one-to-many relationships
More on error handling and query retries
Build Better Apps with CloudKit Dashboard - Session 226
Overview of changes to CloudKit dashboard
GDPR & CloudKit - Session 703