Хранение данных

NSManagedObjectModel описывает схему; NSPersistentStoreCoordinator связывает её с файлом хранилища (обычно SQLite); NSManagedObjectContext — блокнот для создания и правки объектов; NSPersistentContainer соединяет их и выдаёт главный контекст.

Мелкие настройки и флаги — в UserDefaults; секреты — в Keychain; крупные блобы — в файловой системе; графы объектов — в Core Data или SwiftData. Никогда не держите секреты или большие данные в UserDefaults — это незашифрованный plist.

NSFetchRequest описывает, что выбрать — сущность, предикат и дескрипторы сортировки. NSFetchedResultsController оборачивает его для таблицы — даёт секции и строки и через делегата присылает точечные insert/delete/move/update.

Documents/ хранит пользовательские данные и бэкапится в iCloud. Library/Caches/ — воспроизводимые данные: не бэкапится, iOS может очистить при нехватке места. tmp/ — временный каталог, стираемый в любой момент. Видео кладут в Caches.

Keychain — небольшое зашифрованное, аппаратно защищённое хранилище для секретов — токенов, паролей, ключей — а не для крупных данных. kSecAttrAccessible… задаёт, когда элемент читаем и привязан ли только к устройству. Элементы живут вне песочницы приложения.

Секретный токен — в общую группу доступа Keychain, а более крупный кэш — в контейнер App Group. Расширения — отдельные песочницы и не читают приватный контейнер приложения, поэтому это единственные общие поверхности. Всем трём таргетам нужен одинаковый entitlement App Group и группы Keychain.

save() проталкивает изменения контекста на уровень вниз — в родителя, если он есть, иначе через координатор в хранилище. save() дочернего доходит только до родителя, который тоже должен сохраниться. Несохранённые изменения теряются при завершении.

Связь Core Data соединяет только два NSManagedObject из одного контекста. Здесь note в главном контексте, а category получен в фоновом, поэтому note.category = category падает. Исправление — заново получить category в главном контексте по его objectID и там установить связь.

NSManagedObject привязан к своему контексту и его очереди, поэтому обращение из другого потока портит контекст. Не передавайте сам объект — передайте objectID и заново получите объект в целевом контексте внутри его блока perform.

Берите SwiftData для нового приложения, если можете требовать iOS 17+; к Core Data — там, где нет паритета. Это не замена, а Swift-нативный слой поверх стека Core Data — @Model использует тот же движок. Данные Core Data не выбрасывают — оба делят одно хранилище при миграции.

Data Protection шифрует файлы на диске; класс задаёт, когда файл читаем относительно блокировки. Complete нечитаем при блокировке; дефолтный CompleteUntilFirstUserAuthentication читаем после первой разблокировки. Задача в 3 ночи с Complete-файлом падает после автоблокировки телефона.

Lightweight-миграция справляется, когда Core Data может вывести отображение — добавление/удаление атрибутов и сущностей, превращение в optional, переименование через renaming identifier. Преобразования данных требуют mapping model и, возможно, policy. Версионируйте модель, проверяйте каждый шаг.

Сначала измерьте — шаблон File Activity в Instruments плюс du и замер времени обхода каталога, чтобы увидеть число записей и горячий путь. Тысячи мелких файлов стоят метаданных на файл, замедляют обход и раздувают бэкапы. Решение — объединить записи в одно хранилище SQLite или Core Data.

Локальное хранилище — источник истины, из которого UI читает и пишет; каждая офлайн-мутация попадает в устойчивый упорядоченный журнал, а не только в саму запись. Воркер синхронизации осушает его при сети — по порядку, идемпотентно через client id, с backoff-повторами — и разрешает конфликты явной политикой вроде last-write-wins.