3 ms·

I implemented iCloud support in an app not long after iCloud was made available to developers. The problem with the "ubiquitous key/value store" was that you ne

I implemented iCloud support in an app not long after iCloud was made available to developers. The problem with the "ubiquitous key/value store" was that you never knew when or if the local copy would be refreshed, and you didn't necessarily get notified if it was. Therefore, if your application depended on it, you had to figure out some way to operate for an unknown amount of time and then reconcile the app's state if you unexpectedly heard back from iCloud five minutes or an hour after the user started using the app and did a bunch of stuff. I'm curious as to whether this has been improved since then (circa 2011). Another issue is that Apple would throttle your application if it made too many iCloud requests in some time-frame. They refused to specify how many or how fast the requests would have to be to get you throttled, and your program would not be informed. Actually, "throttling" isn't quite right, because that implies that your calls would just be slowed down. No: iCloud calls would just start failing with "false." So, if I'm stepping through my code and there's an iCloud call in it, can I step through it five times? Three? And how quickly?

bobbylarrybobby 3y ago
In fairness don't you always have to prepare for your user’s device to be unable to sync with the cloud? I wonder if apple imposed this limitation just to force developers to consider it even in the best of conditions.
- ShadowBanThis01 3y ago
  To your point, yes. But the somewhat hypocritical thing is that Apple says don't use iCloud for things that need to be timely, but then gives examples that absolutely require timeliness. For example, the user is watching or reading something on one device and then seamlessly picks up at the same point on another one. It's not so much that you have to prepare for network problems; it's that Apple doesn't tell you if the local key/value store EVER synced. If it synced but there was no difference between the local and remote store, you don't even get confirmation that yep, we're all good to go. At least that's how it was the last time I used it.
  - ladon86 3y ago
    That was 12 years ago! But you're spot on, because they barely changed anything in those 12 years and everyone rolled their own solutions. This year, they've _finally_ introduced a higher-level API that does what you're describing, but it's still in beta: https://developer.apple.com/documentation/cloudkit/cksyncengine https://developer.apple.com/documentation/cloudkit/cksynceng...
    - ShadowBanThis01 3y ago
      Oh man, that's unfortunate. But thanks for the info! I appreciate the link.
  - bobbylarrybobby 3y ago
    Oh... that's bad
jjtheblunt 3y ago
Perhaps this issue motivated the acquisition of foundationdb. https://www.foundationdb.org/ https://www.foundationdb.org/
astrange 3y ago
You basically shouldn't use the key value store. Besides this, it also has a very low size limit. Use CloudKit instead.
- ShadowBanThis01 3y ago
  Thanks. I figured they'd just folded the original functionality into CloudKit. How does it differ in this regard?
  - astrange 3y ago
    I mean, it's completely different, so it has none of the same problems. It might have different problems of course. Ironically FoundationDB is a key-value store internally, but you don't get access to that.

bobbylarrybobby 3y ago

In fairness don't you always have to prepare for your user’s device to be unable to sync with the cloud? I wonder if apple imposed this limitation just to force developers to consider it even in the best of conditions.

ShadowBanThis01 3y ago
To your point, yes. But the somewhat hypocritical thing is that Apple says don't use iCloud for things that need to be timely, but then gives examples that absolutely require timeliness. For example, the user is watching or reading something on one device and then seamlessly picks up at the same point on another one. It's not so much that you have to prepare for network problems; it's that Apple doesn't tell you if the local key/value store EVER synced. If it synced but there was no difference between the local and remote store, you don't even get confirmation that yep, we're all good to go. At least that's how it was the last time I used it.
- ladon86 3y ago
  That was 12 years ago! But you're spot on, because they barely changed anything in those 12 years and everyone rolled their own solutions. This year, they've _finally_ introduced a higher-level API that does what you're describing, but it's still in beta: https://developer.apple.com/documentation/cloudkit/cksyncengine https://developer.apple.com/documentation/cloudkit/cksynceng...
  - ShadowBanThis01 3y ago
    Oh man, that's unfortunate. But thanks for the info! I appreciate the link.
- bobbylarrybobby 3y ago
  Oh... that's bad

jjtheblunt 3y ago

Perhaps this issue motivated the acquisition of foundationdb. https://www.foundationdb.org/ https://www.foundationdb.org/

astrange 3y ago

You basically shouldn't use the key value store. Besides this, it also has a very low size limit. Use CloudKit instead.

ShadowBanThis01 3y ago
Thanks. I figured they'd just folded the original functionality into CloudKit. How does it differ in this regard?
- astrange 3y ago
  I mean, it's completely different, so it has none of the same problems. It might have different problems of course. Ironically FoundationDB is a key-value store internally, but you don't get access to that.