Portability of Core Data's SQLite file between OS X and iPhone OS

I have an existing application using Core Data on the iPhone. Occasionally there would be updates to the application's data delivered as updates to the App Store. In my perfect wor开发者_StackOverflow社区ld, building an application to edit the data in the updates with an OS X application and copying the sqlite database to my iPhone app bundle would be a relatively pain-free way to do this.

Is it possible to move sqlite database (assuming they use the same data model) between OS X and iPhone OS?

What are the things I should watch out for that isn't portable between (like 32-bit vs. 64-bit data)?

Are there better alternatives that I'm overlooking?

---

The SQLite format is identical between Mac and iPhone applications with the same data model. It's pretty trivial to generate a Mac application to edit your database (I do this for my iPhone application). In fact, you can take your data model and quickly drag and drop an interface for it (from the Core Data Programming Guide FAQ):

In Mac OS X v10.5 and later, in Interface Builder you can drag a Core Data Entity item from the Library onto a window or box. Interface Builder then presents a panel that allows you to select the entity you want from the currently-open Xcode projects.

Note that you can also create and configure an NSController instance in Interface Builder. As in the case of creating a user interface, you Option-click an entity in the Data Modeling tool in Xcode (or select the Core Data Entity item from the Library), but you drag it to a the Interface Builder file window. For editing one object, an NSObjectController instance is created; for editing many objects, an NSArrayController instance is created.

I'd also check out Core Data Editor, which loads in your compiled managed object model and lets you edit your database from that.

---

I did exactly the same (create a core data database on MacOS, copy the sqlite file and use it on the iPhone) and it seemed to work perfectly. However, recently I ran into a performance issue that is caused by this approach and for which I did not find another solution yet than going back to creating the database in the iPhone emulator. The issue is the following:

if you have a n:m relationship between two tables then the iPhone flavor of Core data creates a link table that looks like this:

CREATE TABLE Z_13FOO ( Z_13BAR2 INTEGER, Z_15FOO INTEGER, PRIMARY KEY (Z_13BAR2, Z_15FOO) );

Whereas the MacOS flavor creates this:

CREATE TABLE Z_13FOO ( Z_13BAR2, Z_15FOO ); CREATE INDEX Z_13FOO_Z_13BAR2_INDEX ON Z_13FOO (Z_13BAR2); CREATE INDEX Z_13FOO_Z_15FOO_INDEX ON Z_13FOO (Z_15FOO);

Although it looks like the two indexes on the join table would allow fast joining between tables foo and bar I measured a performance penalty of more than factor of 100 compared to the primary key constrained version the iPhone Core Data created.

It might be that this issue is not relevant in your case, but it is something you should be aware of when analyzing performance issues as this is a not so obvious pitfall!!!

If anyone has a solution for this issue that would allow me to use MacOS Core Data to create the database as I had originally planned - please post an answer here!!!

---

Yes, you can do this. The problem cones when you need to change database schema; so you might want to consider doing a dump of the data into a different format and then reloading if you need to push out new versions.