Перейти на PRO

Как организовать многомодульную архитектуру в iOS-проекте?

Тип вопроса: Архитектура Вероятность: 10% Категория: IOS Разработчик

Ответ

Многомодульная архитектура разбивает проект на логические, слабосвязанные компоненты (модули/фреймворки). Это улучшает инкапсуляцию, переиспользование кода и скорость сборки за счет кэширования.

Основные подходы и инструменты:

  • Swift Package Manager (SPM): Нативный инструмент Apple. Модули описываются в Package.swift.
  • CocoaPods / Carthage: Традиционные менеджеры зависимостей, также поддерживающие модульность.

Типичная структура модулей:

MyApp/ (главное приложение)
├── AppFeature/ (координация, DI)
├── AuthModule/ (логика аутентификации)
├── NetworkModule/ (сетевые запросы, модели)
├── UIComponents/ (кастомные вью, утилиты)
└── Core/ (общие утилиты, extensions)

Пример зависимости в коде:

// В главном модуле (App)
import AuthModule
import NetworkModule

@main
struct MyApp: App {
    // Внедрение зависимостей
    let authService = AuthModule.AuthService()
    let apiClient = NetworkModule.APIClient()
}

Решаемые проблемы и best practices:

  1. Циклические зависимости: Выносите общие типы, протоколы или утилиты в отдельный модуль (например, Core или SharedModels), от которого будут зависеть оба конфликтующих модуля.
  2. Публичный интерфейс: Четко определяйте public и internal сущности в каждом модуле, чтобы скрыть детали реализации.
  3. Динамические vs Статические фреймворки:
    • Динамические (DYNAMIC_LIBRARY): Уменьшают размер исполняемого файла и время запуска, но усложняют дистрибуцию.
    • Статические: Включаются в бинарник, проще в распространении, но увеличивают его размер и время компоновки.
  4. Тестирование: Создавайте отдельные модули-мишени для юнит- и UI-тестов каждого функционального модуля. Используйте протоколы для легкого создания моков.
  5. CI/CD: Для ускорения сборок настраивайте кэширование собранных модулей с помощью инструментов вроде Tuist или собственных скриптов.

Ответ 18+ 🔞

А, ну, многомодульная архитектура, говоришь? Это когда ты свой проект, как этого... умного дурачка, на кусочки разбираешь, чтобы потом не орать "бля, я ничего не понимаю, где что лежит!". По сути, берёшь монолитную кашу и раскладываешь по аккуратным баночкам: вот логика входа, вот сетевое общение, вот красивые кнопочки.

Чем это, блядь, полезно?

Ну, во-первых, инкапсуляция, ёпта! Один модуль про другой нихуя не знает, кроме того, что тот на публику выставил. Как в хорошем подъезде — соседи не лезут к тебе в холодильник. Во-вторых, переиспользование — взял баночку с кнопками и тыкаешь её в разные проекты, как универсальную отвёртку. И главное, скорость сборки! Собрал один раз модуль, закешировал — и дальше он как орешек, щёлкается моментально, а не пересобирается каждый раз, будто впервые мир увидел.

Чем этим хозяйством управлять?

  • Swift Package Manager (SPM): Это наш, родной, от Apple. Всё честно, в Package.swift прописываешь, кто от кого зависит. Модно, молодёжно, в тренде.
  • CocoaPods / Carthage: Старая гвардия, блядь. Ещё живы, ещё работают, многие проекты на них сидят, как на диване. Поддерживают модульность, но иногда с ними как с упрямым ослом — договориться надо.

Как это выглядит в папках? Представь, что твой проект — это коммуналка:

MyApp/ (Общая квартира, главное приложение)
├── AppFeature/ (Старший по подъезду, всё собирает в кучу и DI-шприцем колет)
├── AuthModule/ (Консьержка с ключами. Логин, пароли, сессии)
├── NetworkModule/ (Почтальон Печкин. Ходит в интернет, приносит данные)
├── UIComponents/ (Дизайнер-архитектор. Красивые кирпичики-кнопки)
└── Core/ (Подвал с общим инструментом. Расширения, утилиты, которые всем нужны)

А в коде как это смотрится?

// В главном модуле (App), который всех собирает
import AuthModule // Импортируем консьержку
import NetworkModule // Импортируем почтальона

@main
struct MyApp: App {
    // А вот и внедрение зависимостей, или, проще говоря, "на, держи, работай"
    let authService = AuthModule.AuthService()
    let apiClient = NetworkModule.APIClient()
}

Подводные ебучки и как с ними бороться:

  1. Циклические зависимости: Это пиздец, товарищ. Когда модуль А хочет модуль Б, а модуль Б в ответ "иди на хуй, я без модуля А не могу". Решение — вынести их общие понты (типы, протоколы) в отдельный модуль-арбитр, типа Core или SharedModels. Пусть оба от него зависят, как дети от папы с ремнём.

  2. Публичный интерфейс: Тут главное — не выносить сор из избы. Объявляй public только то, без чего другие модули сдохнут. Всё остальное — internal, пусть сидит внутри и не выёбывается. Сокрытие реализации, ёпта, основа основ.

  3. Динамические vs Статические фреймворки:

    • Динамические: Как общая библиотека в доме. Библиотека одна, а пользуются все. Размер приложения меньше, запускается быстрее. Но если библиотеку (фреймворк) потерять при доставке — пиздец, приложение не запустится.
    • Статические: Как если бы каждый житель таскал свою личную копию "Войны и мира" в рюкзаке. Размер приложения — овердохуища, но зато запустится везде, даже в глухом лесу без библиотек.

  4. Тестирование: Для каждого серьёзного модуля заводи отдельную мишень для тестов. Хочешь протестировать логику входа? Тестируй AuthModuleTests, не трогая всю остальную банду. А чтобы мокировать зависимости — используй протоколы. Подсунул тестовую заглушку вместо реального почтальона — и проверяй, как консьержка с ней общается.

  5. CI/CD: Чтобы не ждать сборки по полчаса каждый коммит, надо кэшировать уже собранные модули. Настроишь кэш — и следующие сборки будут летать. Для этого есть Tuist или свои костыли-скрипты. В общем, думай головой, а не жди милости от дженкинса.

© ХакСобесов, 2026
support@hacksobesov.com