iOS Architecture for data management

[phr0ze]

I'm about to start working on my first iOS app. However there is one question I can't answer without experience. Keep in mind I prefer this app to be able to sync data to multiple devices using iCloud or some service which I don't have to maintain.

Use one database or individual files?

One database specific questions:
Will the entire database load in ram?
SQLLite directly or CoreData?

The only downside I see with individual files is file management. I mean I can essentially hide actual file management aspects from the user and make it look like a database, but my application needs to keep track of these files. I could easily see thousands of files being needed.

 

[MattInOz]

I'd suggest...
Start with Core Data until you know enough to know why not to use it.
Or why to keep using it.
Same could be said about using plist files as well.

It really depends on your data.
What is the users expectation of the data, is it contained in documents they might focus on, or is it like a big shoe box?

But Core Data handles a lot of issues you raised. It handles turning data blobs on disk and turning them in to an object use can use with Obj-C APIs. It handles freeing up memory when objects aren't needed, and on the flip side tries to help in batch fetching information off disk so your not hitting the "disk" as much. Plus iCloud is geared around in part syncing Core Data stores, with lots of good tutorials on Using Core Date Shoe box style with iCloud.

There are good tutorials out there on UIDocument the other major way to store reasonable amounts of data in iCloud. UIManagedDocument which is a mix of the two, is not so well covered.

 

[phr0ze]

Thank you. I'll use Core Data and go from there.