If you want to develope dynamic application with a bigger data, you are probably going to use SQLite database for that. That will give you proven efficiency and technology which is used on many other platforms. You will also need to choose how do you want to communicate with the database. You can use direct SQL querries or try one of Apple's core frameworks named Core Data.
This article covers briefly some key points in dealing with SQLite on iOS.
Since Core Data is something what everyone recommends on iOS, you're probably going to start from that. After some experience with Core Data you will probably talk to yourself:
Wow, do I really need this stuff? I know SQL very well and if I would use SQL statements directly in SQLite database it would be probably faster in execution and more crossplatform. Why should I teach another complicated technology? That's weird, but I think that Core Data is slow..
.. at least I had such a thoughts.
When working with data in application you will need to perform common tasks like: insert, delete, update. Some part of work will also connected with designing database entity model and with relationships between entities. In applications bigger that small there is also another key point which calls "scalability". If you're working in a project which was not so well planned and is growing during the producing process you will need to make quite few changes in your core logic structures - this could generate much work when using not so much OO code. Additional needed feature would be also safe mechanism for working with multiple threads.
All those things could be done (more or less) easily when working with Core Data in XCode. If you're not familiar in maintaining Core Data with multiple threads I refer you to those links:
All clear, Core Data is great.. but wait a minute, one thing left - "..Core Data is slow..". Yes, that's true in some cases, even when you optimize your code quite well. Core Data is slow when you want to upload or update big chunk of data at one time. Basically that's the main problem which could lead you to use direct SQL queries in SQLite. And I think many developers are taking that route - at least to check is it worth to switch. I was one of those persons.
Ok, so we know that Core Data is slow, but that's not enought. It would be great to know how slow it is comparing to raw SQL queries. This link can give you great informations about SQLite bulk inserts written in C:
Even if we have those great informations, to be fair we need to perform tests for both Core Data and raw querries in the same environment - on the same device. So I've made such a tests and results are interesting.
Tests were made with iPhone 4 iOS 7.1.1 device. There was no additional work in application at the same time when doing database tasks. There was two cases in tests: read 50 000 records form database, insert 50 000 records into database.
|Case||Core Data||raw SQL|
|reading time of 50 000 records [s]||1,5||2,0|
|inserting time of 50 000 records [s]||31,1||2,1|
We can see that there is a huge difference in inserting time. So Core Data is really slow.. But I need to say that tests were not fair to Core Data - e.g. I was using simple variables for raw queries and objects for Core Data (since there is no other way). A lot of time was taking for memory allocation. If we would allocate memory for objects, then convert them to variables and insert in raw querries, there would be also few additional seconds during insert process. In fact object oriented code will be probably always slower than super fast code in C.
We can note that Core Data is doing a lot behind the scenes and that's why it's so slow comparing querries in C. Is it worth to spend so much time to have comfortable OO code? - it depends what are you going to develope. If you're doing OpenGL graphic engine and you need super fast inserts - go for querries in C. If you're doing app in Cocoa's higher level API's - Core Data is the best choice for you. It integrates better with iOS and this approach is opened for future releases of iOS - Apple's devs can optimize it more or even change underneath SQLite with something else.
If you know now that Core Data would fit better for you, but you still don't want to use it because it's too complex, take some time to understand it and in early steps use cool library called Magical Record. This library really helps and saves time.
I've posted on GitHub source code of iOS project for this article. It's here.