Я бы хотел поделиться своими мыслями после прочтения.
Почему мы не остановились на 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 исходя из указанного сравнения.
Все замеры проводятся на mac mini (2 физических + 2 логических ядра), а разработка ведется на MacBook Pro (4 логических + 4 логических), так что у разработчиков все собирается быстрее.
Время чистой сборки на mac mini сократилось с 600 секунд до 390. А вот инкрементальная сборка с изменением самого тяжелого модуля сократилось с 200 секунд до 25.
С недавнего времени стали собирать статистику по утилизации CPU — какой процент времени xcode собирает фреймворки параллельно на всех ядрах. Это позволяет понять, какие части приложения мешают компилироваться других частям.
Профит есть, и он состоит в поддержании качества приложения.
Сбор метрик позволил несколько раз заметить увеличение времени запуска приложения, найти причину и исправить.
Также они позволяют быстро проверять и валидировать наши эксперименты по улучшениях тех или иных характеристик.
В частности во время процесса модуляризации ( разделения `монолита` на множество модулей ) мы тщательно мониторили технические метрики для достижения оптимальной скорости компиляции, времени запуска и размера.
На основе продуктовых метрик мы также принимали решения о реализации той или иной функциональности.
Мы проводили эксперименты влияния технических характеристик на продуктовые показатели для определения оптимальных значений.
В процессе разработки стараемся принимать решения на основе данных и добавляем новые метрики, если без них сложно принять решение.
Спасибо за статью, интересный опыт.
Я бы хотел поделиться своими мыслями после прочтения.
Все перечисленные вами проблемы решаются генераций проектов, например через xcodegen (есть и другие решения)
Во всех решениях есть свои особенности и везде что-то нужно допиливать.
Это не проблема cocoapods, это не доработка со стороны SPM. Если хочется, можно сделать очень простую проверку на Mixed Code.
Podspec это класс, если хочется можно использовать наследование или можно сделать Podspec генерацию из yml.
При этом более серьезные проблемы с SPM при сравнение вы не упомянули:
Проблема с ресурсами в предыдущих версиях SPM ( упомянуто по ходу статьи )
Нельзя работать с конфигурациями ( упомянуто по ходу статьи )
Лаги от того что Xcode проверяет/скачивает внешние зависимости при открытие проекта
Проблема с индексаций при большом количестве модулей так же есть и с SPM ( не думаю что это проблема SPM, но все же )
Версия SPM сильно привязана к версии Swift и Xcode, что иногда создает проблемы при обновлении с учетом того что интерфейс SPM часто меняется
Многие вещи, например такие как добавления нового этапа сборки, или pre-build фазы нужно делать вручную сторонними решениями.
Все еще много внешних зависимостей не поддерживают SPM, особенно enterprise ( которые предоставляются библиотеками ). Часто такие зависимости предоставляются уже собранными библиотеками и дополнительным этапом сборки для среза под определенную архитектуру ( fat framework ).
Без сторонних решений, ручной code signing все еще не возможен с SPM
Я не утверждаю что SPM сырой, но хотел показать что на мой взгляд сравнение в начале статьи сделано не корректно.
Я посчитал важным оставить этот комментарий, так как другие разработчики могут посмотреть эту статью и "на веру" выбрать SPM исходя из указанного сравнения.
Время чистой сборки на mac mini сократилось с 600 секунд до 390. А вот инкрементальная сборка с изменением самого тяжелого модуля сократилось с 200 секунд до 25.
С недавнего времени стали собирать статистику по утилизации CPU — какой процент времени xcode собирает фреймворки параллельно на всех ядрах. Это позволяет понять, какие части приложения мешают компилироваться других частям.
Сбор метрик позволил несколько раз заметить увеличение времени запуска приложения, найти причину и исправить.
Также они позволяют быстро проверять и валидировать наши эксперименты по улучшениях тех или иных характеристик.
В частности во время процесса модуляризации ( разделения `монолита` на множество модулей ) мы тщательно мониторили технические метрики для достижения оптимальной скорости компиляции, времени запуска и размера.
На основе продуктовых метрик мы также принимали решения о реализации той или иной функциональности.
Мы проводили эксперименты влияния технических характеристик на продуктовые показатели для определения оптимальных значений.
В процессе разработки стараемся принимать решения на основе данных и добавляем новые метрики, если без них сложно принять решение.