Тернистый путь внедрения Swift Package Manager. Доклад Яндекса / Comments / Habr

vadimsmal Aug 2 2021 at 14:43

Спасибо за статью, интересный опыт.

Я бы хотел поделиться своими мыслями после прочтения.

Почему мы не остановились на Xcode-проекте?

Все перечисленные вами проблемы решаются генераций проектов, например через xcodegen (есть и другие решения)

Почему не CocoaPods? У него свои особенности. Тоже иногда приходится что-то допилить, например, в post-install-фазе, чтобы проекты собирались.

Во всех решениях есть свои особенности и везде что-то нужно допиливать.

Второй недостаток: можно сделать Mixed Framework

Это не проблема cocoapods, это не доработка со стороны SPM. Если хочется, можно сделать очень простую проверку на Mixed Code.

Третья проблема — Ruby. ... Последняя сложность — на мой взгляд, довольно сложно написать Podspec

Podspec это класс, если хочется можно использовать наследование или можно сделать Podspec генерацию из yml.

При этом более серьезные проблемы с SPM при сравнение вы не упомянули:

Проблема с ресурсами в предыдущих версиях SPM ( упомянуто по ходу статьи )
Нельзя работать с конфигурациями ( упомянуто по ходу статьи )
Лаги от того что Xcode проверяет/скачивает внешние зависимости при открытие проекта
Проблема с индексаций при большом количестве модулей так же есть и с SPM ( не думаю что это проблема SPM, но все же )
Версия SPM сильно привязана к версии Swift и Xcode, что иногда создает проблемы при обновлении с учетом того что интерфейс SPM часто меняется
Многие вещи, например такие как добавления нового этапа сборки, или pre-build фазы нужно делать вручную сторонними решениями.
Все еще много внешних зависимостей не поддерживают SPM, особенно enterprise ( которые предоставляются библиотеками ). Часто такие зависимости предоставляются уже собранными библиотеками и дополнительным этапом сборки для среза под определенную архитектуру ( fat framework ).
Без сторонних решений, ручной code signing все еще не возможен с SPM

Я не утверждаю что SPM сырой, но хотел показать что на мой взгляд сравнение в начале статьи сделано не корректно.

Я посчитал важным оставить этот комментарий, так как другие разработчики могут посмотреть эту статью и "на веру" выбрать SPM исходя из указанного сравнения.