Apple представила на WWDC23 большое количество новых вещей для разработки. Хранения данных — не исключение. SwiftData - это новый фреймворк для работы с хранением данных внутри приложения, который представляет собою новый уровень абстракции над уже существующем механизмом - CoreData. В данной статье будут описаны основные этапы работы с SwiftData, а именно: Создание моделей Установка атрибутов свойств Описание связей между таблицами Создание контейнера моделей Описание миграций Использование в сценариях Заключение Для начала работы со SwiftData, как и для работы с CoreData, необходимо создать модели данных, которые нужно хранить. Работая в CoreDara, создавать и выстраивать связей между моделями не кажется самой удобной вещью, так как необходимо было вручную прописывать и править информацию в  xcdatamodeld файле   С приходом SwiftData стало возможным  описывать все модели и связи между ними используя новый макрос: @Model  @Model позволяет генерировать схему согласно тем свойствам, которые будут описаны в рамках модели. Прямо из коробки существует поддержка таких типов, как структуры, коллекций (только value type), а также модели, которые соответствуют протоколу Codable.  В момент генерации через макрос добавляется поддержка двух протоколов: PersistentModel (для генерации схемы) и известный протокол Observable(для подписки на обновления модели)  В SwiftData были добавлены атрибуты, которые можно применять для свойств в модели. Unique - гарантирует, что поле будет актуальным для моделей, которые хранятся. Если уже существуют модели с не уникальными значениями, то необходимо в рамках миграции дедуплицировать модели. Encrypt - сохраняет значение свойства в зашифрованном типе Spotlight - включает индексацию свойства, для доступа в Spotlight(аналогично переключателю включения индексации в редакторе схемы) ExternalStorage -сохраняет значение свойства в виде двоичных данных рядом с хранилищем модели. Transient  -временное поле, которое не участвует в генерации схемы и не будет записано в БД. После описания модели и атрибутов ее свойств, идёт описание связей между моделями. Макрос @Relationships - еще одна новинка, которая позволяет описать правила удаления: Cascade -  удаляет все связанные модели. Это правило в основном используется, когда модель данных имеет большую зависимость. Оно удалит все ваши записи без каких-либо указаний, если ваш объект связи будет удален. Nullify - зануляет ссылку на модель, с которой была связь. Deny - предотвращает удаление модели, поскольку она содержит одну или несколько ссылок на другие модели. Можно сказать, что полная противоположность работы с каскадным удалением. NoAction  - не вносит изменений ни в какие связанные модели. Однако Apple в документации явно говорит, что: Убедитесь что вы выполняете соответствующие действия со всеми связанными моделями при использовании этого правила удаления, например, удаляете их или аннулируете их ссылки на удаленную модель. В противном случае ваши данные будут в несогласованном состоянии и могут ссылаться на несуществующие модели. (оригинал) Теперь поговорим про то, как можно взаимодействовать с данными через SwiftData. ModelContainer управляет схемой приложения и конфигурацией хранилища моделей. Кроме этого контейнер отслеживает все изменения в моделях и предоставляет большое количество действий для работы с ними, а именно: Отслеживание обновлений данных Извлечение данных Сохранение данных Откат изменений Существует два способа создания контейнера: Простой. Для создание контейнера необходимо передать список моделей (или одну модель), схему для которой необходимо сконфигурировать. Чуть сложнее: Необходимо передать модели для генерации схемы а также ее конфигурацию. Она включает в себя:  Работа в inMemory режиме Необходимость интеграции с CloudKit Работа в режиме ReadOnly Любое приложение развивается и хранилище данных вместе с ним. Для того чтобы обновить модель данных для нынешних пользователей приложения, необходимо проводить миграцию данных. Существует два основных вида миграции: Легковесная(автоматическая) миграция (например, расширение контракта, перевод неопционального поля в опциональный) Ручная миграция (например, установка атрибута unique, изменение типа данных) Для того чтобы применить миграции, необходимо создать перечисление, который будет соответствовать протоколу SchemaMigrationPlan. Для реализации протокола необходимо указать: Массив schemas, который содержит перечисление всех Схем приложения, которые были созданы. Массив stages, который содержит реализации миграций:  Легковесная миграция Ручная миграция В итоге должен получиться следующий код: Необходимо добавить план миграции в конфигурацию контейнера. Для того чтобы получить данные достаточно, использовать новый макрос Query. Обычный сценарий: стартовый экран со списком элементов, который необходимо наполнить данными, согласно схеме. Для доступа к данным из контекста есть возможность обратиться через FetchDescriptor (iOS 17.0+), который содержит дженерик, удовлетворяющий протокол PersistentModel. FetchDescriptor принимает в себя: Новый предикат (типизированный, через конструктор) Порядок сортировки Для сохранения/удаления/изменения необходимо получить инстанс из контекста. При выключенном автосохранении необходимо, как и при использовании CoreData, вызывать метод save() в контексте. При первой прикидке кажется, что релиз SwiftData поспособствует понижению порога входа для использования CoreData. К тому же добавит больше безопасности в работу с хранением данных, извлечением, в тоже время оставит возможность для сложной работы с различными видами контекстов и продвинутыми режимами работы. Но при всех очевидных плюсах закрался один существенный недостаток: минимальная версия начинается с iOS 17, что делает использование  SwiftData непозволительно дорогим для крупных приложений, но почти идеальным решением для работы над различными pet-проектами. Meet SwiftData—WWDC 2023 Build an App with SwiftData - WWDC 2023 Migrate to SwiftData - WWDC 2023 Проект с примерами использования SwiftData iOS Developer Yandex.Market