CloudKit: Structured Storage for Mobile Applications [pdf]

"For these reasons, CloudKit allows several first-party apps to run their conflict-resolution code in server extensions. This allows the app more flexibility to specify what other records and information it needs to resolve the error. In some cases, iterative resolution is performed by the extension. For example, in iCloud Drive when a client attempts to store a record representing a file and the file name conflicts with an existing file, the extension may attempt to rename the new file but in doing so may create a conflict with a different file, requiring additional resolution rounds. To facilitate server-side resolution, CloudKit stores conflicted records and server extensions are expected to clean-up such records after conflict resolution."

Interesting — I wonder if 3rd party developers will ever get access to this functionality?

Am I missing something interesting here, other than that this is from Apple, and satisfies curiosity about the details of a very large-scale deployment?

Specifically, nothing in this paper seems particularly novel from an engineering perspective.

I've never gotten a chance to try out CloudKit but it has always looked pretty cool to me, especially after previous experiences with Parse. However, it seems like it'd reallllly tie the app developer in to iOS -- e.g., let's say I launch on iOS, how do I handle Android and/or web? I understand a lot of apps go iOS-first/focused, but to tie your entire backend to Apple is a bit much (unless you have no plans to expand beyond the CloudKit offerings). From a quick Google search, it seems like there is a JS implementation but I don't see an easy way on Android. This might work great for iOS-specific apps but seems like a bit too much risk vs. other, cross-platform solutions. I do appreciate how the free tier scales with number of users -- think that's a cool approach.

Having said the above, I've always wondered why Apple doesn't have an iOS SDK for user-auth (or if they do, why isn't it more prevalent outside of the Game Center stuff). I'd much prefer to one-touch sign up for an app using FaceId (if needed/user-approved, the app could access user info, like email), then have to signup with an email/username or use another 3rd party like Google. This is especially perplexing to me after the addition of the iOS password manager (https://www.cnet.com/how-to/how-to-use-ios-11s-password-auto...) -- I think it'd be more compelling to offer password management behind the scenes in iOS (e.g, sign up with FaceId and have credentials generated/stored in password manager for off-device access; this could also encourage iOS generated passwords). There's a large chance I'm overlooking something here though, so who knows.

There are two things that have stopped me from using CloudKit in my apps in the past: 1- Despite Apple's generous free tiers, the cost of data transfer is on the app developer, and not on the user. As a developer, I see this as a liability risk. 2- Data is either completely private or completely public, there is no intermediate "team" or group that can be easily set up to share data among users.

Huh, CloudKit is backed by Cassandra. TIL.