Synchronization and Core Data in Modern iOS Apps
I’m working on an iOS project that synchronizes a lot of data between a web service and an iPad app. We’ve relied on the advice and research in the fantastic issues of objc.io on Core Data and Syncing Data along with performance recommendations from Florian Kugler’s research into Core Data stack configuration and overall the solution is working pretty well for us at this point, but it hasn’t been without its challenges.
Throughout the project I’ve been trying to follow industry news and research to keep up with best practices, interesting sync experiments, and usage of Core Data in iOS 7. A recurring question in much of this is whether to use Core Data at all, and if not what you give up and what can you possibly gain in the process?
Brent Simmons’ series of Vesper Sync Diary posts (linked to below) cover this design and decision process in incredible detail and are well worth the read, culminating with his Hard Core post where he ultimately decides to go ahead with a SQLite based solution instead of using Core Data. When using SQLite the go to solution for Mac or iOS is Gus Mueller’s excellent fmdb framework, however another SQLite based solution with a higher level API and different approach has emerged that is well worth a look too, called YapDatabase.
YapDatabase
YapDatabase is a key-value store for iOS and OS X that is built atop SQLite. At its most basic it provides a key-value store for plain old NSObject subclasses that support NSCoding, but also allows you to customize the serialization and de-serialization process and install (or write your own) extensions to further customize the behavior of the data store. It’s built with concurrency, caching, and performance in mind so you’re not blocking the main thread and dropping frames while trying to load your data. Robbie Hanson is the main contributor to YapDatabase and I’d used his CocoaAsyncSocket framework with success on another project so decided to take a closer look at YapDatabase.
The YapDatabase wiki on GitHub provides a lot of detail about the different features of YapDatabase and how you can use it in your next Mac or iOS app. The "What is YapDatabase" article is a great place to start but the killer is "Why did we create YapDatabase". Exactly! This is one of the best explanations of why you’d want to use something other than Core Data in your app highlights the pain points you’re undoubtedly going to encounter with Core Data and a modern Mac or iOS app. The final bullet point sums it up so well,
The problem is, the entire team is forced to deal with Core Data. With other parts of the application (whether it be some networking protocol, or some custom UI component, or whatever) we could assign it to a single team member. He/she would then deep dive and solve the problem, and present the rest of the team with essentially a black box. A simple API we could use without having to understand all the details. But Core Data escapes the black box. It becomes pervasive throughout the application, and everyone is forced to know it.
The rest of the wiki is well written and does a great job of explaining basic, intermediate, and advanced topics as well as describing how you can use the available extensions to add support for relationships, views, or full text search. I’ve started experimenting with YapDatabase, am loving it so far, and definitely plan to consider using it instead of Core Data in our next project.
Vesper Sync Diary posts: 1 2 3 4 5 6 7 8 9 10 11 12 13 13.2 13.3 14 15
