Почему мобильное приложение должно быть разделено на отдельные модули

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

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

Как отвечать

Ключевой довод в уровне доступа. В Swift internal действует на модуль, поэтому в одном таргете любой тип виден всему приложению, а деление на папки держится ровно до ближайшей спешки. Отдельный модуль превращает договорённость в правило компилятора: наружу видно лишь то, что помечено public.

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

Третий: переиспользование в расширениях приложения. Виджет, расширение для обмена и часы линкуют нужные модули, а не тянут весь код приложения.

Полезно сказать и про то, как делят: слои вроде сети, хранилища и дизайн-системы отдельно, фичи отдельно, фичи друг от друга напрямую не зависят, общение идёт через модуль с интерфейсами или через слой навигации. Иначе граф зависимостей быстро замкнётся в кольцо.

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

Повторяют учебный список: читаемость, поддерживаемость, тестируемость. Всё это даёт и аккуратная структура папок. Назовите то, чего папки не дают: невозможность обойти границу и раздельная пересборка.

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

Забывают про цену на запуске и ресурсы. Много динамических фреймворков замедляют старт, поэтому по умолчанию берут статическую линковку. Ресурсы и локализация внутри модуля лежат в его собственном бандле: обращение к главному бандлу по привычке даёт пустую картинку и непереведённую строку без единой ошибки.