8 Answers
8

Here's the best way (and doesn't require SQL knowledge):
Create a quick Core Data iPhone app (Or even Mac app) using the same object model as your List app. Write a few lines of code to save the default managed objects you want to the store. Then, run that app in the simulator. Now, go to ~/Library/Application Support/iPhone Simulator/User/Applications. Find your application among the GUIDs, then just copy the sqlite store out into your List app's project folder.

Won't this break your app if Apple decides to change the internals of Core Data between iOs versions (and you don't ship an update in time)?
–
Sjors ProvoostFeb 1 '12 at 9:19

I honestly doubt Apple would make a change that breaks its ability to read its own databases files.
–
Ken AspeslaghFeb 3 '12 at 19:54

Apple could migrate all existing core data databases on the device during a system upgrade, so it would still be able to read them. But such a migration might skip pre-packaged database files in new installs.
–
Sjors ProvoostFeb 8 '12 at 10:03

That wouldn't work at all Sjors. App data can be backed up on the user's computer in iTunes and restored at any time.
–
Ken AspeslaghFeb 10 '12 at 14:33

I did as you suggest, but I still get "The model used to open the store is incompatible with the one used to create the store". I actually copied the model file from one project to the other... so I'm pretty sure they are identical.
–
ZiggyJun 17 '12 at 1:25

I believe I would like the sql browser approach better because I could add different list. Ive downloaded it. Do I just add an item, name it passport and add 9 more items and then im done?
–
TannerFeb 9 '10 at 16:11

Yes pretty much, it is as easy to use as any other Database browser.
–
Oscar GomezFeb 9 '10 at 16:14

1

This answer is misleading. You can't just dump data into any old SQLite database and then load it into Core Data. Core Data has a very specific internal structure to its SQLite databases that is not documented and that you are advised not to manually write to.
–
Brad Larson♦Feb 9 '10 at 18:47

For 10 items, you can just do this within applicationDidFinishLaunching: in your app delegate.

Define a method, say insertPredefinedObjects, that creates and populates the instances of the entity in charge of managing your airport items, and save your context. You may either read the attributes from a file or simply hardwire them in your code. Then, call this method inside applicationDidFinishLaunching:.

With this method you don't need to make a separate app or have any SQL knowledge. You only need to be able to make a JSON file for your initial data.

I use a JSON file that I parse into objects, then insert them in Core Data. I do this when the app initializes. I also make one entity in my core data that indicates if this initial data is already inserted, after I insert the initial data I set this entity so the next time the script runs it sees that the initial data has already been initialized.

I've had an app rejected for copying the (read-only) pre-populated database to the documents directory - as it then gets backed up to iCloud - and Apple only want that to happen to user-generated files.

The guidelines above offer some solutions, but they mostly boil down to:

store the DB in the caches directory, and gracefully handle situations where the OS purges the caches - you will have to rebuild the DB, which probably rules it out for most of us.

set a 'do not cache attribute' on the DB file, which is a little arcane, as it needs to be done differently for different OS versions.

I don't think it is too tricky, but be aware that you have a bit extra to do to make that example code work alongside iCloud...

So I have developed a generic method that loads from a dictionary (possibly from JSON) and populates the database.
It should be used ONLY with trusted data (from a safe channel), it can't handle circular references and schema migrations can be problematic... But for simple use cases like mine it should be fine