
CloudKit: Structured Storage for Mobile Applications [pdf] - mpweiher
http://www.vldb.org/pvldb/vol11/p540-shraer.pdf
======
archagon
"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?

------
trevyn
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.

~~~
therein
Yeah, looks like a simple overview; something that could have been published
in blogpost form rather than what they have chosen.

------
liampronan
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...](https://www.cnet.com/how-to/how-to-use-ios-11s-password-autofill-
feature-in-apps/)) -- 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.

------
edko
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.

~~~
jkirsteins
Regarding your second point, there is a database for sharing data between
users.
[https://developer.apple.com/documentation/cloudkit/ckcontain...](https://developer.apple.com/documentation/cloudkit/ckcontainer/1640408-sharedclouddatabase)

------
sparky_
Huh, CloudKit is backed by Cassandra. TIL.

~~~
tsurkoprt
perhaps FoundationDB?

