iCloud has obviously been having some problems. The Key-Value store works well, but the rest of the technology -- not so much.
This gist is really just an exploration of what it could take to actually have workable syncing b/t all the iDevices and Mac clients.
This is a big one. I have a hunch that architecting ANY real syncing solution requires meaningful canonical truth in the sense that you should be able to go to the main server and get the latest (canonical) snapshot of "the state of the world" and then sync against it, reconciling diffs, updating timestamps, etc.
Apple, from what I understand, chose to go with something more peer-to-peer driven. Why? Who knows.
It seems like you'd want to have a canonical view of the object-graph with timestamps indicating "last-synced" operational activity.
However, there's another issue: Iterative Core Data model changes.
When OmniGroup was bringing OmniFocus into the world, they mentioned a very specific issue they had dealing with revving the Core Data model (it took roughly 92 iterations during development).
It seems as if there's really no way to get around the dual challenges of both (1) syncing and (2) Core Data model revisions. So it seems like you'd always want the canonical truth to be available as an instantly downloadable transaction log to build the SQLite store if you revved the model between builds.
This might be naïve, but it seems that there's really no better way to deal with object-graph level diffs than using timestamps. If there's a better way, I haven't heard about it. Not saying there isn't, but I suspect that without a deep-sea dive into academic-level research, I don't know if you can do it better.
Apps will need to be told to sync when they are active. The notifications need to be queuable as well to deal with offline syncing issues where subways or airplane travel has a lot of possibilities of getting a graph wildly out-of-sync.
They're a bad idea and have essentially been abandoned by Apple. Don't support them.
Make sure that in the canonical version, there's one-and-only-one GUID. That's what should be used as the Universal Primary Key.
Drew McCormack documented this rather painfully. Make sure this is handled.
Again, Drew McCormack dove into the pain of this. Make sure this is resolved, too.
Make the syncing error messages LOUD and PROUD. Nothing obscure. Have the error messages have real payloads if you get back 200-class responses and server-side syncing fails. Have built-in verbosity for the other kinds of error codes.
If there's A LOT of offline activity, have the app simply queue up the network operations and batch-execute them once Reachability has detected the device is online again.
Rich Siegel documented this. It's pretty bad. Make sure this doesn't happen.
The offline store should exist if you choose to disassociate the app from the rest of the "cloud sync" cluster. No trashing of the data. It should just be a pure local store, oblivious to the fact that it was once part of the sync cluster.
If you choose to rejoin the sync cluster, you have to choose to replace the local store with the canonical truth. There won't be any merging. It's brutal, but it's the right thing to do b/c the deltas could be too far out of sync to have a seamless experience.