A collection of Core Data resources I found genuinely useful back in 2011, plus a pre-populated-store pattern that still works. I’ve re-checked every link for 2026 and marked what happened to each one.
Apple resources
- Core Data documentation — the current home of everything Core Data. Apple retired the old /library/mac/ deep links (the classic Core Data Programming Guide and NSManagedObjectModel article pages now 404 or redirect to the archive root), so start from the topic page.
- Efficiently Importing Data — Apple’s classic import-performance article has also been retired from the docs. Its advice is still worth knowing: import in large batches rather than one object at a time, save the context periodically instead of per-object, and defer validation until the import completes.
Blog resources
Importing data into a Core Data project (the 2011 workflow)
- Create the model in Xcode first — it is essential to do this before importing, because Xcode uses a specific naming convention and adds several underlying tables to the data model.
- Run the app in the Simulator and, with it running, copy the SQLite database out of the app’s Application Support folder. Note: the pre-Xcode 6 path below is long gone — simulator devices now live under
~/Library/Developer/CoreSimulator/Devices/.
- Open the database (I used the SQLite Manager plugin in Firefox back then; today, DB Browser for SQLite does the job).
- Import your data from a CSV file once the CSV column names match the table names.
- Look at the CoreDataRecipes sample code for including a pre-populated database (the interesting part is in the app delegate).
- Ship the database inside the app bundle and you should be good to go.
The pre-populated store pattern, for the record
This is the boilerplate every Xcode template generated in 2011: on first launch, copy a bundled SQLite file into the Documents directory and hand it to the persistent store coordinator.
/**
Returns the persistent store coordinator for the application.
If the coordinator doesn't already exist, it is created and the
application's store added to it.
*/
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
if (persistentStoreCoordinator != nil) {
return persistentStoreCoordinator;
}
NSString *storePath = [[self applicationDocumentsDirectory]
stringByAppendingPathComponent:@"Recipes.sqlite"];
/* Set up the store. For the sake of illustration, provide a
pre-populated default store. */
NSFileManager *fileManager = [NSFileManager defaultManager];
// If the expected store doesn't exist, copy the default store.
if (![fileManager fileExistsAtPath:storePath]) {
NSString *defaultStorePath = [[NSBundle mainBundle]
pathForResource:@"Recipes" ofType:@"sqlite"];
if (defaultStorePath) {
[fileManager copyItemAtPath:defaultStorePath
toPath:storePath
error:NULL];
}
}
NSURL *storeUrl = [NSURL fileURLWithPath:storePath];
NSError *error;
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:[self managedObjectModel]];
if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:storeUrl
options:nil
error:&error]) {
// Handle error
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
exit(-1); // Fail
}
return persistentStoreCoordinator;
}
Note the 2026 view: since iOS 10,
NSPersistentContainer (or
NSPersistentCloudKitContainer if you sync) replaces all of this boilerplate — and for a pre-populated store you simply point its store description at a bundled SQLite file, or set
shouldAddStoreAsynchronously and seed it on first launch. The underlying trick — the Core Data SQLite store is just a SQLite file you can prepare offline — is exactly the same.