CloudKit: What is it good for?

When I first created the try! Swift app in haste in time for my first conference in Tokyo earlier this year, I hard-coded everything. After all, what could possibly change two weeks before the conference?!!!

Well, turned out that one speaker had to cancel last minute and we had to make some last-minute speaker / presentation changes. While, it’s not the biggest deal to have one talk information wrong, I really hated that I couldn’t update any information remotely to accommodate for any last-minute changes without having to go through the app review process again (at that time, it was still two weeks). So I made that the priority feature for the try! Swift NYC app in time for my latest conference in early September.

The obvious way to accomplish this that came to mind was via some type of JSON payload. In fact, @BasThomas actually built it! However, when I mentioned this to @danielboedewadt while catching up during WWDC, he recommended using CloudKit, especially since it has the silent notifications feature. I was immediately excited to play with something new and shiny, so when it came time for me to work on the try! Swift NYC app, I selfishly deleted Bas’s JSON work and started implementing CloudKit instead.

The Business Use-case

From the business perspective, the reality is that the conference schedule would mostly stay the same. In addition, many of our attendees are from abroad with varying levels of internet access. I also had no idea how bad the wifi would be in the venue (although it turned out to be great!).

From that perspective, hard-coding / having as much information as possible on load was still necessary. I wanted users to open the app and have everything load right away without waiting for any kind of annoying spinners while waiting for updates from the cloud.


In the try! Swift Japan app, I hard-coded everything into arrays and dictionaries to load every time (after all, it wasn’t that much information). However, to be able to make updates from CloudKit in the try! Swift NYC app, I knew I needed a more robust local persistence layer.

Realm has been on my list of things I wanted to try but haven’t gotten to, so I decided to try it out instead of CoreData. Pretty happy I did! But that’s another topic.

Data Duplication?

When I started working with CloudKit, my mindset was still stuck in the typical architecture where I would have to sync all the data between the cloud and my local persistence layer. I was planning on saving hard-coded data into Realm on the first app load (since most of it was static and good enough after-all in case there is no internet connection), and then having a mirror database with all the data in CloudKit that I would sync with my local Realm database.

However, the more I thought about my business use-case and how rare it is to have the data actually change, and how expensive it would be to query everything and figure out all the changes, I came up with a much lighter use of CloudKit!


Instead of duplicating my entire database layer in the Cloud, I created a more generic Change table in my CloudKit database:

CloudKit Change Table

So for example, if the Speaker bio changed (which is the only change that happened using this system), I would create the following Change object:

CloudKit Change Create

So basically, the Speaker with id 7 (in Realm) needs to have their “bio” field changed to the new value provided.

Subscribe to Changes

On the app side, we just subscribe to any Creation changes in CloudKit to get notifications to make the update!

Now, when a Change happens, the change can be synced with the local Realm database as follows:

Not the most beautiful code, but it works…


One of the things I was disappointed with for CloudKit was how Stringly-typed it is – given that this is a relatively new native solution from Apple. I was hoping to see something closer to what Parse did. But it ended up working well with Realm subscripts that way. I think the code can definitely be improved to be less Stringy, but I was happy with this initial architecture.

I was able to create a super light updating layer with a mixture of hard-coded pre-loaded data and silent notification updates included without having to install yet another third-party solution. However, if I needed something more heavy-duty, I would have to consider Firebase or just a plain old JSON API.

Note: This blog post is more of a general architecture overview of CloudKit. For full code example, see the try! Swift NYC app source code here.

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.