Core Data: An Object Graph, Not Just a Database

WHY IT EXISTS Apps need to manage complex model data beyond just saving it to a file. They need to track changes, handle relationships between objects, and manage memory efficiently, especially with large datasets. Core Data was created to solve this object lifecycle and persistence problem on Apple platforms.

THE MENTAL MODEL Think of Core Data as a sophisticated manager for your in-memory model objects. Its main job is to manage an "object graph"—a network of interconnected objects. Persisting this graph to a database like SQLite is just one of its features, not its sole purpose. You work with model objects in a "context" or scratchpad, and Core Data handles the persistence details.

HOW IT WORKS You define your data model in a visual editor, creating "entities" (like classes) with "attributes" (properties) and "relationships." Core Data generates NSManagedObject subclasses for you. You interact with these objects through a NSManagedObjectContext. You fetch, create, and modify objects in the context. When you're ready, you "save" the context, and Core Data translates those changes into operations on the persistent store (e.g., a SQLite database). It automatically handles change tracking, validation, and faulting (lazy loading of data).

WHEN TO USE IT Use Core Data for applications with complex, interrelated data models that need to be persisted. It excels at managing object graphs, providing undo/redo support out of the box, and handling large datasets efficiently through faulting. It's a great choice for document-based apps or apps that cache significant amounts of structured data from a server.

WHEN NOT TO USE IT Avoid Core Data for very simple data persistence needs, like storing user preferences (use UserDefaults) or a single blob of data (use the file system). If your data has no relationships and you just need key-value storage, Core Data is overkill. If you need direct, raw SQL access for complex queries or want to share a database with non-Apple platforms, a more direct SQLite library might be better.

ONE CANONICAL EXAMPLE Apple's Mail app. It manages a complex graph of Accounts, which have Mailboxes, which contain Messages. When you view a mailbox, Core Data fetches a list of message objects but not their full content. This is called "faulting." When you tap a message, Core Data then fetches its body from the store on demand. Deleting a message is tracked in the context, and saving persists that deletion to the database.