Комментарии 6
НЛО прилетело и опубликовало эту надпись здесь

Достаточно подробно описано как делать, за что плюс.
Я каждый раз когда создаю framework ручками трачу на это час… Ибо пока вспомнишь как ты это делал год назад. Swiftpm или cocoapods избавляют от этого гемора.


Из не описанных минусов, это уменьшение холодной скорости запуска приложения. Где-то на 0.1 секунду за 1 framework (время зависит от многих факторов).
Когда начинаешь делить, модулей неожиданно становится слишком много, и проблема усиливается


Одно из решений это делать всё на статических либах, а не framework. Правда в этом случае придётся думать о ресурсах — и тут или Cocoapods в помощь или как в монолите — ресурсы оставить в одном месте.


P.S. Моё дело предупредить, а использовать это знание или нет решать не мне ;) вдруг проект на 10 модулей — одна секунда холодного запуска конечно много, но не критично.


P.P.S. Как показывает практика вначале лучше делить монолит разложив всё по обычными папкам, и только потом делать физическое деление.

Да, я как раз начинал с того, что решил записать, чтоб не забыть)
Спасибо, про скорость согласен, но все индивидуально.
Рекомендую посмотреть в сторону xcodegen (https://github.com/yonaskolb/XcodeGen) — с ним любую папку сделать фреймворком можно парой строчек и проект становится хорошо структурированным в файловой системе.
Да, мы тоже к нему долго присматривались, но когда стало все больше модулей, конфликты в файле проекта практически не возникают.
Я сейчас не про его возможность убрать конфликты merge'ей xcodeprpoj-файлов, а именно про фреймворки: то что любую уже существующую папку из монолита можно в несколько строчек вынести в отдельный фреймоворк без ручной работы по кликанью окошек в xcode, которая описана в этой статье. И прописать кастомные параметры, если нужно. Самое главное что это легко может сделать любой junior по аналогии с уже существующими фреймворками в конфиге.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.