Choosing a server can be challenging, especially if you’re not a backend engineer but still need one for your iOS app. You may find yourself in this situation.

So, Why did I consider CloudKit?

Well, first off, it’s maintained by Apple and has been around since its introduction at the 2014 WWDC.

Apple actively uses it for various apps like Photos and Notes, which gives me confidence in its longevity and reliability. Plus, I expect it to receive regular updates from Apple.

My experience

Parse.com

I used Parse (Acquired by Facebook) and contributed to the Parse iOS SDK. I liked it, but Facebook announced its discontinuation.

Consequently, I had to migrate to alternatives like back4app or Sashido.io, which serve as alternatives to parse.com. While they were good, I encountered issues with the lack of active updates to the iOS SDK. This led me to contribute to its development, but I felt it was a waste of time. I wanted to focus on my app rather than on open-source projects.

Vapor

I like Vapor because I can create a server using Swift, which is a significant benefit as an iOS Engineer. Additionally, there are numerous helpful resources available, such as books, YouTube videos, and Udemy courses.

But why did I consider CloudKit?

Unlike CloudKit, I would need to implement server logic from scratch, including authentication, deployment, database setup, migration, and data sharing between users.

My approach

Context

• I’ve already implemented a server using Vapor to handle authentication. While working on sharing data between users, I researched an easy way to implement the invite/accept feature and found that CloudKit fully supports it.

The server I implemented using Vapor is deployed on AWS, using ECS with a Load Balancer. Its primary role is handling SignIn/SignUp and supporting user-related features such as changing passwords and usernames. All user information is saved in PostgreSQL.

For data synchronization across user devices, I utilize NSPersistentCloudKitContainer, which syncs data between CoreData and CloudKit seamlessly. This integration is very convenient and eliminates the need for manual synchronization logic.

CloudKit also supports invite and accept functionality for sharing data between users, eliminating the need to implement server-side logic for this feature.

Be aware of CloudKit topics

• Introduction to CloudKit – WWDC 2014
• Advanced CloudKit – WWDC 2014
• CloudKit Quick Start Documentation Archive by Apple
• CloudKit Documentation by Apple
• Sharing Core Data objects between iCloud users
  • Share a Core Data Object
  • Remove Duplicate Data
• Syncing model data across a person’s devices using SwiftData

Now, returning to Vapor,

I can access and edit CloudKit’s data using CloudKit Web Service. NSPersistentCloudKitContainer use a special zone called com.apple.coredata.cloudkit.zone. If you’re interested how to access it using CloudKit Web Service, you can check out Reading CloudKit Records for Core Data.

Public Data

As for public data storage, I haven’t decided yet where to store it. I’ll update you once I make a decision.

How about CloudKit costs?

Currently, the pricing seems like a black box. I can’t find pricing information on the Apple Developer website. That’s why I can’t decide where I should store public data.

If you want to know AWS costs, see my previous post.

AWS Expenses for My App

I captured pricing information by accessing the archived website.

Overage Fees

Asset Storage	$0.03/GB
Database Storage	$3.00/GB
Data Transfer	$0.10/GB
Requests per sec	$100 per 10 requests