Какой опыт работы с фреймами и автолейаутом в iOS?

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

Понимаете ли вы, как UIKit раскладывает вьюхи, и можете ли выбрать между ручными фреймами и Auto Layout под задачу. Следом обычно спрашивают, как вы разбирались с конфликтом констрейнтов или тормозящим списком.

Как отвечать

Опирайтесь на свой проект: какие экраны делали констрейнтами, где считали фреймы руками и почему. Если ручной вёрстки не было, так и скажите, но покажите, что понимаете механику:

• frame и bounds: frame в координатах родителя, bounds в собственных. При трансформации frame перестаёт быть надёжным;
• ручная вёрстка: размеры считаются в layoutSubviews() или viewDidLayoutSubviews(), когда размер родителя уже известен. Оправдана в тяжёлых ячейках и анимациях;
• Auto Layout: NSLayoutConstraint через якоря, translatesAutoresizingMaskIntoConstraints = false, приоритеты, setContentHuggingPriority и setContentCompressionResistancePriority, intrinsicContentSize;
• инструменты: UIStackView снимает большую часть ручных констрейнтов, safeAreaLayoutGuide отвечает за вырез и индикатор, self-sizing ячейки получаются через UITableView.automaticDimension.

Хороший ответ показывает выбор: Auto Layout по умолчанию, фреймы там, где профилировщик показал проблему. Упомяните отладку: символический брейкпоинт UIViewAlertForUnsatisfiableConstraints, View Debugger в Xcode, идентификаторы у констрейнтов для читаемого лога. Если в команде есть SwiftUI, расскажите, как встраивали его в UIKit-экраны.

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

Выставляют frame в viewDidLoad(). Размеры вьюхи там ещё не финальные, и на другом устройстве вёрстка съезжает.

Смешивают на одной вьюхе констрейнты и ручную установку frame. Следующий проход раскладки молча перетирает значение.

Утверждают, что Auto Layout всегда медленный. Движок Apple давно заметно ускорили, а тормоза обычно от лишней вложенности и пересоздания констрейнтов в cellForRowAt.