Question

I am trying to backfit my app (already on the AppStore with customers using it) with a more robust back end, either CoreData or SQLite (either one would work from a performance standpoint). To date I have used archiving (flat files) to store my custom objects.

I do not have a working knowledge of SQL and I do not have a lot of time. Since I will need to come up to speed on either SQLite or CoreData should I bite the bullet and just go for CoreData since it looks like that will be easier to work with in the long run and I’m assuming would take me the same amount of time to come up to speed? The data model is not that complex.

Thanks

Answer 1

Core Data has a little bit of a learning curve if you’re not familiar with similar abstraction layers.

I’ve used both SQLite and Core Data in two different apps – the first app I didn’t know Core Data, so I used SQLite. It was straightforward, but there is a lot of code to be added to “make it work” — i.e. bridge between SQL and Objective-C. I recommend the FMDB wrapper, which is what we used.

The second app we got tired of trying to tune SQLite and decided to try Core Data. It was frustrating at first, but after you get the hang of it, it’s a lot less code up front to get your objects in and out of the data store.

My choice for all apps moving forward would be Core Data.

The bad news in this answer is that if you’re familiar with neither, I don’t think there is any “quick” solution as you may have hoped. The good news is that the sooner you start with Core Data, the sooner you can learn it and use it in new apps.

Finally, the best way to retrofit like this is unit testing, so you can swap modules/methods in and out. I recommend GHUnit if you’re not already using it.