Как декомпозировать экран из Figma

Что проверяют

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

Как отвечать

Идите сверху вниз, от экрана к мелким элементам:

• каркас экрана: навбар, скролл, закреплённые блоки, нижняя кнопка. Если контент повторяется или длинный, это UICollectionView с compositional layout и diffable data source либо List или LazyVStack в SwiftUI, а не стек из десятка вьюх;
• секции и ячейки: каждая секция описывается своей моделью, например enum Section с ассоциированными данными, а ячейка получает готовую view model и не знает про сеть;
• дизайн-система: сначала ищете в макете готовые компоненты Figma и их варианты. Если кнопка с состояниями уже есть в проекте, её не пишут заново. Цвета, шрифты и отступы берутся из токенов, а не из hex-кода на макете;
• Auto Layout в Figma: подсказывает структуру. Горизонтальный фрейм превращается в HStack или UIStackView, «hug» означает размер по содержимому, «fill» соответствует frame(maxWidth: .infinity) или растяжению по констрейнтам;
• состояния: загрузка, пустой список, ошибка, длинный текст, Dynamic Type, тёмная тема, маленький экран. Чего нет в макете, уточняют у дизайнера до начала работы.

Навигацию в SwiftUI сегодня строят на NavigationStack, NavigationView помечен устаревшим с iOS 16.

Закончите тем, что декомпозиция даёт и оценку: список компонентов с пометками «есть в дизайн-системе» или «новый» превращается в подзадачи.

Где спотыкаются

Переносят размеры с макета жёсткими фреймами. На iPhone SE и при увеличенном шрифте вёрстка разъезжается.

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

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