Какой опыт работы со сторибордами, XIB и программной версткой

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

Знаете ли вы сильные и слабые стороны каждого способа и можете ли обосновать выбор для команды. Следом часто спрашивают, как передать зависимости в контроллер со сториборда и что делать с конфликтами при мерже.

Как отвечать

Опишите, что было в ваших проектах и почему. Каркас сравнения:

• Storyboard: быстро собрать поток экранов с segue, наглядно для новичков. Минусы: XML, который почти невозможно мержить, строковые идентификаторы и падение при опечатке, большой файл долго открывается. Если используете, то по сториборду на фичу, а не один общий;
• XIB: одна вьюха или ячейка, загрузка через UINib и register(_:forCellReuseIdentifier:) или Bundle.main.loadNibNamed. Подходит для переиспользуемых компонентов, конфликтов меньше;
• код: вёрстка в loadView() или инициализаторе, якоря или SnapKit. Читается на ревью, мержится как обычный код, зависимости передаются через init. Цена: больше кода и нет превью без SwiftUI Previews.

Деталь про зависимости: контроллер со сториборда создаётся через init?(coder:), поэтому раньше зависимости присваивали свойствами после создания. С iOS 13 есть instantiateViewController(identifier:creator:), он позволяет передать их в собственный инициализатор.

Скажите и про нынешний контекст: новые экраны всё чаще пишут на SwiftUI и встраивают в UIKit через UIHostingController, так что вопрос часто означает «чем вы поддерживаете старое».

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

Отвечают догмой «сториборды зло» или наоборот. Сильнее назвать критерии: размер команды, частота мержей, переиспользование.

Не знают, почему приложение падает при отвязанном @IBOutlet. Аутлет объявлен неявно развёрнутым опционалом, и обращение к нему до загрузки вьюхи или после удаления связи роняет процесс.

В программной вёрстке забывают translatesAutoresizingMaskIntoConstraints = false и получают лог с конфликтами констрейнтов и вьюху в левом верхнем углу.