TGLIST.COM.UA
Джерело
Затишна Галера | iOSКомпас 🧭1️⃣7️⃣6️⃣ Завдання 176Модуляризація iOS-застосунків через S...
Затишна Галера
@Zatishna_Galera
522 Охват/переглядів
2026-10-14 09:46
Повідомлення №3054
#iOSКомпас 🧭
1️⃣7️⃣6️⃣ Завдання 176
Модуляризація iOS-застосунків через SPM: як навести лад у залежностях.
Доброго здровля мої любі друзі. З вами ваш незмінний ios розробник Сергій з @badlinkschannel.
Сьогодні хочу обговорити статтю (https://kylebrowning.com/posts/modularizing-swift-apps-with-spm/) про організацію залежностей у великих проєктах за допомогою локальних SPM-пакетів. Коли проєкт виростає з кількох десятків файлів, монолітний таргет починає боліти. Збірки сповільнюються, зміна в одному місці перекомпілює половину проєкту, будь-який файл може імпортувати що завгодно.
🔣 Три шари, один потік залежностей:
Автор ділить весь застосунок на три рівні:
➖ Common - найнижчі утиліти: логери, розширення, хелпери. Не залежать ні від чого всередині проєкту.
➖ Services - два підмодулі: API (мережеві моделі та ендпоїнти) і Domain (бізнес-логіка, сервіси, моки). Domain залежить від API та Common.
➖ Features - екрани на SwiftUI. Імпортують тільки Domain і Common. Ніколи - API.
Залежності течуть строго знизу вгору. Модуль може залежати тільки від того, що лежить під ним.
🔣 Як це виглядає в Package.swift:
У маніфесті всі залежності оголошуються явно. Кожен таргет знає, від кого він залежить. Якщо хтось спробує імпортувати модуль мережевого шару прямо з фічі - проєкт просто не збереться. Компілятор не дасть порушити архітектуру.
🔣 Що в кожному модулі:
➖ API - контракт із сервером: мережеві моделі та типізовані ендпоїнти.
➖ Domain - тут відбувається основна робота: моделі предметної області, мапінг з API-моделей у доменні, сервіси (closure-based, без протоколів) і моки. Моки теж живуть тут, тому що повертають доменні моделі, а не API-шні.
➖ Features - чисто UI. Імпортують тільки Domain і використовують моки для прев'ю. Жодного мережевого шару всередині.
🔣 Environment для ін'єкції:
Сервіси можна прокидати через SwiftUI Environment. У прикладі автора вони реєструються через EnvironmentValues і @Entry. Прев'ю використовують .mock, а застосунок отримує реальні реалізації сервісів.
#️⃣ Модуляризація через локальні SPM-пакети - це не про ідеальну архітектуру заради архітектури. Це про швидкість і масштабованість. Коли проєкт росте, модулі дають зрозумілі межі, незалежне тестування та швидші інкрементальні збірки. У результаті новому розробнику простіше зрозуміти структуру, а зміна однієї фічі не змушує перебудовувати весь застосунок.
@Zatishna_Galera
1️⃣7️⃣6️⃣ Завдання 176
Модуляризація iOS-застосунків через SPM: як навести лад у залежностях.
Доброго здровля мої любі друзі. З вами ваш незмінний ios розробник Сергій з @badlinkschannel.
Сьогодні хочу обговорити статтю (https://kylebrowning.com/posts/modularizing-swift-apps-with-spm/) про організацію залежностей у великих проєктах за допомогою локальних SPM-пакетів. Коли проєкт виростає з кількох десятків файлів, монолітний таргет починає боліти. Збірки сповільнюються, зміна в одному місці перекомпілює половину проєкту, будь-який файл може імпортувати що завгодно.
🔣 Три шари, один потік залежностей:
Автор ділить весь застосунок на три рівні:
➖ Common - найнижчі утиліти: логери, розширення, хелпери. Не залежать ні від чого всередині проєкту.
➖ Services - два підмодулі: API (мережеві моделі та ендпоїнти) і Domain (бізнес-логіка, сервіси, моки). Domain залежить від API та Common.
➖ Features - екрани на SwiftUI. Імпортують тільки Domain і Common. Ніколи - API.
Залежності течуть строго знизу вгору. Модуль може залежати тільки від того, що лежить під ним.
🔣 Як це виглядає в Package.swift:
У маніфесті всі залежності оголошуються явно. Кожен таргет знає, від кого він залежить. Якщо хтось спробує імпортувати модуль мережевого шару прямо з фічі - проєкт просто не збереться. Компілятор не дасть порушити архітектуру.
🔣 Що в кожному модулі:
➖ API - контракт із сервером: мережеві моделі та типізовані ендпоїнти.
➖ Domain - тут відбувається основна робота: моделі предметної області, мапінг з API-моделей у доменні, сервіси (closure-based, без протоколів) і моки. Моки теж живуть тут, тому що повертають доменні моделі, а не API-шні.
➖ Features - чисто UI. Імпортують тільки Domain і використовують моки для прев'ю. Жодного мережевого шару всередині.
🔣 Environment для ін'єкції:
Сервіси можна прокидати через SwiftUI Environment. У прикладі автора вони реєструються через EnvironmentValues і @Entry. Прев'ю використовують .mock, а застосунок отримує реальні реалізації сервісів.
#️⃣ Модуляризація через локальні SPM-пакети - це не про ідеальну архітектуру заради архітектури. Це про швидкість і масштабованість. Коли проєкт росте, модулі дають зрозумілі межі, незалежне тестування та швидші інкрементальні збірки. У результаті новому розробнику простіше зрозуміти структуру, а зміна однієї фічі не змушує перебудовувати весь застосунок.
@Zatishna_Galera