14 июля 2026 года обновление SwiftData для платформ Apple 2027 года получило сразу три заметных добавления: поддержку сохранения сторонних и кастомных типов через Codable, секции в выборках для SwiftUI и новые механизмы наблюдения за изменениями хранилища. Как пишет InfoQ, для iOS- и macOS-разработчиков это не декоративный апдейт, а попытка закрыть несколько вполне приземленных болей: как засунуть в модель чужой тип, как не писать лишний код для секционированных списков и как следить за данными за пределами SwiftUI.
Самое практичное нововведение касается типов, которые разработчик не контролирует. Раньше у SwiftData была понятная, но раздражающая граница: если тип нельзя пометить как @Model, встроить его в модель без трюков не получалось, потому что фреймворк не умеет строить для него схему. В релизе 2027 года Apple добавила атрибут .codable, который позволяет сохранять такие значения, если они соответствуют протоколу Codable. В примере, который приводит InfoQ, тип вроде ExLocation можно положить в модель Destination как поле locationInfo и сохранить без отдельного переизобретения слоя маппинга. Для команд, которые тянут в приложение SDK, геоданные, платежные объекты или модели из внешних библиотек, это выглядит как вполне осязаемая экономия времени.
Но здесь Apple не раздает магию бесплатно, и это хороший момент, который в новости не спрятан мелким шрифтом. Поля, сохраненные через .codable, считаются для SwiftData непрозрачными значениями. Их нельзя использовать для фильтрации и сортировки. Более того, если структура такого типа изменилась, например в нее добавили новое свойство, автоматическая миграция сама по себе не сработает. Из этого следует довольно жесткий практический вывод: обновление SwiftData упрощает жизнь именно там, где речь идет о чужих типах или значениях на периферии модели. Если тип ваш и вы собираетесь по нему строить запросы, сортировки и эволюцию схемы, по-прежнему разумнее оформлять его как полноценный @Model, а не прятать внутрь Codable-контейнера.
Вторая часть релиза адресована уже не модели данных, а пользовательскому интерфейсу. В @Query появился параметр sectionBy, который позволяет группировать результаты по заданному key path. На практике это означает, что выборку поездок можно сразу секционировать по направлению, категории или любому другому полю, а затем итерироваться по готовым секциям в SwiftUI-списке. До сих пор такие вещи обычно решались либо дополнительной логикой поверх результатов, либо ручной трансформацией коллекций перед рендерингом. Теперь Apple переносит эту механику ближе к слою данных. Для продуктовых команд это не только про меньше кода: чем меньше самодельной логики между выборкой и UI, тем меньше шансов получить рассинхрон между тем, что реально лежит в хранилище, и тем, как приложение это показывает пользователю.
Третье нововведение, пожалуй, самое интересное для тех, кто давно вышел за рамки «маленького SwiftUI-приложения». В SwiftData 2027 появился ResultObserver — механизм, похожий на @Query, но работающий вне SwiftUI. Он построен на фреймворке Observation и поддерживает те же базовые возможности: сортировку, фильтрацию и секционирование. В статье приведен пример контроллера, который наблюдает за изменениями сущностей Trip и пересчитывает состояние карты. Смысл здесь простой: раньше SwiftData особенно уютно чувствовал себя внутри SwiftUI, а за его пределами разработчику приходилось строить более ручные схемы реакции на изменения. Теперь у Apple появляется более внятный мост для приложений и компонентов, где UI не завязан на SwiftUI напрямую, включая, например, сцены на SceneKit или разные сервисные объекты, которые должны реагировать на обновление данных без лишней акробатики.
Еще один слой наблюдаемости добавляет HistoryObserver. Он следит уже не за конкретным результатом выборки, а за постоянной историей хранилища и сигнализирует, когда появляются новые транзакции. Для этого у него есть наблюдаемое свойство eventCounter, которое увеличивается при поступлении новых записей в историю. После этого приложение может вызвать ModelContext.fetchHistory и забрать последние изменения. Звучит не очень броско, но именно здесь у обновления SwiftData есть шанс оказаться полезным не только для UI-разработчика, но и для архитекторов мобильных систем: такая модель хорошо ложится на сценарии синхронизации с сервером, фоновую обработку изменений и разруливание нескольких источников истины. Если раньше SwiftData ассоциировался в первую очередь с локальным хранением для SwiftUI-экранов, то теперь Apple аккуратно подталкивает его в сторону более взрослого слоя данных.
Контекст у этой истории тоже показательный. SwiftData с момента запуска воспринимался как современная и более дружелюбная альтернатива старым паттернам работы с данными в экосистеме Apple, но за простотой API скрывался набор ограничений, которые быстро всплывали в реальных проектах. Интеграция сторонних типов, наблюдение вне SwiftUI, секционирование без дополнительной ручной обработки — все это не экзотика, а типовые потребности продуктовой команды, особенно если приложение живет дольше одного релизного цикла. На этом фоне июльское обновление выглядит не как показательная полировка для демо со сцены, а как реакция на вполне зрелые запросы рынка. Показательно и то, что Apple уже раздает эти возможности в составе Xcode 27 beta, то есть разработчикам предлагают проверить их до выхода платформенных релизов 2027 года.
Для русскоязычной аудитории практический смысл здесь предельно земной. Разработчики получают меньше поводов городить обвязку вокруг чужих типов и меньше ручной работы при построении списков. Тимлиды и архитекторы могут внимательнее посмотреть на SwiftData как на слой, который начинает обслуживать не только декларативный UI, но и события в самом хранилище. Продуктовым командам это обещает более предсказуемую разработку фич, где данные нужно одновременно хранить локально, показывать в секциях и синхронизировать с внешними системами. Открытый вопрос в другом: остановится ли Apple на удобных API для «счастливого пути» или в следующих итерациях дотянет SwiftData до более серьезной работы со схемой, миграциями и сложными запросами, без которой ни один удобный фреймворк долго не считается взрослым.