Какие модули есть в приложении

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

Это вопрос про ваш реальный проект: как он разбит, почему так и что это дало. Интервьюер хочет понять, работали ли вы с модульной архитектурой или только слышали о ней. Следом спрашивают про граф зависимостей: могут ли фичи зависеть друг от друга и как собирается приложение.

Как отвечать

Рассказывайте про свой проект, с конкретными названиями и цифрами: сколько модулей, сколько человек в команде, как изменилось время сборки. Если приложение монолитное, скажите прямо и опишите, как бы его разделили и зачем.

Типичная схема, от которой удобно отталкиваться:

• App: тонкий таргет приложения. Собирает зависимости, настраивает DI и корневую навигацию;
• фичевые модули: Profile, Catalog, Checkout. Каждый со своим UI, логикой и тестами, друг от друга напрямую не зависят;
• интерфейс и реализация: фича делится на CatalogAPI с протоколами и CatalogImpl. Соседи зависят только от лёгкого API, и правка реализации не пересобирает половину проекта;
• core-модули: Networking поверх URLSession, Storage с SwiftData, Core Data или Keychain, Analytics за протоколом, чтобы менять провайдера в одном месте;
• DesignSystem: цвета, шрифты, общие компоненты UIKit или SwiftUI.

Техническая сторона: локальные пакеты Swift Package Manager или фреймворки, генерация проекта через Tuist или XcodeGen, чтобы не ловить конфликты в .pbxproj. Упомяните выбор линковки: много динамических фреймворков удлиняют запуск приложения, а статическая библиотека, попавшая в несколько динамических таргетов, дублирует код.

Польза, которую стоит назвать: инкрементальная сборка, быстрые превью SwiftUI на маленьком модуле, понятное владение кодом по командам, изолированные тесты.

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

Выдают за модули слои внутри одного таргета («UI, сеть, данные»). Папки в Xcode это не модули: у них нет границ видимости и отдельной сборки.

Допускают зависимости между фичами. Модули переплетаются, появляются циклы, и собрать одну фичу отдельно уже нельзя.

Дробят слишком мелко. Сотня модулей в маленькой команде даёт накладные расходы на настройку и граф, которые перевешивают выигрыш по времени сборки.