I’ve been programming for the iPhone for about 2 years now, and as part of the applications I have programmed I’ve used SQLite and Core Data for persistence, however there are some cases where one is better and more optimised as a solution then the other, firstly I would like to stress that I am fully ware that Core Data is not and was not designed to be a RDBMS as is SQLite, however the APIs are very handy and you can get some real benefits from using it.
So across my applications I’ve used SQLite directly with no wrapper, and I didn’t really enjoy interacting directly with the C functions within my lovely OO app.
Then I decided to learn Core Data for two reasons, firstly I wanted to familiarise myself with this framework as it is a very useful and present framework within the iOS developing environment and in terms of my career I wanted to ensure that I knew this framework, but also at a first glance it seemed like the perfect solution for my application.
In a nut shell it was an app where the user generated their own content, so creating data sets based on user interaction was quite satisfyingly achieved with Core Data, but then another layer got added to my application which was some sort of remote API sync, so now I had an remote API endpoint that could tell me some data from other users, then I had to save this to the app and refresh, update etc from the remote source from time to time, but as soon as I started integrating the concept of downloading batches of data from the remote source, I realised that Core Data wasn’t really as great as I hoped, so for example my application needed a login and then I would load your friends data from the remote source (based on Facebook friends using this application). So when I log out from the application, I would have to pass on all the objects in the Core Data store and delete them, because assuming the next login is by a different user, you wouldn’t want to show that user the previous users friends information.
There was one feature of Core Data I loved and that was the Fetched Results Controller for table views, this worked great and optimised to the max the object faulting etc…
However the problem still remained about the remote sync, downloading batches of data and saving then one by one, the deleting them to keep up to date, seemed like a lot of looping, loading and operations, especially when you consider that this would only be one SQL command to delete all the records of your friends if I had chosen SQLite for this…
So my question is, according to you what are the optimal contexts when Core Data should be preferred to SQLite and vice versa, to kick off and I’m still trying to really figure tho one out, I made a short list of apps and what I think they use:
• FaceTime for mac: it seems the data store for all the calls / missed calls, call duration, favourites, would be Core Data.
• Twitter iOS app: given the enormous set of data that a user could have in this app, I an guessing that it uses SQLite, however I could be wrong…
It seems to me that you would consider Core Data more in a user content generation scenario, and an SQLite solution in a more large set/remote data sync scenario, but sometimes these two scenarios come together in the same application, I do know of some developers mixing and matching both in the same application but I would like to get your take on this, and could anyone say for any particular apps they know one or the other is being used, as a matter of curiosity.
Lastly I am aware or other Stack Overflow questions titled “Core Data vs SQLite” etc but this is really about analysing it, thank you.
Why wouldn’t you associate the data you downloaded from your remote store with a User entity? Then, you wouldn’t have to delete the data, rather you’d just fetch the new user’s data?
Core Data is really good when dealing with large data sets. I built an app once that had 120k records in the DB and Core Data handled it like a champ—provided you fully understand how it works and how to optimize your fetches. For this information, be sure to see the related WWDC videos and docs.
Overall, I think that Core Data can handle the majority of use cases you can throw at it. Also, don’t assume that it can’t simply because you don’t see how it would—it will surprise you. In test I’ve ran, I’ve found Core Data to be faster than native SQL Code because of the caching mechanisms it uses. Always base your design decisions regarding Core Data with tests you’ve run on instruments. Just this morning I found out that something I thought would be less efficient actually was faster than doing it the “right” way.
Bottom line, if you run your app in instruments and become obsessive about optimization—based on your instruments results, not your gut—Core Data will fit most any bill.