🔢 Миграция в SwiftData: как обновлять модель без потери пользовательских данных. Когда в приложении меняется модель данных, миграция становится головной болью. Особенно если пользователи уже накопили тонны информации, которую нельзя просто выкинуть. SwiftData предлагает несколько способов справиться с этой задачей: от автоматических легких миграций до полностью ручных, где разработчик контролирует каждый шаг. Разбираемся, как не наступить на грабли. Версионирование с первого дня: Любая работа с данными должна начинаться с версионирования. Даже если у вас сейчас одна-единственная модель, ее стоит обернуть в VersionedSchema. Это создает стабильную точку отсчета. Потом, когда появятся изменения, будет понятно, откуда и куда мигрировать. Обычно схемам дают номера версий: V1, V2, V3. В коде они живут как отдельные enum со списком моделей и идентификатором версии. А для удобства в основном коде используют typealias, чтобы каждый раз не писать ExerciseSchemaV5.Exercise. Новую версию стоит заводить перед каждым релизом, в котором меняются модели. Даже если изменений несколько, они все могут войти в одну версию схемы. Главное чтобы пользователи, пропустившие пару обновлений, могли переехать сразу в актуальную версию без потери данных. Когда SwiftData справляется сама: Есть изменения, которые SwiftData умеет обрабатывать автоматически. К ним относятся: 🔵Добавление опционального поля (старым объектам просто ставится nil). 🔵Удаление поля (данные теряются, но миграция проходит гладко). 🔵Переименование поля (если указать @Attribute(originalName:)). В этих случаях можно либо вообще не писать миграционный план, либо добавить его для порядка, но использовать легкий этап .lightweight. План может пригодиться, когда хочется четко контролировать все шаги и тестировать их. Когда нужна ручная работа: Легкая миграция перестает работать, если новое поле обязательное и без значения по умолчанию. SwiftData не может придумать, что туда записать. То же самое когда нужно преобразовать данные: изменить тип, разбить одно поле на несколько, смержить сущности, почистить дубликаты. В таких случаях пишется SchemaMigrationPlan с кастомными этапами. У каждого этапа есть две фазы: 🔵willMigrate - выполняется до применения новой схемы, работает со старыми данными (можно почистить дубликаты). 🔵didMigrate - после применения, здесь уже доступны новые модели и можно заполнять поля. Например, если в новой версии появилось обязательное поле createdAt, в didMigrate проходим по всем объектам и проставляем дату. 🔗 Читать подробнее 💡 Вывод: Миграции в SwiftData - это не про героизм, а про аккуратность. Если с самого начала заложить версионирование и продумывать изменения, большинство проблем решаются либо автоматически, либо небольшими кастомными этапами. А для самых сложных случаев всегда можно разбить задачу на несколько версий, чтобы не переписывать все за один раз. Главное - не забывать тестировать на реальных данных, а не только на пустой базе в симуляторе. ➡️ Подписаться на канал Мобильный трудоголик