Michael Tsai raises an interesting topic: CoreData vs ARC don’t really work all that well together.

I have spent months trying to get an iOS app to work with Core Data. In doing so, I went from a single thread that handled the UI and web communications to a multi-threaded (queued in the latest incarnation, actually) thing that has independent threads for the UI, communications, and Core Data. It works now, but it was a real pain.

The problem is that Core Data not only works badly with ARC, it also does not work at all in a multi-threaded environment. And if you are using the standard iOS URL access methods, your response from the webserver is handled in a different thread from your main thread. That pretty much terminally messes up Core Data.

Having such a fundamental design limitation in Core Data seems strange in this day and age of concurrency everywhere. (Apple does document this clearly, so I am not blaming them. This is clearly a design limitation, not a bug.) Like Brent Simmons wrote: “if you were starting from scratch in 2014 … how might you do it differently?”.

As opposed to Brent, I do have reservations about using Core Data for anything. For me, the pain is simply not worth it. If you enjoy debugging exceptions thrown from concurrently running (closed-source) system code, your opinion may be different.🙂

Anyways, I started using the excellent FMDB by Gus Mueller of Flying Meat fame. FMDB is an Objective-C wrapper for SQLite that saves me from having to use the SQLite API directly. The pain is having to write code to serialize objects to the database and to un-serialze them again (sort of like the old NSArchiver/NSUnarchiver code I used to hate writing …)

The gain is total control over what goes on and not a single crash. Ever. I’m not looking back …