Live data from Hacker News

Why iOS Devs Should Consider Using Core Data iCloud sync

zaal.tumblr.com

11–20 of 34 posts

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#12
post #11

Currently downloading the referenced app (Contacts Journal CRM) to see if the hype is real.

So far the app is great, but I'll need to give it a real test run over the next week or so to see if I run into any data issues. Right off the bat I'd like to mention both something worth of appraisal yet slightly worrisome. The iCloud sync in Contacts Journal CRM gives the user an "Identity" number associated with their account. I don't have a lot of experience with iCloud but I've never seen this done before. Is this provided by Apple in the iCloud implementation? It's awesome you guys have some redundancy to protect against Apple failing with your data, but it's also kind of an indication that theres some likeliness to there being some issues with iCloud.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#13
post #5

There are a lot of alternatives to iCloud. Most of them are just backend-as-a-service, but some of them are really sync engines. Dropbox has been around a long time, and is really popular for iOS file sync. My team at Couchbase has been building mobile NoSQL databases that sync[1], for a number of years now, and our tech is used by a few apps in the app store already.[2] This preamble is to say that I've had plenty o…

Thanks for this. When I looked at the couch offerings just a few months ago, I was turned off by the need to run what looked like a lot of heavy Couch code on my devices. The mobile offerings didn't look mature. Couchbase Lite looks promising, and makes me want to look at the Couch space again.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#14

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

> No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for.

Seems like the guys who build iawriter did or maybe we're talking about something different

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#15
post #9

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

I'm extremely unimpressed with the software engineering coming out of Apple recently. So many of their major new iOS APIs either don't work (Core Data/Sync), are just not well thought through (Storyboards) or seemed to have been designed with much real world testing at all (AutoLayout). They have a great foundation in Obj-C/Cocoa Touch but I'm very quickly losing confidence in their ability to move the platform forwa…

I'm curious about what you think is wrong with Storyboards or AutoLayout. Storyboards certainly lack features so not all apps can be done with them, but nonetheless I think they're pretty solid. And AutoLayout works like magic, haven't had any problems (the IB-adds-constraints-for-you thing is annoying, but necessary)

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#16

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

Thanks for that feedback! I thought I had conveyed my own displeasure with CDIS at the end, and mentioned a few times that "only if it worked well". Maybe I should've highlighted this more to reflect my own frustrations that I've experienced so far. I just felt that the tone had gone to an extreme in the other direction (that it's completely unworkable; and even if it did, you shouldn't support it).

My point was mostly to discourage people from completely writing off the idea around CDIS, that you shouldn't work with it "even if it worked", and countering some of the incorrect assumptions that some people were making. I think there's great reasons to adopt it (theoretically), and (this might be personal opinion) I don't believe that they're too far from cracking it. I guess time will tell. I've figured out a few hacks to backup data, to recover from failed syncs, walk through users with cleaning up their iCloud containers and get devices to setup sync again. They're mostly hacks that shouldn't be required, but have gotten to the point where users mostly have a great experience with the app, and even if sync fails or they start seeing weird errors, I can recover their data and walk them through restoring their state. I've only seen 3-4 people who have lost access to their data completely, and that really sucked. But that's a risk anyone takes with any technology, home-made or provided by some other platform.

I am open to the idea that I'm maybe too optimistic about all this. But having spent a lot of time and energy on CDIS, and having my app in production supporting CDIS for a few months, I think it was valuable information to share. A lot of issues that devs might run into while testing don't actually pan out in real-world usage. People don't have their devices sitting open side-by-side, trying to edit data simulatenously. But in any case, my plan is to compile a list of all the issues I've experienced next, and maybe some of the hacks that I'm using to work around them, and do another write-up in the near future.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#17

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

> No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. Seems like the guys who build iawriter did or maybe we're talking about something different

iA Writer is document-based, and I believe these are working fine in iCloud. Things break when iCloud is used to sync Core Data based apps.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#18
post #12
post #11

Currently downloading the referenced app (Contacts Journal CRM) to see if the hype is real.

So far the app is great, but I'll need to give it a real test run over the next week or so to see if I run into any data issues. Right off the bat I'd like to mention both something worth of appraisal yet slightly worrisome. The iCloud sync in Contacts Journal CRM gives the user an "Identity" number associated with their account. I don't have a lot of experience with iCloud but I've never seen this done before. Is th…

Thanks! The ID number is only referenced in this file: ~/Library/Mobile Documents/BJ97GLR9R3~com~cjournal~icloud/Configuration.plist

It's just a reference to check if your current device is participating correctly with the rest of the iCloud container, so that you can tell if someone deleted the iCloud container behind you while the app wasn't active, the app would be able to handle that situation. It's only exposed to the user in case something is wrong and the user can quickly check this value from that plist file. In practice, it hasn't proven too useful to expose this to users, but something to build on for a future update.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#19
post #9

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

I'm extremely unimpressed with the software engineering coming out of Apple recently. So many of their major new iOS APIs either don't work (Core Data/Sync), are just not well thought through (Storyboards) or seemed to have been designed with much real world testing at all (AutoLayout). They have a great foundation in Obj-C/Cocoa Touch but I'm very quickly losing confidence in their ability to move the platform forwa…

And the problem isn't just Core Data syncing. That's misleading.

iCloud as a whole is defective, with an incredibly immature and incomplete API. You don't get any feedback to speak of. There's no way to tell if you're even interacting with iCloud or what the state of the local store is in regard to that on the server.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#20
post #9

The problems with Core Data iCloud sync are vastly understated in this article. > "Yes, there are various problems" Yes, chief among them that it doesn't work . I'm quite serious here. No one has gotten an iCloud-based Core Data store to withstand the actual multi-device usage it was designed for. We're not talking about "works, but buggy". We're not even talking about "works but is a pain in the ass". We're talking…

I'm extremely unimpressed with the software engineering coming out of Apple recently. So many of their major new iOS APIs either don't work (Core Data/Sync), are just not well thought through (Storyboards) or seemed to have been designed with much real world testing at all (AutoLayout). They have a great foundation in Obj-C/Cocoa Touch but I'm very quickly losing confidence in their ability to move the platform forwa…

[deleted]
Post reply on HN