For those interested in the replication side Cloudant and CouchDB, there is some start to documenting the protocol on http://www.replication.io. It's exciting to have more things can seamlessly replicate! Another great example is the PouchDB project (http://pouchdb.com).
Couchbase Server is different from Apache CouchDB, etc (different APIs, different use cases, etc). But our mobile database, Couchbase Lite, is sync compatible with the Apache CouchDB ecosystem, and it has a vibrant developer community: https://groups.google.com/forum/#!forum/mobile-couchbase
I'm glad Cloudant are sticking with the standard CouchDB sync protocol. Their mobile clients are based on open source code started at Couchbase, so they will be able to connect to all the existing backends, including Couchbase Sync Gateway.
There is definitely some confusion to the names and efforts there are efforts to ensure there is a clear identity for the CouchDB project moving forward. (Couchbase is not compatible with CouchDB so there will likely always be some confusion there which boils down to historical trivia more than anything.)
TouchDB & PouchDB were some of the earlier projects which extended CouchDB's reach to in-browser and on-mobile databases respectively. In those days the brand confusion problem wasn't as clear. Hopefully in the future all you'll need to know is that the projects support CouchDB replication. Cloudant is a big supporter of the CouchDB community. It made sense to build upon community efforts where they existed already rather than replace them with completely proprietary components.
"CDTDatastore is available through CocoaPods, to install it add the following line to your Podfile:
Why CocoaPods? What is wrong with a static library? Or simply adding the relevant class files to a project?
I don't want to have Ruby infrastructure just to add a bunch of files to a project! Why are Ruby folk obsessed with doing things their 'Gems' way? They bring the same mentality to Go(lang). I always hear (ex)-Ruby folk asking questions at meetups about packaging and versioning...
As long as you also pull in the dependencies specified in the podfile, you'll be absolutely fine just adding the class files to the project. I've tried to be careful to maintain that as a viable option. That you retain the option is one of the strengths of Cocoapods to my mind.
While far from perfect, I chose to use Cocoapods as it's becoming the defacto standard in the iOS community. I've used it in my apps, and have found it easier to manage my deps than a bunch of git submodules or copying source code into my projects.
The problems with static libraries on iOS have been well documented at . Essentially, that you can't build static libraries as a third-party for iOS without resorting to low-level trickery. This seemed like it would become a maintenance burden vs. the Cocoapods approach.