iPhone Duo сломал складское приложение за смену: как чинили интерфейс

Адаптация iOS-приложения под iPhone Duo означает переработку интерфейса под два состояния — сложенный и разложенный экран, с учётом зоны сгиба, смены size class и синхронизации данных с сервером. Косметическая правка растягивает старые экраны и оставляет пустые поля; полноценная переработка навигации использует адаптивный layout и стоит от 500 000 ₽.

когда экран разворачивается, а интерфейс — нет

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

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

почему адаптивный интерфейс не адаптируется сам

iOS исторически различает size classes — компактный и обычный — и разработчик обязан явно описать, как элементы ведут себя в каждом. Если экраны верстались под iPhone с фиксированной шириной, у большинства элементов стоят жёсткие constraints: ширина карточки в поинтах, отступ от края в поинтах, размер шрифта без адаптации. На сложенном экране это работает случайно — просто потому что размеры совпадают со старым iPhone. На развёрнутом экране Duo система переходит в другой size class, а верстка, рассчитанная на компактную ширину, не умеет растягиваться на вдвое большее пространство.

Вторая причина — сгиб. Apple резервирует зону вокруг сгиба под safe area, и элементы интерфейса, которые не учитывают этот отступ, попадают точно на линию раскрытия: кнопки, поля ввода, ряды таблицы обрезаются пополам. Третья причина — состояние приложения при переходе между сложенным и разложенным режимом: если экран пересоздаётся заново вместо того, чтобы сохранять текущий view controller, пользователь теряет введённые данные — например, отсканированный штрихкод или незаполненную форму приёмки.

сканер тоже завязан на размер экрана

Отдельная проблема нашлась в модуле сканирования: preview layer камеры был закреплён под конкретную ориентацию и не учитывал промежуточное состояние, когда телефон разложен наполовину. В такие секунды камера показывала обрезанный кадр, а штрихкод считывался со второй-третьей попытки вместо первой. Пришлось привязать preview layer к текущему size class, а не к ориентации устройства — иначе адаптация верстки решала только половину проблемы.

Проверить готовность приложения можно и без физического iPhone Duo в руках: Xcode умеет эмулировать составной экран в симуляторе — сложенное и разложенное состояние, разные точки сгиба. Это не заменяет тест на живом устройстве, но позволяет отловить половину проблем ещё на этапе разработки, до того как сотрудники получат телефоны на руки.

три способа привести приложение в порядок — и что каждый стоит

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

Склад выбрал средний вариант — адаптивный layout: экранов в приложении немного, а самое дорогое решение с dual-pane было избыточным для задачи «принять товар и провести накладную в 1С».

как шла доработка: пять шагов от аудита до публикации

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

Size classes вместо фиксированных размеров. Каждый найденный экран переписали на UITraitCollection и адаптивные stack-контейнеры, чтобы верстка сама решала, показывать список и карточку рядом или друг за другом — в зависимости от того, сложен экран или разложен.

Safe area вокруг сгиба. Отступы от линии сгиба вынесли в отдельный layout guide, чтобы кнопки и таблицы не попадали точно на границу раскрытия — это была причина обрезанной кнопки «Подтвердить приёмку».

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

Тестирование и публикация. Проверяли и на симуляторе Xcode для составных экранов, и на живых устройствах кладовщиков — в реальных условиях склада сгиб экрана заклеивают защитной плёнкой, и это тоже влияло на то, где именно проходит линия safe area. После правок обновление отправили в App Store с пометкой поддержки нового класса устройств.

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

что изменилось после адаптации

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

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

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

Не каждое приложение одинаково уязвимо к новому форм-фактору. Быстро проверить собственный код можно по нескольким признакам:

• ✓размеры экранов и отступы заданы в фиксированных поинтах, а не в долях экрана или через safe area guide;
• ✓кнопки и поля ввода расположены близко к центру экрана — именно там проходит сгиб на составных устройствах;
• ✓состояние формы или сканера не сохраняется при смене ориентации или размера окна;
• ✓приложение не тестировалось на симуляторах с составным экраном в Xcode;
• ✓интеграция с 1С реализована через отдельный слой синхронизации, а не завязана напрямую на конкретный экран — это упрощает адаптацию интерфейса без риска сломать обмен данными.

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

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

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

Обычно нет. Чаще достаточно адаптировать существующие экраны под size classes и safe area вокруг сгиба, не трогая логику работы с сервером и 1С. Полная переработка навигации нужна только для сложных многоэкранных приложений, где список и карточка должны открываться одновременно на двух половинах экрана.

Сколько стоит адаптация iOS-приложения под iPhone Duo?

Точечная правка критичных экранов — по объёму работ, обсуждается индивидуально после аудита кода. Полноценная переработка навигации под dual-pane с сохранением состояния при повороте экрана начинается от 500 000 ₽ — это уровень полноценной доработки мобильного приложения, а не косметики. Точная сумма зависит от количества экранов и глубины интеграции с 1С.

Что будет, если не адаптировать приложение под iPhone Duo?

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

Можно ли проверить готовность приложения к iPhone Duo без покупки самого устройства?

Да, частично. Xcode умеет эмулировать составной экран в симуляторе — сложенное и разложенное состояние, размещение элементов вокруг сгиба. Это помогает найти большинство проблем с версткой до релиза, но точное поведение камеры, сканера и multitasking стоит проверить на живом устройстве перед публикацией в App Store.

Изменится ли работа интеграции с 1С после адаптации приложения под iPhone Duo?

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