Storing information over iPhone apps is a task that needs to be carefully taken and analyzed. We know an iPhone has limited resources that need to be used and released, properly. The problem is: what happens when you have an app that stores and load large amount of data (e.g, a Sales Force Automation Applications)?
We don’t know how the application will respond to these data access with the time (as the database size increases). Moreover, we have lot of third-party options of persistence layer, or layers responsible to manage data access and data mapping to objects.
These third-party options may have other problems that could resulting in performance loss with the time. So, choosing the best for each situation isn’t an easy job.
Thus, I.ndigo has decided to begin a series of performance experiments on the most known options of Persistent Store, and obviously, the Core Data purely implemented.
Searching on the web for options resulted on the following list of technologies:
| Core Data | FMDB | Magical Panda | Mogenerator | OmniDataObjects | iphone-rsdb | SQLite | SQLitePersistentObjects | |
| Abstraction level | object graph manager | SQLite wrapper | ActiveRecord (over Core Data) | object graph manager | Core Data API implementation (over SQLite) | SQLite wrapper (based on fmdb) | - | ActiveRecord over SQLite |
| belongs_to implementation | yes | yes | yes | yes | yes | yes | yes | yes |
| has_many implementation | yes | yes | yes | yes | yes | yes | yes | yes |
| many_to_many implementation | yes | yes | yes | yes | N/A | no | yes | no |
| SQL | no | yes | no | no | no | yes | yes | yes |
| Lazy Loading | yes | no | yes | yes | yes | no | yes | no |
| License | iPhone Program | MIT | MIT | N/A | MIT | Apache 2.0 | Public Domain | New BSD License |
Next posts will cover a serie of tests executed on some of these technologies and comparisons between them in several scenarios.
Stay tuned!
This post is also available in Portuguese: Visão Geral de iPhone Persistent Store
