Сможет ли SwiftPM заменить CocoaPods?

В ожидании WWDC 2020, который, к слову, впервые будет проходить в онлайн режиме из-за всем известных событий, предлагаю вспомнить интересные (пока ещё) новинки (зачёркнуто) с прошлогодней конференции разработчиков Apple.

Сегодня предлагаю поговорить о SwiftPM – менеджере зависимостей от Apple.

В прошлом году вместе с релизом Xcode 11 Apple показала Swift Package Manager – собственный аналог менеджера зависимостей CocoaPods.

Я решил немного покопаться в нём и разобраться сможет ли он заменить всем привычный и любимый CocoaPods.

Спойлер: нет, не сможет. В целом, использование SwiftPM для меня было хорошим опытом, но как и ожидалось у него есть недочеты.

Действительно простое добавление пакетов. Вам больше не нужно поддерживать Podfile, а сам Xcode, имея отличный пользовательский интерфейс, позволяет в несколько кликов добавить необходимый пакет зависимостей.

Xcode отображает ваши зависимости в боковом меню понятно и организованно. Он даже показывает текущий номер версии пакета, что мне очень нравится.

На мой взгляд, очень удобно иметь такой "first-party" инструмент, поскольку больше не нужно ничего дополнительно устанавливать. Если вы работаете в команде и используете решение от Apple вашим коллегам также нет необходимости в установке дополнительных инструментов (что немаловажно).

Больше нет необходимости в использовании Xcode workspace или как-то иначе вмешиваться в процесс билда. First-party инструмент означает, что мы можем быть уверены, что все будет создано и прилинковано правильно.

Важно: SwiftPM как и CocoaPods – это open-source проект и вклад в его развитие может принести каждый. Может это и не будет быстро но все же это возможно.

Что касается приватных пакетов, использование их значительно проще использования приватных "подсов". Нет необходимости постоянно поддерживать private specs repo. Достаточно просто добавить приватный пакет прямиком в Xcode (аналогично как с open-source).

Войдя в аккаунт Github в настройках Xcode при добавлении новой зависимости вам будет виден список всех репозиториев вашего аккаунта.

Стоит отметить, что при работе в команде, всем ее участникам нужен будет доступ к репозиториям приватных пакетов.

Файл Package.resolved хранится в директории проекта, так что его можно быстро проверить в Source Control.

Подводя итог по плюсах я могу сказать, в целом, опыт как разработчика, отличный. Всё как обычно у Apple – «just works», как и ожидалось.

Управление зависимостями, встроенное в Xcode, делает разработку гораздо проще.

Нет эквивалента директории Pods, которую создает CocoaPods. Проверка вашей директории Pods всегда была источником противоречий, но все хотя бы могли сделать этот выбор. С использованием SwiftPM зависимости хранятся глубоко в DerivedData (~/Library/Developer/Xcode/DerivedData/...).

Обновить один пакет невозможно. В целом, обновление пакетов довольно громоздкое. Это делается через меню File > Swift Packages. На данный момент это «все или ничего», и так делать не всегда хочется. В обход этого, вы можете обновить правила версий для одного пакета, но это не идеально.

Файл Package.resolved создается в директории проекта, но хранится в MyApp.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved. Это не серьезная проблема, но было бы приятно, если бы этой файл хранился в корне проекта, или в каком-то более очевидном месте.

Нет никакой гибкости или возможности менять то, как пакеты интегрируются.

При использовании интеграции в Xcode нет возможности прилинковать пакеты к конкретным назначениям (например, при использовании third-party фреймворка для тестирования), или только включать пакеты с особой конфигурацией (например, линкование фреймворка для дебага только в DEBUG).

Как выше упоминалось, SwiftPM – это open-source, но процесс обновлений и фиксов медленнее, чем у CocoaPods, поддерживаемого обществом. CocoaPods может выпускать новые версии с фиксами или новыми возможностями быстрее. SwiftPM же привязан к расписанию обновлений Xcode.

На данный момент SwiftPM не поддерживает библиотеки, смешанные с Objective-C и Swift.

Также, SwiftPM не поддерживает объединение ресурсов, таких как изображения, сториборды, asset catalogs и т.д., хотя вскоре нам обещают такую поддержку.

Я использовал SwiftPM в маленьких и простых проектах. Там я единственный разработчик и только я владею всеми зависимостями. В этих зависимостях нет Objective-C. В таком случае, использование SwiftPM довольно отличное, поскольку минусы, описанные мной, совсем не влияют на меня. Для больших и более сложных приложений, или при работе в команде, мне кажется, что гибкость и кастомизация, которые предоставляет CocoaPods будет предпочтительнее для большинства проектов. Для больших приложений я пока что буду использовать CocoaPods.

И все же, я думаю, что в интеграции SwiftPM в Xcode есть большой потенциал. Большинство проблем, описанных выше, можно легко решить добавлением обновлений каждого пакета, добавлением цели линкования для каждого пакета, добавлением опции оставить директорию SwiftPM/ в корне проекта, включением объединенных ресурсов, и смешивания Objective-C и Swift. Я надеюсь, что над этими недостатками будут работать, но, к сожалению, это будет решено внутренним расписанием обновлений компании Apple.

Официальная документация здесь.