SwiftUI для бизнеса: когда фреймворк ускоряет разработку, а когда тормозит

SwiftUI — декларативный фреймворк Apple для интерфейсов iOS, macOS, watchOS, где верстка описывается как функция от состояния данных, а не как последовательность команд отрисовки. Для бизнеса это означает более быструю разработку типовых экранов и более скользкие места на нестандартных сценариях: сложных таблицах, кастомной навигации, интеграции со старым кодом на UIKit.

что такое SwiftUI и чем он отличается от UIKit

UIKit почти пятнадцать лет был единственным способом писать нативные интерфейсы под iOS: разработчик вручную создавал вьюшки, назначал делегатов, подписывался на события и следил, чтобы экран сам себя перерисовал в нужный момент. SwiftUI, представленный в 2019 году, перевернул подход — интерфейс описывается декларативно: разработчик пишет, каким экран должен быть при том или ином состоянии данных, а фреймворк сам решает, что и когда перерисовать.

На практике разница ощущается в объёме кода. Форма с десятком полей, валидацией и переходом на следующий экран на UIKit — это отдельный контроллер, сторибоард или вёрстка кодом, делегаты для полей ввода, ручное управление клавиатурой. На SwiftUI тот же экран укладывается в один файл с описанием структуры и связанных с ней переменных состояния.

ключевые технические особенности

• ✓Combine и позже макросы Observation — реактивное обновление интерфейса при изменении данных без ручных вызовов reloadData или setNeedsDisplay.
• ✓Единая кодовая база для iOS, iPadOS, macOS и watchOS с адаптацией под размер экрана через модификаторы, а не отдельные раскладки.
• ✓Live Preview в Xcode — изменения в коде видны в превью без пересборки приложения на симуляторе, что на средних проектах экономит часы за спринт.
• ✓Постепенная миграция: SwiftUI-экраны встраиваются в существующее UIKit-приложение через UIHostingController, и наоборот.

почему возникает разрыв между демо-приложением и продакшеном на SwiftUI

На презентации Apple SwiftUI-приложение собирается за час: список, детальный экран, форма — всё гладко. Но у клиента из ритейла с 1С на бэкенде задача другая: экран склада должен показывать таблицу из тысячи позиций с сортировкой, фильтрами и подгрузкой партиями, а ещё синхронизироваться с базой в реальном времени. На такой таблице SwiftUI-список начинает подтормаживать при скролле, а состояние экрана — раздваиваться между локальным кэшем и данными с сервера.

Причина не в фреймворке как таковом, а в его молодости на сложных сценариях. SwiftUI хорош там, где Apple годами оттачивала стандартные компоненты — списки, формы, навигацию с одним уровнем вложенности. Но когда нужна кастомная анимация перехода, синхронная работа с картой, сложный жестовый интерфейс или интеграция с legacy SDK, который писался под UIKit десять лет назад, декларативная модель начинает сопротивляться: разработчик тратит время не на бизнес-логику, а на обход ограничений фреймворка.

Если это не учесть на этапе оценки проекта, компания получает сорванный срок сдачи: заказчик ждёт приложение к открытию сезона продаж, а команда неделями чинит производительность списка вместо того, чтобы доделывать интеграцию с 1С. Для бизнеса это не абстрактный риск, а конкретная цена — упущенные заказы за дни простоя мобильного канала и повторная оплата доработок, которые должны были войти в первоначальную смету.

как исправить производительность и глюки интерфейса на SwiftUI

Первый шаг — найти, где именно тормозит: в SwiftUI это почти всегда лишние перерисовки. Structура, помеченная как @State или @Published, тянет за собой пересчёт всего дерева вью, которое от неё зависит, даже если реально изменилось одно поле в списке из тысячи строк. Решение — дробить крупные вью на мелкие подкомпоненты, чтобы перерисовывался только затронутый кусок экрана, и переносить тяжёлые данные в отдельные ObservableObject с точечными полями вместо одного гигантского объекта состояния.

Вторая частая проблема — списки с большим числом элементов и вложенными изображениями. LazyVStack и LazyVGrid решают часть случаев, но при интеграции с 1С, где количество позиций в накладной или остатков на складе легко переваливает за пару тысяч, помогает пагинация на уровне запроса к серверу, а не попытка отрисовать всё разом на клиенте.

Третье — конфликты состояния при офлайн-работе, частые в мобильных приложениях для торговых точек с нестабильным интернетом. Здесь без чёткой архитектуры (единый источник истины, локальная база с очередью синхронизации) SwiftUI-приложение будет то показывать устаревшие остатки, то терять введённые данные при разрыве связи.

что делать, если ошибка повторяется после исправления

Если баг с перерисовкой или потерей состояния возвращается после фикса — почти всегда это значит, что поправили симптом, а не причину. Например, добавили id к элементам списка, чтобы убрать мерцание, но не разобрались, почему SwiftUI вообще пересоздаёт вью: реальная причина может быть в неправильно объявленном Identifiable или в том, что модель данных пересоздаётся заново при каждом обращении к API вместо обновления существующего объекта.

В таких случаях помогает не точечная правка, а ревизия архитектуры экрана целиком: как объявлено состояние, откуда оно приходит, кто на него подписан. На проектах с интеграцией 1С мы фиксируем модель данных на уровне протокола обмена ещё до старта вёрстки экранов — это убирает добрую половину подобных повторяющихся багов, потому что структура данных на телефоне перестаёт расходиться со структурой в базе.

Второй источник повторных ошибок — версии iOS. SwiftUI меняется от релиза к релизу заметнее, чем UIKit: поведение модификатора, которое работало на iOS 16, может отличаться на iOS 17 или 18. Если баг воспроизводится только на части устройств пользователей, первым делом стоит проверить, на каких версиях системы он ловится, и явно протестировать код на минимально поддерживаемой версии, а не только на последней.

как предотвратить проблемы SwiftUI ещё на этапе проектирования

Дешевле всего решить эти проблемы до того, как они появились в коде. На старте проекта для бизнеса это означает три вещи.

Первое — трезво выбрать, где SwiftUI, а где гибрид с UIKit. Каталог товаров, формы заказов, личный кабинет, push-уведомления — типовые сценарии, SwiftUI справляется отлично. Кастомный сканер штрихкодов с наложенной разметкой, сложные жестовые взаимодействия на складских экранах — здесь иногда быстрее и надёжнее взять готовый UIKit-компонент и обернуть его, чем переизобретать на SwiftUI.

Второе — заранее спроектировать модель данных и её синхронизацию с 1С, а не подгонять её под готовый интерфейс задним числом. Наш опыт интеграции мобильных приложений с 1С показывает: если протокол обмена данными продуман до вёрстки, дальнейшая разработка идёт без переделок экранов под изменившуюся структуру ответа от сервера.

Третье — не экономить на нагрузочном тестировании интерфейса с реальными объёмами данных клиента, а не с демо-набором из двадцати строк. Ритейл с полутора тысячами SKU и логистическая компания с сотней заявок в день — разные требования к архитектуре списков и кэшу, и это нужно закладывать в разработку с первого спринта.

сравнение SwiftUI и UIKit для бизнес-задач

сколько стоит разработка iOS-приложения на SwiftUI и что входит в работу

Мы в UKVED делаем мобильные приложения для бизнеса на SwiftUI там, где это ускоряет разработку без потери качества, и подключаем UIKit для узких мест — сложных таблиц, кастомных сканеров, тяжёлой графики. На старте проекта проектируем архитектуру данных так, чтобы интеграция с 1С не превратилась в переделку интерфейса на середине разработки: у нас есть отдельная практика по интеграции мобильных приложений с 1С и готовые решения для B2B-приложений, завязанных на учётную систему.

Разработка мобильного приложения под ключ у нас стартует от 500 000 рублей — в эту сумму входит проектирование архитектуры, вёрстка интерфейса, интеграция с бэкендом и тестирование на реальных объёмах данных заказчика, а не на демо-наборе. Подробнее о том, что мы делаем в рамках разработки мобильных приложений, и по каким сценариям чаще всего заказывают приложения с интеграцией 1С, можно посмотреть на странице услуги. Если проект завязан на 1С не только через API, а требует мобильного контура внутри самой учётной системы — есть отдельное направление на 1С:Мобильной платформе. Актуальные тарифы и условия — на странице цен и тарифов.

❓ Частые вопросы

SwiftUI подходит для приложения с интеграцией 1С?

Да, для большинства экранов — каталогов, форм заказов, личных кабинетов. Ключевое условие — заранее спроектировать модель данных и протокол обмена с 1С, до вёрстки интерфейса, иначе структуру экранов придётся переделывать при изменении формата ответа от сервера.

Почему демо-приложение на SwiftUI работает быстро, а готовый проект тормозит?

Демо обычно тестируют на небольшом наборе данных. При реальных объёмах — тысячи позиций в списке, частые обновления состояния — начинаются лишние перерисовки экрана. Решается разбиением крупных вью на компоненты и пагинацией данных с сервера.

Можно ли совмещать SwiftUI и UIKit в одном приложении?

Да, это стандартная практика через UIHostingController. Типовые экраны делают на SwiftUI ради скорости разработки, а сложные кастомные интерфейсы — сканеры, нестандартные жесты, тяжёлую графику — оставляют на UIKit или сторонних SDK.

Сколько стоит разработка iOS-приложения на SwiftUI под ключ?

У нас разработка мобильного приложения начинается от 500 000 рублей, включая проектирование архитектуры, вёрстку, интеграцию с бэкендом и тестирование на объёмах данных заказчика, а не на демо-примере.

Что делать, если баг с интерфейсом на SwiftUI появляется снова после исправления?

Обычно это значит, что поправили симптом, а не причину — например, состояние объявлено неверно или модель данных пересоздаётся вместо обновления. Нужна ревизия архитектуры экрана: откуда приходит состояние и кто на него подписан.