**Apple** випустила гайдлайни для iPhone Duo. Це перший раз, коли iOS-додаток треба готувати до складаного екрана. Подивився сесію **Marcos** і **Vince** з дизайн-команди  **Apple**, ось що звідти важливо для роботи.

**КОНТРОЛИ ПЕРЕЇЖДЖАЮТЬ УБІК**
Закритий пристрій має ширший і нижчий дисплей, ніж звичний iPhone. Тому таб-бар, тулбари, кнопка «назад», перемальований статус-бар і Dynamic Island тепер живуть у вертикальній смузі праворуч. Так вивільняється вертикаль під контент, а керування лишається під великим пальцем. Мапінг з наявного айфона прямий: що було вгорі тулбара, іде вгору смуги, що було внизу, лишається внизу, таб-бар знизу. Широкі елементи типу текстових кнопок і segmented control залишаються в нав-барі.

**МАКЕТИ ПІД КОЖНУ ПОЗУ**
Пристрій розкривають наполовину як книжку, ставлять на стіл як ноутбук, лишають стояти на ребрі. Спокуса намалювати окремий макет під кожен випадок велика, і Apple прямо каже цього не робити. Замість цього два size class: compact width зовні, regular width всередині. Ніяких фіксованих ширин і брейкпоінтів під конкретний екран, тільки layout margins і horizontal safe area insets. Формулювання Vince я б повісив на стіну: проєктуйте так, щоб додаток вільно ресайзився.

**ЗОВНІШНІЙ ДИСПЛЕЙ**
Центрувати контент по всій ширині за замовчуванням більше не вийде, йому потрібен офсет, щоб не ховатися під контролами. Якщо верстка спирається на safe area insets, це стається саме. Виняток є: імерсивні візуальні екрани без скролу можна лишати центрованими, якщо контроли нічого не перекривають. Змішаний варіант теж працює, коли фон чи хедер ідуть на всю ширину, а скрольований контент має відступ.

**ВНУТРІШНІЙ ДИСПЛЕЙ**
Тут не має бути розтягнутого айфона. Split view показує кілька рівнів ієрархії одночасно. Вертикальний стек може перебудовуватися у дві колонки, коли з'явилася горизонталь. Таб-бар можна подати як сайдбар, але це радше для щільних застосунків типу Health.

**СКЛАДАННЯ**
Кнопки, що опиняються прямо в згині, натискати незручно. Тому системні компоненти самі відсувають інтерактивні елементи вбік: шіти, алерти, меню, кнопки тулбара. Скрольований контент відсувати не треба. Для мене це найсильніший аргумент не малювати власні компоненти там, де є системні.

**Шіти окремо: **зовні їхні контроли теж ідуть убік, і це можна вимкнути, якщо кнопка одна. Всередині, у портреті й ландшафті, працюють звичайні горизонтальні бари.

**І те, що варто винести з усієї сесії: **ієрархія і функції не залежать від пози. Люди складатимуть і розкладатимуть пристрій прямо посеред сценарію, тож додаток має поводитися передбачувано.

Практично все зводиться до адаптивності. Роботу, яку хороші продуктові команди й так мали робити, тепер просто не вийде відкласти.

А ви вже приміряли свої макети до цього форм-фактора?

Відоси: [https://lnkd.in/p/d5TVNYrn](https://lnkd.in/p/d5TVNYrn)

 [Product Design * Motion in App | Підписатися](https://t.me/motioninapp)