Table of Contents

Введение в управление зависимостью в iOS

Современная разработка iOS редко начинается с нуля. Сторонние библиотеки обрабатывают все, от сетевого и JSON-разбора до UI-компонентов и кэширования изображений. Без структурированного подхода ручная загрузка фреймворков, разрешение конфликтов версий и связывание двоичных файлов быстро становится кошмаром обслуживания. Именно здесь приходят менеджеры зависимостей.

CocoaPods и Carthage являются двумя наиболее известными инструментами для управления зависимостями в проектах iOS. В то время как CocoaPods предлагает оптимизированную интеграцию на основе рабочего пространства, Carthage следует децентрализованной философии построения себя. Понимание сильных сторон и компромиссов каждого помогает вам выбрать правильный подход для вашей команды, вашего приложения и вашего конвейера развертывания.

CocoaPods: централизованные и автоматизированные

CocoaPods с момента своего появления был доминирующим менеджером зависимостей. Он использует центральный индекс под названием CocoaPods Specs и генерирует рабочее пространство Xcode, которое обрабатывает все зависимости автоматически. Это означает, что вы можете добавить библиотеку, просто объявив ее в Podfile, запустить команду и немедленно начать импортировать ее в свой код.

Установка и настройка

CocoaPods устанавливается через RubyGems. macOS-корабли с Ruby, но вам может потребоваться обновить или использовать менеджер версий Ruby.

sudo gem install cocoapods

После установки перейдите в каталог проекта и инициализируйте Podfile:

pod init

Это создает файл с открытым текстом под названием Podfile. Затем вы редактируете его, чтобы указать целевую платформу, любой флаг (требуется для библиотек Swift) и необходимые вам зависимости. Типичный Podfile выглядит следующим образом:

platform :ios, '15.0'

target 'MyApp' do
 use_frameworks!

 pod 'Alamofire', '~> 5.7'
 pod 'SwiftyJSON', '~> 5.0'
 pod 'SDWebImage', '~> 5.15'
end

Как только Podfile будет готов, выполните:

pod install

CocoaPods загружает указанные версии, разрешает зависимости и генерирует файл . С этого момента вы должны открыть рабочее пространство, а не оригинал , чтобы создать и запустить ваше приложение.

Расширенные возможности CocoaPods

  • Подвиды: Многие библиотеки позволяют импортировать только подмножество их функциональности. Например, уменьшает двоичный след.
  • Локальные пути: Вы можете указать на локальную папку для частных библиотек:
  • Источники на основе Git: Зависимости могут поступать из любого репозитория Git:
  • Podfile.lock: Этот файл блокирует каждую зависимость от конкретной версии, обеспечивая воспроизводимые сборки в вашей команде и CI.
  • Плагины: Вы можете расширить CocoaPods с помощью плагинов для SwiftLint, Firebase или пользовательских сценариев сборки.

CocoaPods также поддерживает мультиплатформенные цели.Вы можете иметь различные наборы зависимостей для iOS, macOS и watchOS, вставляя блоки внутри одного Podfile.

Post-Install Hooks и кастомизация

Распространенной необходимостью является запуск сценария после каждого . Например, вы можете захотеть удалить архитектуры симулятора из сборок релиза. Это делается с помощью крючка:

post_install do |installer|
 installer.pods_project.targets.each do |target|
 target.build_configurations.each do |config|
 config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '15.0'
 end
 end
end

Такие крючки дают вам мелкозернистый контроль над сгенерированным проектом Pods, но они также добавляют сложности. Чрезмерное использование может затруднить чтение и обслуживание вашего Podfile.

Карфаген: децентрализованный и выключенный

Карфаген использует другой подход. Вместо централизации метаданных, он опирается на теги Git и фактические проекты Xcode каждой библиотеки. Карфаген строит фреймворки на вашей машине и оставляет этап интеграции — перетаскивание фреймворков в ваш проект Xcode — полностью до вас. Это минимальное вмешательство привлекательно для разработчиков, которые хотят полного контроля и меньшего влияния в их контроле версий.

Установка и настройка

Карфаген обычно устанавливается через Homebrew:

brew install carthage

Затем создайте файл с открытым текстом, названный Cartfile в корне вашего проекта. Синтаксис похож на CocoaPods, но указывает на репозитории GitHub или любой источник Git:

github "Alamofire/Alamofire" ~> 5.7
github "SwiftyJSON/SwiftyJSON" ~> 5.0
github "onevcat/Kingfisher" ~> 7.0

После редактирования Картфиль, запустите:

carthage update --platform iOS

Эта команда клонирует репозитории, проверяет помеченные версии и строит фреймворки с помощью Xcode. Полученные двоичные файлы размещаются в папке Carthage/Build/iOS. Затем вы вручную перетаскиваете их в свой проект Xcode в разделе «Рамки, библиотеки и встроенный контент», убедившись, что добавите их в соответствующую цель.

Основные отличия от CocoaPods

  • Никакое рабочее пространство: Карфаген не изменяет файл проекта. Вы сохраняете контроль над ссылками на файлы и настройками сборки.
  • Скорость сборки: Карфаген может кэшировать сборки. На CI можно предварительно построить зависимости для ускорения трубопровода.
  • Версия: Карфаген использует Cartfile.resolved для блокировки версий, аналогичных Podfile.lock.
  • Бинарные фреймворки: Некоторые библиотеки поставляют двоичные файлы. Карфаген может загружать их напрямую, пропуская этап сборки и экономя время.
  • Поддержка XCFramework: С Carthage 0.38 он может выводить XCFrameworks, которые работают бесшовно с Swift Package Manager и устраняют необходимость полоски архитектуры симулятора.

Обработка рамок с зависимостями

Одна из проблем с Carthage заключается в том, что он создает зависимости в последовательности. Если библиотека А зависит от библиотеки В, вы должны перечислить оба в Cartfile. Carthage автоматически разрешает дерево зависимостей, но вам все равно нужно вручную связать все транзитивные зависимости в вашем проекте. Это дает вам видимость каждой бинарной ссылки вашего приложения, но также увеличивает вероятность отсутствия необходимой структуры во время выполнения.

Сравнение какаоподов и карфагена: практическое руководство

Выбор между ними зависит от размера проекта, зрелости команды и рабочего процесса развертывания. В таблице ниже приведены основные компромиссы.

Factor CocoaPods Carthage
Setup complexity Low – one command, workspace generated automatically. Medium – requires manual linking of frameworks.
Build system control Lower – CocoaPods merges project files and may override build settings. Higher – you control project structure and build phases.
Integration with Xcode Tight – workspace includes Pods project, all configurations preset. Loose – you add frameworks manually; no workspace changes.
CI/CD compatibility Good – pod install works reliably in CI, but full rebuild on each run if lockfile changes. Excellent – prebuilt frameworks can be cached; build times are faster.
Swift Package Manager migration Can coexist but may cause conflicts if both manage the same library. Can coexist more easily because Carthage does not modify project files.
Community and library availability Widest coverage – almost every popular library has a CocoaPods spec. Good coverage – but some niche libraries may not be Carthage-friendly.

Когда использовать CocoaPods

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

Когда использовать карфаген

  • Вы цените модульность и хотите избежать раздувания «проекта Под».
  • Ваше приложение большое, и вам нужно оптимизировать время сборки, кэшируя предварительно построенные фреймворки.
  • Вы переходите на Swift Package Manager и хотите постепенного перехода без нарушения существующих интеграций.
  • Вы работаете в команде, которая предпочитает поддерживать проект Xcode на плаву и вручную управлять настройками сборки.

Миграция между менеджерами по иждивенцам

Переключение с CocoaPods на Carthage или наоборот возможно, но требует тщательного планирования.

Миграция из CocoaPods в Карфаген

  1. Удалите Podfile, Podfile.lock и рабочее пространство.
  2. Удалите любые фазы сборки, связанные с Pods (например, «Embed Pods Frameworks»).
  3. Создайте карт-файл и перечислите те же библиотеки (обеспечивая их поддержку Карфагена).
  4. [[19]] [[[19]]]
  5. Ручно добавьте каждый фреймворк из Carthage/Build/iOS в проект Xcode.
  6. Обновите все заявления об импорте - в соответствии с Карфагеном вы импортируете фреймворки напрямую (например, ).
  7. Тщательно проверяйте; транзитивные зависимости теперь могут нуждаться в явной связи.

Миграция из Карфагена в CocoaPods

  1. Удалите связанные с Карфагеном этапы сборки и ссылки на фреймворк из проекта Xcode.
  2. Удалить картридж и Cartfile.resolved.
  3. [21] Создать [[ВИДЕО]]
  4. Добавьте все зависимости с соответствующими ограничениями версии.
  5. Запустите , а затем откройте новое рабочее пространство.
  6. Проверяйте дублированный импорт - CocoaPods могут встраивать библиотеки по-разному.
  7. Если необходимо, обновите настройки сборки (например, ).

Лучшие практики для обоих менеджеров

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

  • Обязательные файлы блокировки: Всегда передайте Podfile.lock или Cartfile.resolved для контроля версий. Это гарантирует, что каждый член команды и сервер CI использует точно такие же версии.
  • Версии для пин-кодов: Используйте оптимистичные операторы , чтобы разрешить незначительные обновления при блокировке основных изменений. Укажите точные версии только тогда, когда вам нужна абсолютная стабильность.
  • Обновления запуска намеренно: Не запускайте или без просмотра журналов изменений обновленных зависимостей.
  • Аудит совместимости версий Swift: Некоторые библиотеки могут не поддерживать версию Swift, используемую вашим проектом.Проверьте, соответствует ли ветвь или тег зависимости вашей платформе Swift.
  • Удалите неиспользуемые зависимости: Периодически просматривайте свой Картфиль или Подфиль и удаляйте библиотеки, которые больше не используются.
  • Рассматривайте SPM для новых проектов: Swift Package Manager теперь встроен в Xcode и поддерживается большинством крупных библиотек. Если вы начинаете с нуля, SPM может быть самым простым выбором. И CocoaPods, и Carthage остаются отличными для управления крупными унаследованными проектами или частными фреймворками.

Устранение общих проблем

CocoaPods: «Спектр не найден»

Обычно это означает, что библиотека не была перенесена в багажник CocoaPods или вы используете неправильное имя. Проверьте имя капсулы на cocoapods.org . Если библиотека является частной, вам нужно указать ее источник в вашем Podfile.

CocoaPods: конфликты в транзитных зависимостях

Запустите и проверьте выход. Возможно, вам потребуется добавить явные ограничения версии для транзитивных подиумов. Используя и свежий , можно сбросить граф зависимостей.

Карфаген: «Нет такого модуля» при строительстве

Часто это происходит потому, что фреймворк был построен не для правильной платформы (например, вы построили с по ошибке). Перезапустите и проверьте папку вывода. Также убедитесь, что вы добавили фреймворк в раздел «Рамки, библиотеки и встроенный контент», а не только навигатор проекта.

Карфаген: строительство не удается из-за отсутствия зависимостей

Если библиотека, которую вы используете, имеет свои собственные зависимости (например, зависимости RxSwift), вы должны перечислить их в своем Картфиле. Карфаген не загружает автоматически транзитивные зависимости, если они не отображаются в Картфиле или не указаны в качестве субмодулей.

Гибридные подходы: использование как какаоподов, так и карфагена

При смешивании менеджеров зависимостей в одном проекте не рекомендуется, некоторые команды делают это по необходимости. Например, критическая библиотека может быть доступна только через CocoaPods, в то время как остальная часть проекта использует Carthage. Если вы должны объединить их, держите рабочее пространство CocoaPods отдельно и вручную связывайте каркасы Carthage. Будьте в курсе потенциальных конфликтов в дублирующихся символах или перекрывающихся ресурсах. Проще всего выбрать одного менеджера и перенести любые библиотеки, которые не поддерживаются.

Будущее управления зависимостью от iOS

Swift Package Manager (SPM) сейчас считается стандартом Apple и интегрирован непосредственно в Xcode 11 и более поздние версии. Большинство библиотек с открытым исходным кодом добавили поддержку SPM, а SPM устраняет необходимость в внешних инструментах. Однако и CocoaPods, и Carthage по-прежнему имеют преимущества:

  • CocoaPods предлагает богатую настройку через крючки и плагины, а его репозиторий спецификаций остается крупнейшей коллекцией библиотек iOS.
  • Карфаген Карфаген дает вам полный контроль над процессом сборки и его легче кэшировать, что делает его популярным в CI-тяжелых рабочих процессах.

Многие команды используют SPM для новых зависимостей, сохраняя устаревшие интеграции с CocoaPods или Carthage.Со временем SPM, как ожидается, станет по умолчанию, но на данный момент понимание всех трех инструментов позволяет работать на любой кодовой базе iOS.

Заключение

Эффективное управление зависимостью является краеугольным камнем профессиональной разработки iOS. CocoaPods предоставляет решение под ключ, которое автоматизирует весь процесс интеграции, что делает его идеальным для команд, которые хотят скорости и простоты. Carthage предлагает более стройный, более прозрачный подход, который дает разработчикам детальный контроль над системами сборки и структурой проекта. Овладев обоими инструментами, вы можете выбрать правильный подход для размера, сложности и рабочего процесса вашего проекта. Что бы вы ни выбрали, всегда делайте блокировки файлов, сознательно обновляйте зависимости и следите за развивающимся ландшафтом Swift Package Manager.

Для дальнейшего чтения, изучите официальные руководства CocoaPods и репозиторий Carthage GitHub .