Should I save in plist or Core Data?

Question

I'm wondering if I should save data in my app to a plist or using Core Data..

My app is just basically saving tweets from timeline and other users now. Which is less than a few hunderd kB (about 200 kb in my testing). What's the advantages of using core data?

Haem

Answer 1

I would not consider plists for anything other than saving simple preferences and really basic data structure. Plus performance wise, retrieving and saving data to plists can be quite slow.

After struggling with Coredata for a long time, now that I finally get it I would choose it over anything any day. Yes it does have a bit of a steep learning curve but there is so much you get "for free" with it, I'd definitely invest the time to learn and explore it.

Coredata will give you flexibility to expand your object models as needed, easily fetch objects from the persistant storage based on certain parameters, create relationships between models, memory management and the list goes on.

Coredata is really well documented by Apple so you will find everything you need to get started plus more. There are examples, sample projects, videos, you name it - so I'd definitly recommend you have a look IF you are interested in performance, scalability and having a bit of fun too :)

Nantucket

But is it really worth it for a few hunderd KB of data? I'm also planning to do Core Data at some point, but I only have a few more weeks until beta testing... So do you think I should stick with plist? – Haem

Well it's not like you can't decide to move to Coredata in the future should the need arise. If you need speed to market right now, go with plists as it will be a piece of cake to implement. – Nantucket

CoreData is excessive for a non-complex use case like this that only involves a couple of hundred KB. There is nothing wrong with using a plist in this situation. Many apps, including Apple's, have used plists for much larger amounts of data, without obvious performance problems. Keep It Simple, people. Use CoreData where CoreData is needed. Otherwise, use the simplest approach possible. – Evapotranspiration

Answer 2

just some advices that could help in your app design.

First of all would be nice to underline that CoreData is not really comparable with plist. What I mean is that CoreData is like a data model abstraction layer over your data storage that allow you to manage relationships and fetching rules between different data entities. Behind the CoreData layer, your data storage could be based on plist (osx only), sqlite database or binary object.

This is also important because help you to understand the scope of CoreData: if you need to keep logical relationship between different data entities or perform multiple queries over the same data or serialize/deserialize big data structures, CoreData provides the best and fastest solution to make it happen. If you just need to store a plain list of items that just need to be displayed, a bounce of plist file should be enough.

Another important decision point is the type of data you need to store: according to Apple, plist files are optimized for strings, numbers, dates and some binary data. This is what Apple says about plist:

Note that property lists should be used for data that consists primarily 
of strings and numbers. They are very inefficient when used with large blocks 
of binary data.

Many applications require a mechanism for storing information that will 
be needed at a later time. For situations where you need to store small 
amounts of persistent data — say less than a few hundred kilobytes — property 
lists offer a uniform and convenient means of organizing, storing, and 
accessing the data.

It means that if you need to store "heavy" stuff or complex objects and manage them (like search trough them), the caching system of the plist parser could be inefficient (mostly on iOS).

In my opinion, your idea to store around 200k of linear tweets (around 1000 tweets?) from a timeline will works fine with a plist based solution. Also consider that the plist parser is strongly accelerated with small data structure then you will have better performance and low memory usage (mostly during startup) because you don't need to initialize CoreData nor any other "code wrapper" around your data storage. Just a simple on-the-fly usage of NSDictionary, NSArray and so on.

Last but not least, the plist implementation is cheap enough to give you the possibility to move on CoreData in a next step.

What I mean is that sometimes it's not necessary to use a tank if you need to catch some flies :-)

Hope this helps. Ciao!

Woald

Answer 3

As already noted, writing to a plist and reading from a plist is almost trivial using NSDictionary. So that might be a good way to start.

That said, if your data model starts getting richer with additional attributes and relationships, then Core Data would provide better scaling and better support. Xcode makes it very easy to design your object model (schema) - and will even generate source files, should you decide to subclass NSManagedObject (which I almost always do).

Bottom line: Plist will get you up and running faster; Core Data will give you lots of power when the time comes.

Fantoccini

You guys are making me wish I have more time... I really want to learn Core Data now, but maybe I won't use it in this app since I have to ship it in a few weeks. – Haem

I came to the same conclusion. One of my apps had a small set of some basic data, so I opted for using plists rather than Core Data. In general, I think it's best to only leverage more complicated, more powerful APIs/features if really need them. – Milagro