Apple анонсировала iPhone Duo, свой первый складной iPhone, 9 сентября 2026 года. Предзаказы открываются 16 октября, старт продаж — 23 октября, устройство работает на iOS 27.1. Странность в последовательности: правила Apple опубликовала в тот же день, а SDK с симулятором Duo появится только «позже в сентябре». Документация уже есть, железа почти ни у кого нет — и это ровно то окно, чтобы найти в своём приложении допущения о layout, которые незаметно перестали быть верными.
Это не обзор устройства — таких выйдет сотня. Само push-уведомление рисует система, там менять нечего. А вот всё, что ваше приложение рисует само внутри себя, — то, что теперь должно пережить экран, который меняет форму и aspect ratio прямо во время активной сессии: in-app сообщения, rich media, push primer, лоадеры. Именно на этот слой Apple написала новые правила, и именно его большинство команд рискует пройти мимо — независимо от того, на какой рынок и в каком часовом поясе они катят релиз.
Что на самом деле изменилось в iOS 27 на складном iPhone
У iPhone Duo два дисплея с почти одинаковым соотношением сторон. Внутренний — 7.6 дюйма, примерно на 50% больше площади экрана, чем у iPhone 18 Pro Max; внешний — 5.4 дюйма, около 90% площади экрана iPhone 18 Pro. Пропорции близкие, но не идентичные — ещё один повод строить layout от size classes, а не от соотношения сторон, которое вы считаете одинаковым для обоих экранов.
Каждое приложение участвует в Split View. Duo — первый iPhone, который запускает несколько инстансов UI одного приложения одновременно, а значит ваше in-app сообщение может оказаться в половине экрана рядом с чужим приложением.
И форма меняется прямо посреди сессии. Пользователь разворачивает устройство или складывает его наполовину, пока у вас на экране висит модалка. Layout больше не решение, которое вы принимаете один раз при запуске.
3 уровня совместимости, и где окажется большинство приложений
Правило Apple звучит прямолинейно: приложение запускается на Duo без пересборки. Вопрос в том, сколько экрана оно получит — а это зависит от того, под какой SDK оно собрано.
- Старый SDK: приложение работает, но контент остаётся в рамке размером с обычный телефон.
- SDK iOS 27: UI выходит за пределы status bar на внутреннем дисплее.
- SDK iOS 27.1: UI доходит до края экрана, а стандартные кнопки навигации и toolbar выстраиваются вертикально.
То есть команда, которая не делает ничего, отправляет свои in-app сообщения в коробке размером с телефон на 7.6-дюймовом дисплее. Не сломано — просто заметно нетронуто, рядом с конкурентами, которые этим занялись.
Почему layout вашей in-app messaging перестаёт работать
3 причины, и они складываются друг с другом.
Aspect ratio. Большинство in-app и rich-media шаблонов сверстаны под пропорции обычного iPhone. У внутреннего дисплея пропорции другие, и шаблоны, сделанные под старые экраны, не встанут туда, где вы их разместили.
Ориентация — не тот сигнал. Внутренний дисплей регулярный (regular) в обоих size classes и не учитывает поддерживаемые interface orientations. Любая ветка layout, завязанная на ориентацию, читает сигнал, который внутренний дисплей просто игнорирует. Инструкция Apple прямая: строить layout от size classes, а не от ориентации.
Safe area асимметричен. Insets и margins на Duo часто разные с каждой стороны, поэтому каждый край нужно обрабатывать отдельно, а не полагаться на симметричный фрейм. И протестировать это ещё раз в Split View, где фрейм снова становится узким.
In-app сообщение, которое открыто в момент раскладывания телефона
Этот сценарий стоит продумать заранее, потому что понаблюдать за ним пока негде — нет симулятора: модальное in-app сообщение на экране, и пользователь разворачивает телефон. Фрейм меняется прямо под уже показанным view.
Apple даёт для этого 2 инструмента, и перепутать их — самая частая ошибка.
Hinge API, onHingeChange в SwiftUI и UIHingeInteraction в UIKit, сообщают дискретное состояние (закрыто, частично открыто, полностью открыто) и непрерывный угол. Они предназначены для отслеживания в реальном времени и управления интеракциями и эффектами. В собственном демо Apple угол сгиба меняет высоту тона у виртуального инструмента. Это тот регистр, для которого они нужны, а не для того, чтобы двигать ваши кнопки.
Layout идёт через другую дверь. Apple отсылает к API расположения и зон из доклада «Strike a pose with adaptive layouts on iPhone Duo», который вводит reserved regions, arrangement views со split- и overlay-раскладками и displacement: перекомпоновку существующих элементов в реально доступное пространство, чтобы контент оставался видимым и доступным по мере складывания устройства. iOS 27.1 добавляет ReservedRegion в SwiftUI и UIViewReservedRegion в UIKit — так ваш кастомный UI может занять нужное ему место, не сталкиваясь с системным UI. Их можно запросить через reservedRegions(kind:), где .division — это сам сгиб, а .occlusion — камера.
Для модалки это сводится к одному правилу: не использовать угол сгиба, чтобы перепозиционировать её. Пусть она реагирует на arrangement и reserved region — тогда при раскрытии экрана контент окажется там, где должен, а не будет цепляться за фрейм, которого уже нет.
In-app уведомления в Split View
Раз теперь каждое приложение участвует в multitasking pool, ваши in-app уведомления могут оказаться в половине экрана рядом с чужим приложением. Это гораздо более узкий фрейм, чем полный внутренний дисплей, — и именно поэтому стоит тестировать при половинной ширине. Модалка, которая нормально выглядит на весь экран, будет обрезаться или теснить контент, потеряв половину места.
Есть и жёсткое ограничение: на внешнем дисплее нельзя открывать новые окна — он зарезервирован под внутренний опыт. Любая логика презентации, которая порождает окна, должна это учитывать.
Внешний дисплей: компактный layout, плюс виджеты и Live Activities
Внешний дисплей ведёт себя как обычный экран iPhone. Приложение работает там же, и всё, что оно рисует, включая in-app сообщения. Apple формулирует это так: внешний дисплей — это compact-width layout, как у обычного iPhone, а внутренний — regular по обоим измерениям. При 5.4 дюйма это самый узкий полноэкранный фрейм, который получит ваша in-app messaging на этом устройстве, — так что ему место в тестовой матрице, а не в стопке «не применимо».
Поверх этого есть ещё одна поверхность. На Duo StandBy работает на любом из дисплеев даже без зарядки: положил телефон — внешний экран остаётся включённым и развёрнутым в комнату. Приложение без виджета и без Live Activity в этот момент просто отсутствует. Присутствие там обеспечивают виджет или Live Activity — та же работа, что вы уже делали для lock screen и Dynamic Island. Если Live Activities у вас уже есть, это вторая точка, где эта инвестиция окупается. Если нет — вот ещё один повод их сделать.
Чек-лист совместимости со складным iPhone до 23 октября
Устройства у вас пока нет, но всё остальное — уже на столе:
- Проведите инвентаризацию in-app и rich-media шаблонов. Найдите каждый, где зашита фиксированная рамка, aspect ratio или коробка размером с телефон.
- Проверьте креативы 16:9. Всё, что сверстано под фиксированный aspect ratio, нуждается в плане для внутреннего дисплея.
- Найдите ветки, завязанные на ориентацию. Layout, завязанный на interface orientation, читает сигнал, который внутренний дисплей игнорирует, — перенесите логику на size classes.
- Проверьте каждый край safe area отдельно. Считайте асимметрию нормой; не полагайтесь на симметричный inset.
- Найдите все обращения к
UIScreen.main. На устройстве с 2 дисплеями это неоднозначно, и Apple объявила о будущем deprecation. Берите экран черезwindow?.windowScene?.screen, а масштаб — черезtraitCollection.displayScale. - Тестируйте при компактной ширине, а не только в развёрнутом виде. На внешнем дисплее ваши in-app сообщения получают меньше всего места, и это реальная поверхность для них.
- Заложите время на тест в Device Hub. Когда выйдет бета Xcode 27.1, симулятор Duo появится в Device Hub: откройте его, закройте, поверните, сложите наполовину с сообщением на экране.
- Сегментируйте по модели устройства. Дайте себе способ таргетировать пользователей Duo для отдельного тестирования, когда они появятся у реальных пользователей.
- Пересмотрите текст push-уведомления и onboarding-primer. Системный запрос разрешения во время онбординга по-прежнему рисует система, но любой кастомный экран перед ним подчиняется тем же правилам layout, что и ваша in-app messaging.
Ничего из этого не требует устройства. Всё это нужно сделать до того, как устройство окажется в руках пользователей, а не после.
Готовьте in-app messaging к Duo уже сейчас
Чинить это вручную в in-app сообщениях, rich media и push primer, на каждом экране, который носят ваши пользователи, — задача, которую проще решить одной интеграцией, чем шестью. Это и есть аргумент в пользу единой кросс-канальной платформы вовлечения для in-app messaging и push-уведомлений вроде Pushwoosh: начните бесплатно или поговорите с нашей командой о том, как подготовить messaging к Duo до 23 октября.
