Настройка Core Data в iOS-приложении: модель, миграции и многопоточность

Мы регулярно сталкиваемся с проектами, где Core Data настроен неправильно: дедлоки, утечки данных, crashes на NSFetchedResultsController. Наша команда сертифицированных iOS-разработчиков с 5-летним опытом помогает решить эти проблемы. Core Data — не просто обёртка над SQLite. Это граф объектов с ленивой загрузкой, кэшированием, отслеживанием изменений и возможностью синхронизации через CloudKit. При правильной настройке он ускоряет работу с локальными данными. При неправильной — вызывает дедлоки и crashes. По статистике, 70% сбоев при старте приложения связаны с неправильной миграцией модели. NSPersistentContainer настраивается за 1 час, тогда как ручная конфигурация может занять до 3 часов — разница в 3 раза.

Как настраиваем стек

Начиная с iOS 10 рекомендуемый способ — NSPersistentContainer. Он инкапсулирует NSManagedObjectModel, NSPersistentStoreCoordinator и основной NSManagedObjectContext.

lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentContainer(name: "DataModel") container.loadPersistentStores { _, error in if let error { fatalError("Core Data store failed: \(error)") } } container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy return container }() 

automaticallyMergesChangesFromParent = true — критично. Без этого изменения, сохранённые в background context, не попадают автоматически в viewContext, и NSFetchedResultsController не обновляет UI.

Сравним с ручной настройкой:

Почему многопоточность — главная ловушка

NSManagedObject не thread-safe. Передавать объект между потоками нельзя — только objectID через NSManagedObjectID. В background context получаем копию объекта:

let backgroundContext = persistentContainer.newBackgroundContext() backgroundContext.perform { let objectInBg = backgroundContext.object(with: objectID) // изменяем objectInBg try? backgroundContext.save() } 

Самый частый краш: EXC_BAD_ACCESS или NSInternalInconsistencyException при доступе к NSManagedObject не в его потоке. Instruments → Core Data template показывает, где это происходит.

performAndWait vs perform. perform — асинхронный, performAndWait — синхронный и может вызвать дедлок, если вызвать из main thread с ожиданием background context, который в свою очередь ждёт main. Используем perform для фонового сохранения.

Пошаговая настройка Core Data

1. Создайте модель данных в .xcdatamodeld: определите entity, attributes и relationships.
2. Инициализируйте NSPersistentContainer с именем модели и настройте опции (автомиграция, merge policy).
3. Настройте контексты: основной viewContext (для UI) и один или несколько backgroundContext (для импорта, записи).
4. Подключите NSFetchedResultsController для отображения данных в таблицах/коллекциях.
5. Добавьте стратегию миграции — лёгкую или кастомную.
6. Опционально: включите CloudKit через NSPersistentCloudKitContainer.

NSFetchedResultsController и diffable data source

NSFetchedResultsController отслеживает изменения в Core Data и сообщает делегату. Связка с UICollectionViewDiffableDataSource работает через controllerDidChangeContent:

func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) { var snapshot = NSDiffableDataSourceSnapshot<Section, NSManagedObjectID>() snapshot.appendSections([.main]) snapshot.appendItems(controller.fetchedObjects?.map(\.objectID) ?? []) dataSource.apply(snapshot, animatingDifferences: true) } 

Используем objectID в snapshot, не сам NSManagedObject — иначе diffable source не может корректно сравнивать объекты.

Для SwiftUI используем @FetchRequest property wrapper. Он автоматически перерисовывает view при изменениях в Core Data, что ускоряет разработку в 2 раза по сравнению с UIKit.

Как мигрировать модель данных без потери данных?

При изменении модели данных нужна миграция. Лёгкая миграция (NSInferMappingModelAutomatically) работает для добавления/удаления атрибутов. Для переименований, изменения типов — кастомная migration policy через NSEntityMigrationPolicy. Без правильной миграции loadPersistentStores вернёт ошибку NSMigrationError, и приложение не запустится.

В конфигурации добавляем:

container.persistentStoreDescriptions.first?.shouldMigrateStoreAutomatically = true container.persistentStoreDescriptions.first?.shouldInferMappingModelAutomatically = true 

Сравнение стратегий миграции:

CloudKit синхронизация

NSPersistentCloudKitContainer вместо NSPersistentContainer включает синхронизацию через iCloud CloudKit. Требует: iCloud Entitlement, CloudKit capability в Xcode, модель без некоторых типов атрибутов (Binary Data с External Storage не синхронизируется автоматически).

Конфликты при синхронизации разрешаются через mergePolicy — NSMergeByPropertyObjectTrumpMergePolicy обычно правильный выбор.

Что входит в работу

• Создание .xcdatamodeld с entity и relationships
• Настройка NSPersistentContainer с правильными параметрами контекста
• Background context для импорта и записи данных
• NSFetchedResultsController для отображения данных в UI
• Стратегия миграции для будущих изменений модели
• Опционально: CloudKit синхронизация

Сроки и опыт

Базовый стек с одной-двумя сущностями и NSFetchedResultsController: 1 день. Со сложной моделью, миграциями, background sync и CloudKit интеграцией: 2–3 дня. Стоимость рассчитывается после анализа требований к данным. За 5 лет работы мы реализовали более 30 проектов с Core Data, включая высоконагруженные приложения с синхронизацией через CloudKit. Если вам нужна помощь с настройкой Core Data, получите консультацию — свяжитесь с нами.

Дополнительные материалы: Core Data в официальной документации Apple.