The macOS app is a helper tool for me to process data and manage its representation in CloudKit. But it’s currently stateless. It decodes JSON and writes directly to a public database – so I can reset the CloudKit developer environment as needed and quickly stand it back up with schemas and records.

But as I started modeling a new metadata type that isn’t represented in the source JSON, I realized the Mac app needs a data store of it’s own.

Maintaining the source schemas from each data source as its own record type has been a good choice. Now I have a small catalog of data from 3 places loaded into CloudKit. And a simple iOS app with a picker between 3 SwiftUI views – each tuned to its source. So each feels the same.

Next I’ll model some common metadata concepts from across the 3 schemas as new CloudKit record types. I’ll expand the macOS writer app to run queries against the existing data catalog, create new CloudKit metadata records and build an object graph between content and tags using CKRecord.Reference. So the iOS reader can query against these common metadata records, and get back references to records from all 3 sources.

I went down the path of trying to define a source agnostic schema, thinking I would transform all the incoming data to a common record type in the macOS app before loading it into CloudKit.

But this adds some pressure to get the data normalization “right” on ingest. Now I’m exploring an alternative approach, where I maintain a 1:1 relationship between data source schemas and CloudKit record types.

I updated the macOS writer app to publish 25 actual records to CloudKit – and in turn, the iOS reader to fetch this new data. Each record includes a title and a remote imageURL. The titles appear right away, but the AsyncImage(url:) SwiftUI View has some noticeable latency when loading images. Tomorrow I’ll try saving them directly to CloudKit as a CKAsset when I create the records and see if this improves performance.

Progress is tangible though. This morning the app only displayed temp strings. Tonight it’s showing actual content and it’s starting to feel like a real app.

T minus 57-days…

Yesterday I realized my database had duplicate records, and that CloudKit doesn’t support unique constraints. So I added a check to make sure a record doesn’t exist before writing it in. My code evolved into a mix of bits from the documentation and a few phone-a-friends with ChatGPT. It worked. But how?

Today I learned the fetch method on CKDatabase takes in a completion handler as a parameter, which gets called after the operation with the outcome of the fetch. The completion handler itself takes in a single Result parameter, which is a basic type from the Swift Standard Library.

@frozen public enum Result<Success, Failure> where Failure : Error {
    case success(Success) 
    case failure(Failure)
}

Notice the <Success, Failure> in the enum’s declaration. It’s using Swift Generics as a placeholder to represent any Success or Failure value. In CloudKit, these are defined by the fetch method to return either a tuple of results, or an error if the request fails. So in the case of .success, I get back an array of matchResults. If this array .isEmpty, a write won’t create a duplicate record.