I know I’m sounding like a broken record, but it’s incredible that we were able to add a feature to our reminders app that allows us to collaborate on a reminders list. We can both create, edit and delete reminders, and we can even both edit the cover image for the list.

It only took a few lines of code, it was bolted onto an app that was not specifically built to support data sharing or even iCloud synchronization, and it just magically works. Our SQLiteData library is handling a ton of edge cases and nuances having to do with conflict resolution, tracking record zones, and listening for changes in both the private and shared iCloud databases at the same time.

Building this kind of feature used to be the kind of thing we would dread. We could have spent months building a wonderful app for our users, and the moment we release it to the world we get back the first bit of feedback from our users, which is that they want their data synchronized to all their devices, and they want to share some of their data with friends or family. Well, we no longer have to dread this kind of feature request. SQLiteData takes care of all of that complexity for you, and you can focus your attention on just building your features in basically the same way you would have prior to worrying about sync and sharing.

And it’s worth mentioning that while SwiftData does have rudimentary support for iCloud synchronization, it does not support iCloud sharing at all. This means if you use SwiftData to handle persistence in your app, you simply will not be able to support allowing your users to share bits of their data with other iCloud users. You will have to wait with bated breath for each WWDC to roll around and hope that it eventually gets added.

And you might think that seamless iCloud data sharing would have been the ultimate cherry on top of this series of episodes, but we have an additional, tiny cherry to put on top of the existing cherry. We went above and beyond when building these tools because we wanted them to work seamlessly behind the scenes without you having to worry about how they work, but we also wanted to make sure you had full access to everything happening under the hood.

In particular, while you, the user of our library, gets to simply deal with SQLite databases and struct data types representing your tables, our library has to translate all of that information into CKRecords to send out to CloudKit. And conversely, when we receive CKRecords from CloudKit we have to update your SQLite database. You typically don’t have to think about these CKRecords, but sometimes it can be handy to get access to them. They contain information that can be useful and that you don’t have access to from just your own SQLite database alone.

So, let’s see where this data is stored, what all is stored, and let’s see how it can be useful to customize our applications that make use of iCloud synchronization and sharing.