Мобильный трудоголик

Руководство по адаптации приложений под iPhone Duo

Apple выпустила руководство по адаптации приложений под iPhone Duo - свой первый складной смартфон. Главная новость: отдельного FoldableKit нет. Apple просто продолжает двигать разработчиков в сторону адаптивных интерфейсов.


С чего стоит начать:

Приложение будет работать на iPhone Duo, даже если оно не собрано при помощи iOS 27 SDK. Но чтобы использовать все возможности, нужно обновление.

В режиме совместимости, как iPhone-приложение на iPad, все будет работать не очень красиво. Если собрать с iOS 27 SDK, появится полноэкранный режим с черным статус-баром. С iOS 27.1 SDK можно сделать полноценную поддержку.

Для тестирования нужно скачать Xcode 27.1 и выбрать симулятор iPhone Duo в Device Hub. Там можно открыть, закрыть, повернуть и сложить устройство, чтобы посмотреть, как ведет себя layout.


Как работает адаптация:

На внешнем экране iPhone Duo все выглядит как на обычном iPhone: regular для вертикального положения, compact для горизонтального. На внутреннем экране - regular и по горизонтали и по вертикали. Это позволяет показывать sidebar и больше контента.

Внутренний экран не обязан соблюдать supportedInterfaceOrientations. Apple прямо говорит: не проверяйте ориентацию для layout-решений. Используйте size classes.


Проблема с UIScreen.main:

У iPhone Duo два дисплея, поэтому понятие UIScreen.main становится неоднозначным. Apple объявила такие обращения устаревшими.

Если действительно нужен экран конкретного окна, его можно получить через UIWindowScene:

window?.windowScene?.screen

Но лучше вообще работать через environment, traits и размеры самой scene.


Асимметричные safe areas:

Safe area теперь может быть асимметричной. Формула width - leftInset * 2 больше не гарантирует правильный результат. Левый и правый inset могут отличаться из-за формы устройства, камеры и системного UI.

Apple советует считать каждую сторону отдельно. Весь интерактивный UI держать внутри safe area, а фон растягивать edge-to-edge.


Автоматическая адаптация:

Если вы используете стандартную навигацию, большая часть адаптации произойдет автоматически. NavigationSplitView, UISplitViewController, TabView, UITabBarController, sheets, popovers и alerts уже умеют адаптироваться к разным положениям Duo.

На внутреннем экране tab bar можно автоматически превратить в sidebar. Для SwiftUI это настройка default tab bar placement, для UIKit - preferred placement.


ReservedRegion:

В iOS 27.1 появилась новая возможность - ReservedRegion в SwiftUI и UIViewReservedRegion в UIKit. Она нужна кастомному edge-to-edge UI, чтобы сказать системе: дай максимум пространства, но не залезай туда, где уже живет системный интерфейс.

Это полезно для собственных баров и сложных лайаутов.


🔗 Читать подробнее


Вывод:

iPhone Duo не приносит отдельный фреймворк. Apple просто продолжает давить в сторону адаптивного интерфейса. Не определять устройство. Не ориентироваться на конкретную ширину. Не считать, что экран один. Не ожидать симметричные safe areas. Если вы уже следовали этим правилам, у вас будет минимум работы по адаптации.

Реалии разработки: почему 50% времени уходит не на код

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


Цикл разработки, который знаком каждому:


Неделя 1 - начало разработки:

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


Неделя 2 - ожидания тестирования:

Отдел тестирования перегружен, ваша задача висит в статусе «готова к тестированию». Вы переключаетесь на другие задачи и проекты, постепенно забывая детали реализации. Контекст стирается, а энтузиазм угасает.


Неделя 3 - неожиданное возвращение:

Внезапно приходит сообщение: «Задача возвращена на доработку». Оказывается, требования изменились, нашли краевой случай или продукт-менеджер придумал улучшение. Теперь вам нужно заново вникать в задачу, которую вы уже считали завершенной.


Немного статистики:

🔹 Каждая третья фича возвращается на доработку минимум один раз.

🔹 15% задач требуют кардинальных изменений после тестирования.

🔹 Среднее время ожидания тестирования: от 2 дней до 7 дней.

🔹 Большинство разработчиков одновременно ведут несколько задач.


Почему так происходит:

Бизнес-требования постоянно эволюционируют: рынок не стоит на месте. То, что было актуально месяц назад, сегодня может устареть. Пользователи дают обратную связь, которая подсвечивает неочевидные проблемы. Тестирование выявляет ситуации, которые невозможно было предвидеть на этапе проектирования.


Как с этим работать:


Ментальные практики:

🔹 Не привязываться эмоционально к написанному коду.

🔹 Воспринимать изменения не как неудачу, а как возможность сделать продукт лучше.

🔹 Понимать, что выпиливание фичи - это не личное поражение, а забота о пользователе.


Построить рабочие процессы:

🔹 Организовать регулярные встречи с продукт-менеджерами для синхронизации.

🔹 Проводить промежуточные демо для стейкхолдеров до финального тестирования.

🔹 Выполнить детальные чек-листы перед сдачей задачи.

🔹 Назначить четкие критерии приемки для каждой фичи.


Вывод:

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