Core Data — What It Is, Data Model and How It Works

What Is Core Data and Its Role in iOS

Core Data is an object graph and persistence management framework that is part of Cocoa Touch. Contrary to common misconception, Core Data is not a database, but an object management layer that can use SQLite as one of its stores. The main task of Core Data is to track object changes, manage their lifecycle and synchronize state with disk.

The framework provides an object graph where each Managed Object is tracked by the context for changes. Upon saving, all modified, added and deleted objects are committed to the persistent store in a single transaction. This eliminates the need for the developer to write SQL queries and manage transactions manually.

According to Swift Developer Survey statistics (2025), Core Data is used in 52% of iOS applications working with local data. Despite the emergence of modern alternatives (SwiftData, Realm), Core Data remains the primary framework in existing Apple projects due to its maturity and deep system integration.

Use Core Data for projects with a medium-complexity data model where object relationships, change rollback and automatic caching through the faulting mechanism are needed.

Core Data architecture is built around the Managed Object Context concept — a workspace that tracks all object changes. The context supports undo/redo through the built-in NSUndoManager, allowing you to implement drafts and action cancellation without manually saving state snapshots. When save() is called, the context commits all changes in a single transaction to the persistent store, guaranteeing atomicity and data consistency.

Data Model: Entity, Attributes, Relationships

The Core Data data model is defined in the .xcdatamodeld file — Xcode's visual editor where all Entities, their attributes and relationships are described. At compile time, the model is serialized into .momd and loaded through NSManagedObjectModel.

Entity and Attributes

Entity is a data type description, similar to a table in SQL. Each Entity contains a set of Attributes — named fields with a data type (String, Integer, Date, Boolean, Data). Unlike Room, Core Data requires explicit type selection for each attribute through the model editor.

Relationships

Relationship is a connection between Entities, similar to a foreign key in SQL. Core Data supports all relationship types: one-to-one, one-to-many and many-to-many. Each relationship has a Delete Rule (Cascade, Nullify, Deny) configured — behavior when the related object is deleted.

Choosing a Delete Rule is critical for data integrity: Cascade without verification can delete a third of the database, while Deny can block the operation with an unclear error. In production code, Nullify with manual orphan record handling is recommended.

In the Xcode model editor, the developer can define not only Entity and attributes but also constraints (unique constraints), indexes for query acceleration and default values for attributes. All model changes are compiled into a .momd file, which is loaded during NSPersistentContainer initialization. Model Versioning allows maintaining multiple schema versions and performing migration between them.

Core Data Stack: PersistentContainer and Context

NSPersistentContainer is a single object managing the Core Data stack since iOS 10 and macOS 10.12. It encapsulates NSManagedObjectModel, NSPersistentStoreCoordinator and NSManagedObjectContext, automating model loading and store configuration. For older versions, the stack was built manually, but this is no longer recommended.

let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores { _, error in
    if let error { fatalError("Core Data load failed: \(error)") }
}
let context = container.viewContext

viewContext is the main context tied to the main thread. All reads and UI updates are performed through it. For performance, data writing is recommended to be performed on a background child context with subsequent synchronization.

NSPersistentStoreCoordinator

The NSPersistentStoreCoordinator coordinator connects the model to the physical storage on disk. Core Data supports several store types: SQLite (recommended), Binary and In-Memory. The SQLite store supports migrations, incremental backup and crash resilience during write operations.

NSFetchRequest and Working with Data

NSFetchRequest is an object describing a query to the Core Data store. It contains the Entity name, filter predicate, sort descriptors and fetch settings. The query is executed via context.fetch(), which returns an array of NSManagedObject.

let request = NSFetchRequest<User>(entityName: "User")
request.predicate = NSPredicate(format: "age >= %d", 18)
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
request.fetchLimit = 50

let results = try context.fetch(request)

NSPredicate supports complex conditions: LIKE, IN, BETWEEN, CONTAINS[c] (case-insensitive), SUBQUERY for nested queries on related Entity. Core Data also supports NSFetchedResultsController — a class for reactive data loading in UITableView, which automatically tracks changes and updates the table with animated sections.

Core Data in a Multithreaded Environment

Working with Core Data in a multithreaded application requires strict rule compliance: NSManagedObject cannot be passed directly between threads. Each thread (or queue) must use its own context. The main approach is creating a child NSManagedObjectContext with a private queue (NSPrivateQueueConcurrencyType) for writing and viewContext for reading.

The child context saves to the parent, and then the parent saves to the disk store. This guarantees that changes do not block the main thread and that the UI always sees a consistent state through mergeChanges or automatic viewContext update upon saving.

Core Data uses faulting — a lazy loading mechanism for related objects. When fetching a User without requesting their addresses, the related Address objects are not loaded until they are accessed via dot notation. Faulting saves memory and speeds up loading, but may cause unexpected disk access on the main thread if access is not controlled in background contexts.

For efficient multithreading, use NSBatchInsertRequest and NSBatchDeleteRequest for bulk inserts and deletes without loading objects into memory — this is critical for data synchronization with the server.

Batch operations execute directly at the NSPersistentStoreCoordinator level, bypassing the context and object graph. This allows inserting 10,000 records in milliseconds without creating 10,000 NSManagedObject instances in memory. After executing a batch request, the context must be updated via mergeChangesFromContextDidSaveNotification so that the UI reflects the new data. Apple recommends batch operations for initial data loading and nightly server synchronization.

For change tracking in Core Data, NSPersistentHistoryTracking is used — a mechanism that records every transaction (insert, update, delete) in a separate history. Enabling history tracking allows synchronizing data between different processes and applications working with the same SQLite file, for example between the main application and a Notification Service Extension. Activation is done via NSPersistentStoreDescription with the persistentHistoryTrackingKey flag, and reading via NSPersistentHistoryChangeRequest with filtering by date and transaction type.

For debugging and performance profiling of Core Data, the Core Data Profiler tool from the Instruments suite in Xcode on macOS is used. It shows all fetch, insert, delete and save operations with the duration of each operation and the number of loaded objects in tables and timeline graphs. The developer can identify problem areas: multiple fetches of the same query (lack of caching), fault object leaks during table scrolling or main thread blocking due to synchronous loading of related entities. It is recommended to run profiling on a real device rather than a simulator, as the simulator's performance does not reflect the real behavior of the application on an iPhone or iPad.