iPhone Duo для iOS-разработчика: что реально меняется в Swift-коде

iPhone Duo для Swift-разработчика — это не новый API, а новый экран: жёсткие frame и constraints, рассчитанные под прежние модели, съезжают или обрезаются. Меняются три вещи — обработка size classes, работа с несколькими сценами UIWindowScene и safe area на нестандартной геометрии экрана. В B2B-приложениях с 1С это бьёт по формам ввода накладных и складским сканерам первыми.

Где ломается старый layout: сцена с демонстрации у клиента

На демонстрации у клиента менеджер открывает форму списания товара — приложение синхронизировано с 1С, поле «количество» подтягивает остаток со склада. На прежней модели iPhone всё помещается на экране без вопросов. На iPhone Duo кнопка «Провести документ» уезжает под клавиатуру, а таблица позиций накладной обрезается сбоку. Разработчик правил вёрстку по фиксированным координатам, потому что несколько лет это была стандартная ширина экрана и менять её не было причин. Но новый корпус даёт другое соотношение сторон и другой safe area снизу, поэтому старые constraints держат элемент там, где раньше был край экрана, а теперь — середина.

Для склада это не вопрос эстетики. Кладовщик не может закрыть отгрузку, потому что не видит кнопку подтверждения. Менеджер вводит данные повторно на компьютере, пока в приложении разбираются. Клиент, который смотрел демо, откладывает подписание акта до следующей встречи — и это уже вопрос сорванного контракта, а не косметики интерфейса.

Size classes перестают быть формальностью

В большинстве старых iOS-приложений horizontalSizeClass и verticalSizeClass проверяли ради одной цели — переключить одноколоночный список на двухколоночный на iPad. На iPhone эту ветку кода часто не трогали годами: класс всегда compact, условие никогда не срабатывает. На iPhone Duo это перестаёт быть так — в развёрнутом состоянии size class уходит в regular, и код, который никогда не выполнялся, впервые запускается в проде, а не на тестовом стенде.

UIKit и SwiftUI ведут себя по-разному

В UIKit это означает пересмотр NSLayoutConstraint с приоритетами вместо одного жёсткого набора координат — там, где раньше стояла константа отступа, нужен диапазон и приоритет, который решает, чем жертвовать при нехватке места. В SwiftUI то же самое решается через GeometryReader или через адаптивный HStack/VStack, который меняет ось в зависимости от ширины контейнера, а не от типа устройства. Практический вывод простой: если ось стека жёстко задана как .horizontal или .vertical, форма ввода накладной либо не использует освободившееся место, либо ломает порядок полей при повороте.

Мультиоконность: одна сцена или две одновременно

Второе, что меняется, — количество активных UIWindowScene. Раньше приложение почти всегда работало с одной сценой на экране, и состояние — например, выбранный склад или текущий документ 1С — спокойно хранилось в singleton или в AppDelegate. На iPhone Duo пользователь может открыть каталог товаров в одной панели и карточку накладной в другой одновременно. Если состояние общее на всё приложение, вторая панель начинает показывать не то, что выбрал пользователь в первой, а последнее, что было выбрано где угодно.

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

Как проверить, что приложение готово, а не полагаться на глаз

Быстрая проверка на симуляторе в одном состоянии не находит половину проблем — они видны только в развёрнутом виде с открытой клавиатурой. Перед релизом стоит прогнать конкретный список:

• ✓форма с числовой клавиатурой открыта в компактном и в развёрнутом состоянии — проверить, не перекрывает ли клавиатура кнопку подтверждения;
• ✓таблица позиций документа прокручивается по горизонтали без обрезки последней колонки;
• ✓переход между панелями сохраняет выбранный склад, контрагента и текущий документ, а не сбрасывает их на значение по умолчанию;
• ✓VoiceOver проговаривает элементы в порядке, соответствующем новому layout, а не старому линейному порядку;
• ✓drag & drop карточки товара между панелями не создаёт вторую запись в 1С.

Если хотя бы два пункта из списка проваливаются, приложение выйдет в продакшен с багами, которые пользователи найдут сами — и найдут их на складе во время отгрузки, а не в тестовой среде разработчика.

Цена промедления: во что это обходится бизнесу

Пока форма ввода не адаптирована, склад продолжает работать по обходному сценарию — кладовщик уточняет остаток по телефону у офиса, вместо того чтобы посмотреть его в приложении на развёрнутом экране. Менеджер, у которого зависает кнопка «Провести документ», закрывает и открывает приложение заново по несколько раз за смену. Каждый такой перезапуск — минута простоя, а на смене с десятками документов задержка отгрузки набегает уже в часах.

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

Что делаем мы: адаптация Swift-кода под новый форм-фактор

Мы начинаем не с переписывания приложения целиком, а с аудита — ищем в кодовой базе жёсткие frame, константы отступов и места, где состояние хранится вне сцены. Дальше разделяем данные: то, что должно быть общим для всего приложения (авторизация, кэш каталога), и то, что должно быть привязано к конкретному окну (текущий документ, выбранный склад). Для B2B-приложений с 1С отдельно проверяем, что обмен через API выдерживает параллельную работу двух панелей — это частая причина дублей в учётной системе после доработки под мультиоконность.

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

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

Нужно ли переписывать приложение с нуля под iPhone Duo?

Нет, в большинстве случаев достаточно доработки: аудит жёстких frame и constraints, перенос состояния из singleton в привязку к сцене, адаптивные стеки вместо фиксированных осей. Полное переписывание нужно редко — только если приложение изначально не использовало Auto Layout или адаптивный SwiftUI-стек.

Как понять, что наше приложение с 1С сломается на новом экране, не дожидаясь жалоб?

Проверить пять вещей: форму с клавиатурой в развёрнутом виде, горизонтальную прокрутку таблиц, сохранение выбранного склада и документа при переходе между панелями, порядок VoiceOver и поведение drag & drop между панелями. Если два пункта из пяти проваливаются, приложение не готово.

Сколько стоит адаптация существующего B2B-приложения под новый форм-фактор экрана?

Стоимость зависит от количества экранов и глубины интеграции с 1С — оценивается индивидуально после аудита кода. Разработка мобильного приложения в UKVED начинается от 500 000 рублей, актуальные тарифы указаны на странице с ценами.

Может ли из-за мультиоконности возникнуть дублирование данных в 1С?

Да, если состояние документа хранится в общем singleton, а не привязано к конкретной сцене — две открытые панели могут независимо отправить изменения по одному и тому же документу и создать дубль или конфликт в учётной системе.

С чего начать адаптацию, если приложение писалось несколько лет назад?

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