CloudKit does seem to be Apple’s answer going forward (which makes me suspect 
Core Data sync will not improve) but CloudKit requires internet access for the 
app to work at all which I don’t want to require.

I’m not sure I understand your concerns about Dropbox. The app is single user 
so when the iOS enters the background, I can upload the data (if there’s a 
network connection at the moment) for modified files to Dropbox. When the app 
starts I can check Dropbox (or warn the user that there may be a newer version 
on Dropbox if there’s no internet connection) to see if the document files are 
newer on Dropbox. It’s not as clean as a pure sync but gives the user more 
control over their data (which is important for my app).

Dave



> On May 10, 2015, at 1:37 PM, Alex Kac <a...@webis.net> wrote:
> 
> I would try CloudKit. Its super simple and far simpler than using Dropbox. 
> Plus using Dropbox you end up with lots of issues going forward that you 
> don't want to mess with. Different database versions, data that is not 
> written to disk when you make the copy due to disk caches, and a lot more. 
> 
> CloudKit is Apple's solution for sync between Apple devices. CoreData sync 
> over iCloud was never going to work well. I loved the idea, but as everyone 
> knows its implementation wasn't really foolproof. Many of us realized that 
> the better solution is a cloud sync that we designed ourselves. Apple 
> providing CloudKit solves that for Apple-only users. 
> 
> 
> 
> On Sun, May 10, 2015 at 7:16 AM, <davel...@mac.com> wrote:
> 
> Thanks MIchael. That's what I was afraid of (i.e., that Apple doesn't make 
> this straightforward). I first looked at BSManagedDocument 2-3 years ago but 
> never got around to trying it for my original app as I kept hoping Apple 
> would have an official solution to this problem.
> 
> Also thanks to Jens Alfke for his reply about Couchbase Lite 
> (http://www.couchbase.com/nosql-databases/couchbase-mobile). I may look into 
> it but after skimming the site, I couldn't tell exactly what I would need 
> (i.e., would I need to setup my own server or use a server that your company 
> provides, etc.). I doubt my app would generate enough income to even cover 
> the server costs. My apps are for teachers and I write them because I want to 
> use them myself but they don't generate much money given the fairly narrow 
> target audience and that many schools provide systems the teacher has to use 
> for the tasks (i.e., my existing iOS apps, Attendance and Attendance2 are for 
> taking attendance in class and generating reports, etc.). Jens, I may send 
> you an email off-list with a few more questions (that you can ignore if you 
> want).
> 
> I may just end up using Dropbox without sync (i.e., have the user send the 
> data to Dropbox from the iOS app) when they want to use it on the Mac and 
> import the data from Dropbox into iOS after the data has been changed on the 
> Mac. It's not elegant but it's better than risking data corruption via an 
> automatic sync that isn't reliable. Perhaps with some warnings about which 
> data is newer by looking at modification dates from the file metadata, it 
> could be usable. The app is mainly intended to be used on iOS but I want to 
> use the Mac for one or two features that would not work well on iOS.
> 
> Dave
> 
> 
> > On May 7, 2015, at 10:57 AM, Michael Swan <michaels...@mac.com> wrote:
> >
> > Dave,
> > Unfortunately on the OS X side with iCloud, Core Data, and documents it is 
> > pretty much a pick any two situation. The iOS side can be done but there 
> > are some gotchas not really covered in the documentation. I've actually 
> > just started work on my own custom subclasses of UIManagedDocument and 
> > NSDocument (NSPersistentDocument is less than useless if you want to share 
> > with iOS). My current plan is to use Apple's code as much as possible 
> > without adding extra stores like Ensembles does. If you're interested we 
> > could talk about a collaboration to build an open sourced set of classes to 
> > handle this area. (I plan to include a file browser for iOS as well since 
> > nothing currently exists.)
> >
> > On iOS you set two keys in the options dictionary to tell the system where 
> > to keep the change logs and what the name should be. The name is typically 
> > a UUID and the location is generally some version of ChangeLogs at the root 
> > level of the ubiquity container. The catch is that your can't set those 
> > options in configurePersistentStoreCoordinator… and have it come out right. 
> > You have to init the document then set the persistentStoreOptions property 
> > to a dictionary with those keys in order for the file package to get the 
> > right structure. You also need to create the document locally first and 
> > then move it to the ubiquity container.
> >
> > On OS X NSPersistentDocument can only make flat files, not packages like 
> > UIManagedDocument (I've filed a bug about there being no counterpart to 
> > UIManagedDocument for OS X, been open for over a year now…). 
> > BSManagedDocument will create a file package that looks like a locally 
> > stored UIManagedDocument but it doesn't have the logic for dealing with 
> > files in iCloud (my current plan is to build a subclass of 
> > BSManagedDocument with the extra logic in place).
> >
> > Apple's answer to me when I have asked about this in he past is that it is 
> > possible to sync Core Data documents through iCloud but you have to do all 
> > the heavy lifting (I have no idea if that will change in June, but I doubt 
> > it).
> >
> > As far as entitlements go you just need the document option enabled and to 
> > ensure that both apps use the same container.
> >
> > On the Mac the documents should show up in the normal open sheet just like 
> > they do for TextEdit and Preview documents that are in the cloud.
> >
> > These guides are a good starting point:
> > Document Based App Programming Guide for Mac
> > Document Based App Programming Guide for iOS
> > iCloud Design Guide
> > iCloud Programming Guide For Core Data
> >
> > Thanks,
> > Mike Swan
> > ETCP Certified Entertainment Electrician
> > 347-451-5418
> > theMikeSwan.com
> >
> >> On May 5, 2015, at 8:54 PM, cocoa-dev-requ...@lists.apple.com wrote:
> >>
> >> Message: 3
> >> Date: Tue, 05 May 2015 17:31:23 -0400
> >> From: davel...@mac.com
> >> To: CocoaDev <cocoa-dev@lists.apple.com>
> >> Subject: Core Data sync between iOS and Mac apps
> >>
> >> I'm looking into options for building an iOS and Mac app that can 
> >> sync/share Core Data between them. I'm well aware of the issues with Core 
> >> Data iCloud syncing in iOS 5 and 6 and that it is supposedly better so I'm 
> >> willing to try it. The apps can have deployment targets of iOS 8 and 
> >> greater and OS X 10.10. I don't expect they'll be ready to release before 
> >> iOS 9 and 10.11 (or whatever it's called) are out. The apps will be 
> >> "document-based" in that the user can open different data files each which 
> >> should sync separately.
> >>
> >> The most detail explanation I can find of iCloud Core Data syncing is WWDC 
> >> 2013 session 207 (which apparently also applies to iOS 8) and the objc.io 
> >> issue: http://www.objc.io/issue-10/icloud-core-data.html
> >>
> >> I looked into Ensembles (http://www.ensembles.io) a bit last year and 
> >> bought a "support package. I'm also aware of BSManagedDocument (but 
> >> haven't tried using it). And I've seen this 
> >> http://ossh.com.au/design-and-technology/software-development/ but I 
> >> didn't see any accompanying code.
> >>
> >> I'm comfortable with Objective-C, Swift, and Core Data locally, but not 
> >> syncing Core Data.
> >>
> >> Is there someone where that I should look for that describes the steps in 
> >> detail including setting the proper entitlements, etc. in Xcode 6?
> >>
> >> I assume now that the iOS synced data would show up in the iCloud Drive on 
> >> the Mac - correct - or am I missing something that it is only for iCloud 
> >> Documents, not Core Data sync? I don't quite understand how 
> >> URLForUbiquityContainer comes into play on the Mac if the files now appear 
> >> local on the Mac. After the user chooses File -> Open would they navigate 
> >> to the iCloud Drive and select the file? If so, how does the code then use 
> >> URLForUbiquityContainer.
> >>
> >> Pointers to any documentation or tutorials or recommendations would be 
> >> appreciated.
> >>
> >> Thanks,
> >> Dave Reed
> 
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net
> 
> This email sent to a...@webis.net
> 
> 
> 
> -- 
> Alex Kac - President and Founder
> 
> Web Information Solutions, Inc.
> 


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to