(1) Made new CKContainer in the console.
(2) Created macOS app with an iCloud entitlement to the new container.
(3) Inflated the container’s public database with a schema and sample records.
(4) Created separate iOS app with entitlement to same CloudKit container.
(5) Fetched CKRecord objects from CloudKit and displayed results in SwiftUI.

I’ve explored CloudKit as a compliment to Core Data before. But never as a standalone store like this. My main requirement was not using the console for schema and data tasks. I had reluctantly considered cktool cli or cktool.js with some node scripts, but neither of these felt great. A companion Mac app turned out to be a much nicer solution.

Seeing the data appear on the iOS app for the first time was a good moment. I didn’t expect to get this far today!

T-minus 58 days…

So to prevent writing duplicates into CloudKit, I run this CKQuery first, and if no matches come back, I create a new record.

let predicate = NSPredicate(format: "%K == %@", recordField, recordValue)
let query = CKQuery(recordType: recordType, predicate: predicate)

CloudKit doesn’t support unique constraints on schema fields. So running my setup code multiple times led to duplicate records in CloudKit (same data with different UUIDs). So I’m going to try using CKQuery to make sure a record doesn't already exist before creating it.

I didn’t see a CloudKit API in Swift to reset the development schema. So I made a SwiftUI button that runs a shell script of xcrun cktool reset-schema. But I couldn’t get it to work.

Error executing command: Error Domain=NSCocoaErrorDomain Code=4 “The file “🧨.sh” doesn’t exist.”

It does exist. But that’s ok. For now, I will click “Reset Environment…” in the CloudKit console and move on with my day.

I thought I’d have to define a CKRecord.RecordType along with a schema of field names and types before writing any data into CloudKit. But this is not necessary because a new RecordType is automatically created and modeled after the first instance of that particular type to be saved to the database.

First checkpoint. I have a shell of a Mac app with a CloudKit entitlement. It has a single button that creates a CKRecord object and saves it to the container’s public database. And in the CloudKit console, I see the new record type with schema defined along with the sample data!

I’m breaking ground on a companion Mac app today. It’s main job is to ingest JSON records, transform them to match a CloudKit schema and write them to a public CloudKit database.

And my neighbors are jack hammering their patio, which is bringing some good build something ambiance.

I’m building a reader app for images. The content is all similar (in the same subject domain) – but coming from multiple sources, each with it’s own schema. Some is available via API, but some is only via data dump.

Phase 1 is defining a common schema, fetching all the data, normalizing it into the shared schema, and then writing it all into a public CloudKit database.

T-minus 59 days...