Core Data sync between iOS and Mac apps

Discussion:

d***@mac.com

2015-05-05 21:31:23 UTC

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-***@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/gegs%40ml-in.narkive.ne

Jens Alfke

2015-05-05 23:39:00 UTC

Permalink

Post by d***@mac.com
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.

I wouldn't recommend it. The sync mechanism for Core Data is IMHO a terrible kludge, and you have zero visibility into the server-side storage nor any ability to diagnose server-side problems. I still see user complaints in reviews of apps that use iCloud sync (Ulysses is one recent example.)

On the other hand, I'm biased because I work on a competing sync solution, Couchbase Lite*. It's designed from the ground up to do sync, you can run your own server, it supports multi-user sharing, and it's all open source. It has its own Cocoa API, but you can also use it as a back-end for Core Data.

Another solution to look into is Parse**. It's apparently pretty fast and reliable, although as a hosted service you don't have control over the servers (and you have to trust Facebook to play nice with your data.)

Dropbox has a data-sync API, but they just announced that they're deprecating it and phasing it out.

—Jens

* http://www.couchbase.com/nosql-databases/couchbase-mobile <http://www.couchbase.com/nosql-databases/couchbase-mobile>
** http://parse.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.n

Michael Swan

2015-05-07 14:57:05 UTC

Permalink

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

Message: 3
Date: Tue, 05 May 2015 17:31:23 -0400
Subject: Core Data sync between iOS and Mac apps
Content-Type: text/plain; charset=us-ascii
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-***@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/gegs%40ml-in.narkive.net

This em

Sean McBride

2015-05-07 15:14:34 UTC

Permalink

Post by Michael Swan
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…).

Only a year? Mine's been open for 3 years now. Duped to <rdar://9447453> which is still open too.

Cheers,
--
____________________________________________________________
Sean McBride, B. Eng ***@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.n

d***@mac.com

2015-05-10 13:16:48 UTC

Permalink

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

Post by Michael Swan
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.
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

Message: 3
Date: Tue, 05 May 2015 17:31:23 -0400
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

Alex Kac

2015-05-10 17:37:58 UTC

Permalink

Post by d***@mac.com
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

Post by Michael Swan
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.)

Post by Michael Swan
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.

Post by Michael Swan
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).

Post by Michael Swan
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).

Post by Michael Swan
As far as entitlements go you just need the document option enabled and

to ensure that both apps use the same container.

Post by Michael Swan
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.

Post by Michael Swan
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

Message: 3
Date: Tue, 05 May 2015 17:31:23 -0400
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.

Post by Michael Swan

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

Post by Michael Swan

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.

Post by Michael Swan

I'm comfortable with Objective-C, Swift, and Core Data locally, but not

syncing Core Data.

Post by Michael Swan

Is there someone where that I should look for that describes the steps

in detail including setting the proper entitlements, etc. in Xcode 6?

Post by Michael Swan

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.

Post by Michael Swan

Pointers to any documentation or tutorials or recommendations would be

appreciated.

Post by Michael Swan

Thanks,
Dave Reed

_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net

--
*Alex Kac - **President and Founder*

*Web Information Solutions, Inc.*
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to g

d***@mac.com

2015-05-12 13:00:00 UTC

Permalink

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

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

Jens Alfke

2015-05-12 15:35:09 UTC

Permalink

Post by d***@mac.com
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.

A single-user app is less likely to encounter conflicts, but it can still happen since many users have multiple iOS devices. I frequently end up switching from iPhone to iPad, sometimes even the same app (quickly check news on my iPhone, start reading an article, go upstairs and grab the iPad so I can read the article more comfortably…) And if your app doesn’t somehow deal with this, it’s looking at potential data-loss scenarios.

You can still handle conflicts using Dropbox, it’s just trickier. You’ll need to detect the renamed version of the file that Dropbox creates — something like “MyAppData (Jens Alfke's conflicted copy 2015-05-09).db” — then open both files and reconcile any changes, then save back to the original file and delete the conflicted copy. And somehow keep both devices from doing this at the same time, or you’re back at square one.

—Jens

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email

Kyle Sluder

2015-05-12 16:48:24 UTC

Permalink

Post by Jens Alfke
You can still handle conflicts using Dropbox, it’s just trickier. You’ll
need to detect the renamed version of the file that Dropbox creates —
something like “MyAppData (Jens Alfke's conflicted copy 2015-05-09).db” —
then open both files and reconcile any changes, then save back to the
original file and delete the conflicted copy. And somehow keep both
devices from doing this at the same time, or you’re back at square one.

There was a hilarious* bug in an early version of OmniPresence where
clients a) eagerly resolved conflicts and b) did not back off if their
attempt to resolve the conflict created another conflict.

The result was that if you had two Macs running OmniPresence, and you
managed to create a conflict, occasionally both machines would just
start generating infinite duplicates of the conflicted document.

--Kyle Sluder

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.nark

Jens Alfke

2015-05-10 18:35:25 UTC

Permalink

Post by d***@mac.com
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.).

Couchbase doesn’t (yet?) offer a hosted server, although it’s pretty easy to set one up in a generic hosting environment like AWS or Heroku. Also, the replication protocol is compatible with that used by Cloudant’s hosting service.

One thing I’d like would be a lightweight turnkey replication server you could easily run on a Mac or PC. I think that would be appealing for many users, partly because they’d have control over where their data is stored. We’ve done this as a proof-of-concept (it even runs on a Raspberry Pi!) but so far it has too many moving parts for it to be something an end user can easily set up.

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This e