Core Data: Overkill for simple, static UITableView-based iPhone App?

Question

Hello!

I have a rather simple iPhone app consisting of numerous views containing a single, grouped table view. These views are held together in navigation controllers which are grouped in a tab bar. Simple stuff.

My table views do little more than list text (like "Dog", "Cat" and "Weasel") and this data is being served from a collection of plists. It's perhaps worth mentioning too that these tables are 'static' in the sense that their data is pre-determined and will only ever be amended—and if so, very rarely indeed—by the developer (in this case, moi).

This rudimentary approach has reached its limits though, and I think I'm going to need something a bit more relational. I have worked a tad with Core Data in the past, but only with apps whose data is determined by user input.

I have four closely related questions:

1. Is Core Data overkill for an app consisting mainly of a selection of simple table views?
2. Do you recommend using Core Data to manage data which is predetermine and extremely unlikely to ever change?
3. Can one lock Core Data down so that its data can't change, thereby relinquishing my responsibility as the developer to handle the editing and saving of the managed object context?
4. How do I go about giving Core Data my predetermined data, and in a format I know that it can work with?

Thanks a bunch guys.

Answer 1

You might consider using the SQLite API directly, rather than Core Data, as it may be easier to pre-populate a database that way. You can create and modify a SQLite database on any platform (Mac, Windows, Linux), and just copy it to your application's bundle as a resource.

You can find tutorials/examples that will create a user's database by copying a SQLite database out of the application bundle. In your case, you can just use the one in the bundle. Just be sure to open it read-only.

Answer 2

You should read why NetNewsWire switched

The two main takeaways from that post:

I bet Core Data is the right way to go 95% of the time. Or more. It’s easy to work with. It’s fast (in most cases).

And:

(Rule: always work at the highest level possible.)

Answer 3

I would recommend sticking with plists since your data will rarely change and when it does it will be developer-driven.

1. Core Data is very powerful, but there will be a moderate amount of plumbing and infrastructure you'll need to set up to make it work.
2. Core Data places its store outside of your app bundle (as it must to run on the iPhone), so all new installations will need to load data into the store on the first run. This data will probably have to be stored as resource plists anyway, so you aren't saving yourself the trouble of generating those plists. Turns out that wasn't true and you can store read-only parts of the persistent store in the App bundle.

Since I don't know exactly what kinds of limitations you're running in too, Core Data may be the solution, but I'm guessing it won't be. If object relationships are the biggest difficulty you're dealing with, you should read up on object archiving as a way to store your entire object tree in a form that can easily be saved as a resource in your bundle and recreated when necessary.

Answer 4

The answer is simple. If you do not need to persistent to an out of date format (like MSWord, etc.) then you should be using Core Data. Raw SQLite is a headache that is not worth the effort 99.999% of the time.

Core Data is more efficient than plists and allows greater flexibility if the project ever evolves.

It is also very easy to pre-populate a Core Data sqlite file using a OS X machine; you know, the machine you are using to develop your application in the first place :)

NNW's use case is a singular exception to this rule that, if I were a betting man, I would bet has the Core Data team's attention and will be corrected in a future update. An update, by the way, that you will get for free if you use Core Data.