SPM або модульність в iOS додатках

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вступ

Звичайно, що це доволі очевидні речі, особливо для Front-end розробників. Когось ця стаття може дратувати або викликати питання: «Нашо такі очевидні речі?». Як показує практика вони не настільки очевидні.

Почнемо з самого початку, що таке SPM та навіщо він потрібен в iOS/mac/whatever епл додатках?

SPM

Swift package manager. Головне, мабуть, тут те, що це менеджер. Залежності в Swift/Objective-C з різними пакетами через CocoaPods (чи хтось досі використовує?) це дуже складне питання. Коли ви стикаєтесь з тим, щоб окремі модулі використовували окремі бібліотеки це стає болем. SPM полегшує цю залежність та контрольованість. Ruby дуже потужний інструмент та мова програмування, але все ж менеджити версії + володіти нею може бути зайвим для iOS-розробника.

То ж SPM. Дуже проста структура, підтримується Xcode, доповнюється, стандартні ШІ, типу Copilot теж розуміють. Далі на скріні стандартна стуктура SPM файлу. Наразі використовується Swift 5.7, це легко переключити та перейти на новішу версію. На одному з проектів ми використовували фікс-версії, на інших просто підіймали до 5.10, що дозволяло не перейматись наступними. Swift 6, звичайно, дуже круто класно, але мало проєктів готові вкладати кошти заради надійності, а не швидкості розробки.

Тут SPM слугує менеджером залежностей та можливістю підключити Network Layer там, де він потрібен.
Має сенс розказати про .lock файл, який фіксує версії залежностей. Це той самий файл, до якого всі звикли. Він блокує оновлення версій допоки розробник сам не скаже, що треба оновитись. Є різні бачення до цього підходу: хтось каже, що от тільки на фіксованій версії треба. Хтось каже, що якщо щось змінили то залити на Гіт із лок-файлом. Тут немає однієї думки, в кожній команді має вирішуватись окремо дивлячись на те, як часто змінюються залежності.
Окремий маленький модуль, який буде слугувати лише одній цілі: викликати потрібний енд-поінт та повернути результат. Які можливості це дає:
1. Тестованість. Кожен окремий модуль може бути відтестований та перевикористаний
2. Написано один раз та може перевикористовуватись
3. Прописано однією строкою в залежностях
Звісно, що не можемо пройти повз Dependency Injection та його застування.

Dependency Injection

Мабуть найпоплярнішим серед розробників менеджер є Swinject. Модуль, який дозволяє зберігати інстанс в контейнері або ініціалізувати по запиту. Особисто для себе написав трохи зручніший інструмент, на основі цього пакету.

Головна тема: SPM. Дозволяє «на льоту» додавати сервіси, які вам потрібні.

Оскільки код вже скомпільований на моменті, коли ви його запускаєте на тести чи просто прогнати на девайсі, то на цьому моменті можна підставити будь-який сервіс, який буде імплементувати «зрозумілий» сервіс.
Дуже цікаво стає, коли окремий сервіс використовує «@propertyWrapper» та йому надалі підсовують мок з потрібними сервісами для тестів.

CI/CD

Головними артефактами для програм автоматичної компіляції є попередні скомпільовани додатки. SPM дозволяє зекономити час на компіляції бібліотек та 3rd-party пакетів, адже більшість систем можуть їх підтягувати з кешу. На одному з проєктів це дозволило звільнити потужності майже вдвічі, з 20 хвилин на cold build, до 10. Простіше зробити декілька білдів на окремі пакети один раз, аніж кожного разу компілювати «моноліт» зі всіма залежностями.

Profit

Маючи маленькі SPM модулі-сервіси можна отримати буст по продуктивності локально. Зберігати та перевикористовувати код локально в різних проєктах. Один раз протестовано та написано = менше часу на розробку наступного

Дякую за увагу. Можливо для вас буде щось цікаве