Bulk-import large JSON into Core Data efficiently

WHAT THIS TESTS This verifies you know how Core Data offers store-level batch operations that skip the object graph entirely, and that you understand the correctness trade-offs that come with bypassing the managed object lifecycle.

A GOOD ANSWER COVERS The specialized API is NSBatchInsertRequest, introduced in iOS 13. Instead of allocating an NSManagedObject per record, registering it in the context, and saving, which holds every object in memory and is slow, the batch insert pushes rows directly into the SQLite store. You supply either an array of dictionaries or, better for large data, a per-object dictionary handler that the request calls repeatedly until it returns true, so you stream records and keep memory flat. You run it on a background context so the UI never blocks. The benefits are dramatic memory reduction and speed because there is no object materialization, change tracking, or undo overhead. The limitations are important: it bypasses validation and willSave or awakeFromInsert hooks, does not establish relationships between objects, and does not automatically reflect into running contexts, so you must mergeChangesFromRemoteContextSave or refetch to see the data, and you should configure a merge policy or unique constraints to avoid duplicates. Related batch APIs are NSBatchUpdateRequest and NSBatchDeleteRequest.

COMMON WRONG ANSWERS Looping creates and saves on the view context, blocking the UI. Forgetting that the inserted rows will not appear in an existing fetched results controller without merging. Trying to set relationships in a batch insert.

LIKELY FOLLOW-UPS How do you make new rows visible to the main context? How do you handle relationships afterward? How do unique constraints and merge policy prevent duplicates? When is a plain background save still fine?

ONE CONCRETE EXAMPLE Importing one hundred thousand contacts from JSON, a save loop balloons memory and freezes the app. Instead you decode incrementally and feed a handler-based NSBatchInsertRequest on a private background context, keeping memory nearly constant. Afterward you post the store-did-change notification so the main context merges the new rows, then run a second pass to wire up relationships, since the batch insert could not.