Используете ли SnapKit или другие библиотеки для верстки

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

Вопрос про опыт, но на деле проверяют, понимаете ли вы, что под SnapKit лежит тот же Auto Layout, и умеете ли обосновать выбор инструмента. Следом часто просят сверстать ячейку без библиотеки или спрашивают про SwiftUI.

Как отвечать

Начните с честного ответа о своём стеке, а потом покажите понимание:

• SnapKit: DSL поверх NSLayoutConstraint. Запись view.snp.makeConstraints { $0.edges.equalToSuperview().inset(16) } короче и читается легче, чем четыре якоря. Для изменений есть updateConstraints и remakeConstraints, а translatesAutoresizingMaskIntoConstraints библиотека выключает сама;
• нативные якоря: NSLayoutAnchor и NSLayoutConstraint.activate([...]), доступные с iOS 9. Кода больше, зато нет зависимости, и любой iOS-разработчик прочитает его без подготовки;
• ручной лейаут: фреймы в layoutSubviews или библиотеки вроде PinLayout и FlexLayout. Их берут для тяжёлых лент, где решатель ограничений на сложных ячейках даёт просадку кадров;
• SwiftUI: новые экраны многие команды уже пишут на нём, встраивая в UIKit через UIHostingController, и тогда вопрос библиотеки для констрейнтов отпадает сам.

Каркас ответа: что использовали в последнем проекте, почему команда так решила и что бы вы выбрали сейчас. Примеры и цифры нужны ваши: сколько экранов, была ли проблема с производительностью, как её измеряли в Instruments. Если со SnapKit вы не работали, так и скажите: «Верстаю на якорях и SwiftUI, SnapKit читаю без труда, он один в один ложится на те же констрейнты».

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

Говорят, что SnapKit ускоряет интерфейс. Он создаёт обычные констрейнты, производительность та же, что у нативного Auto Layout.

Не знают нативного API. Если без библиотеки кандидат не может сверстать ячейку, это настораживает сильнее, чем отсутствие опыта со SnapKit.

Не упоминают стоимость зависимости: обновления под новые версии Swift и Xcode, влияние на время сборки, риск, что библиотеку перестанут поддерживать.