Какую архитектуру вы бы выбрали для годового проекта

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

Умеете ли вы выбрать архитектуру под срок, команду и минимальную версию iOS, а не назвать модную аббревиатуру. Следом обычно спрашивают, как в выбранной схеме устроены навигация и внедрение зависимостей.

Как отвечать

Сначала уточните условия: сколько разработчиков, какая минимальная версия iOS, SwiftUI или UIKit, будет ли приложение жить после года разработки.

Для проекта на год с небольшой командой разумный каркас такой:

• MVVM на SwiftUI: ViewModel через макрос @Observable (фреймворк Observation, iOS 17 и выше), на старых версиях через ObservableObject и @Published. View только рисует состояние и передаёт действия;
• слой сервисов: сеть, хранилище и бизнес-правила живут в отдельных типах за протоколами, ViewModel их только вызывает;
• навигация: координатор или роутер поверх NavigationStack с путём в состоянии, чтобы переходы и диплинки не расползались по View;
• зависимости: передача через инициализатор или лёгкий контейнер, протоколы позволяют подменить сервис в тестах;
• модули: локальные пакеты Swift Package Manager по фичам, это ускоряет сборку и держит границы;
• асинхронность и тесты: async/await и акторы со строгой проверкой конкурентности Swift 6, тесты на XCTest или Swift Testing.

Если в приложении много сложного общего состояния и команда готова к порогу входа, упомяните TCA: предсказуемый однонаправленный поток и удобное тестирование ценой сторонней зависимости. VIPER уместен скорее в большой команде на UIKit с множеством похожих экранов.

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

Переносят всю логику в ViewModel. Через полгода она становится тем же толстым контроллером на тысячу строк, только с другим названием.

Выбирают @Observable или SwiftData, не проверив минимальную версию iOS. Если приложение поддерживает iOS 16, половина плана не собирается.

Называют MVVM и молчат про навигацию и зависимости. Именно на этих вопросах интервьюер проверяет, строили ли вы архитектуру сами или только работали в готовой.