Что выбрать между VIPER и Clean Swift
Что проверяют
Отличаете ли вы два близких подхода по существу, а не по набору букв, и умеете ли выбирать архитектуру под задачу. Ответ показывает, разбирали ли вы модуль руками или читали статью со схемой.
Как отвечать
Сказать, что оба подхода решают одну задачу: растащить экран на слои и убрать логику из контроллера. Разница в направлении потока и в контрактах.
В VIPER центральная точка это Presenter. View сообщает ему о действии, он обращается к Interactor за логикой, результат возвращается через Presenter обратно во View, за переходы отвечает Router, данные представлены сущностями.
В Clean Swift поток замкнут в цикл: контроллер отправляет запрос в Interactor, тот выполняет работу и отдаёт ответ в Presenter, Presenter формирует модель отображения и возвращает её контроллеру. У каждого сценария свои типы запроса, ответа и модели отображения, есть Router и вспомогательный Worker для работы с данными. Из-за этого Presenter занимается только форматированием, а контракты между слоями явные, но типов на экран становится заметно больше.
Практический вывод: если в команде уже принят один из подходов, спор бессмысленен, берём принятый. При выборе с нуля оба тяжелы для простого экрана, и разумнее связка с координатором для навигации, оставив строгую схему для сложных сценариев. Для интерфейса на декларативном фреймворке обе схемы ложатся плохо, там ближе однонаправленный поток состояния.
Где спотыкаются
Повторяют, что Clean Swift легче и компактнее. Шаблон генерации создаёт на один экран сопоставимый, а часто больший набор файлов, так что экономии кода там нет, есть более жёсткие контракты.
Второе: называют слои, но не могут сказать, кто владеет навигацией, где хранится состояние экрана и куда уходит сетевой вызов. Без этого список компонентов остаётся заученной схемой.
Третье: обосновывают выбор тестируемостью, хотя тестов на проекте нет. Тестируемость дают протоколы и внедрение зависимостей, а не количество слоёв, и об этом стоит сказать самому, не дожидаясь вопроса.