I have an ios app that has alot of static content and static settings. right now, I save them in multiple plist files that I update when I release app updates. It’s convenient for me to save the content & settings in plist files rather than having them as arrays or dictionaries in the source code.
It came out that I have a plist for each module in my app and a generic plist file for settings. around 8 plist files for the entire app. mostly small plist files.
They are really small plist files and I only change them when I release an update, so I don’t see a reason why I should use core data or sqlite for it.
Does it reasonable to save all my content and settings in plist files and can it be a performance issue? Should I cache the plist data to make sure I phrase the files only once, or it’s a relatively cheap call?
If this pattern is working for you, then there’s no need to change it. There’s nothing wrong with storing your information in disparate plist files, particularly if there is no coupling between the data stored by one module and the data stored by another.
The main benefit of using Core Data/SQLite is that it is relational. It understands how your state is related to other bits of state, and provides API’s for querying, sorting, browsing, and filtering it efficiently. If your data is non-relational, however, then there is little to be gained by stuffing it in a relational database.
As for performance, if you are re-processing your plist files every time the user goes to view some bit of state, then that can be very inefficient. Personally I’d recommended keeping an in-memory array or dictionary that represents your plist state, and writing the in-memory data back to the plist whenever a change is made. Then reading is always fast, because you just use the in-memory copy.