Работал ли с компонентами и библиотеками для переиспользования
Что проверяют
Умеете ли вы выделять переиспользуемое и понимаете ли цену такого решения. За вопросом стоит и опыт модуляризации, и работа с зависимостями: на iOS они влияют на время сборки, минимальную версию системы и на то, как быстро вы поднимете проект на новом Xcode.
Как отвечать
Разделите своё и внешнее.
- Свои компоненты: общий набор элементов интерфейса на UIKit (наследники
UIView, ячейки с регистрацией и переиспользованием) либо на SwiftUI (View,ViewModifier,ViewBuilder). - Границы: компонент настраивается одной моделью, а не десятком открытых свойств, ничего не знает про экран, куда его вставили, не ходит в сеть и не лезет в синглтоны.
- Физическая граница: выносите в локальный Swift Package или отдельный модуль, тогда лишние зависимости не проползут по привычке.
- База: цвета и отступы из каталога ресурсов, поддержка Dynamic Type и VoiceOver закладывается сразу.
- Внешние библиотеки: SPM как основной способ, CocoaPods в унаследованных проектах, версии зафиксированы, и вы понимаете, что зависимость тянет за собой.
Добавьте, как это живёт дальше: превью и демонстрационный экран со всеми состояниями, снапшот-тесты на компоненты, правила изменения публичного интерфейса модуля.
Где спотыкаются
Обобщают слишком рано. Компонент обрастает флагами на каждый частный случай, и его проще написать заново, чем настроить. Общее выносят после третьего повторения, а не после первого.
Тянут тяжёлую зависимость ради одной функции. Потом она не собирается на новом Xcode или требует версию системы выше вашей, а поддерживать её некому.
Меряют результат выдуманными процентами экономии времени. Проверяемо звучит другое: перестали дублировать элементы, поправили доступность в одном месте, и это применилось везде.