In my application I need short list of objects of class Person. Each Person has a few properties like name, firstName, age and so on.
So far all objects were hard coded in Objective-C and added to an NSMutableArray.
This approach works perfect for my needs since I don't need to add any additional objects during runtime.

Somehow I had the idea of working with a plist instead of hard coded objects may be a much better idea and so I created a plist from my array.
To my supprise the plist file was not exactly small and now I wonder if working with hard coded objects may be the better approch.

I don't need any Core Data (I guess) since all I need is a list of objects that will never change and should not be modified by the user.

3 Answers
3

you can have many plist in your project and easily switch by code to the plist you want to load. Usefull for example when testing your app with multiple pools of datas, or for example to have one plist for each localization (one for english, one for spanish, one for chinese, etc...)

You can load/unload the datas, so they don't get stuck into memory

You can save a plist file, modify it for any reason, and restore it, without loosing the "real" app code you did modify.

But... if your hard-coding is ultra clean, with static datas stored into a custom class, with its accessors, etc... all of this will apply to your custom class (it can be saved as an invidual file, loaded into memory then released, localized, ...), so then the plist files won't have any visible benefits.

I had a similar situation myself and went with the plist in the end. It took many lines of repetetive code out of my app startup (which was the biggest benefit for me) and made adding or changing items later on much easier. I'd be surprised if, byte-for-byte, it took significantly more "characters" to do it in a plist versus code (obviously the code is smaller when compiled, but what are we talking about, a few kilobytes?).

A property list is also a graph of objects, except those objects are generic containers and not a model of your project domain. So they are not smaller or easier to work with. The size of the plist in disk is not important because you only have to deserialize it once, which will be nearly 0% of your application lifetime, and it's also negligible because you are not dealing with a big amount of data.

If you are trying to use a plist to achieve more flexibility (maybe for unit testing), you can implement NSCoding, and archive/unarchive to binary plist.