CocoaPods — это очень мощный инструмент, имеющий статус must have для любого iOS Developer'а. С помощью него мы можем легко, быстро и просто подключать различные вкусные тулзы, утилиты и библиотеки, которые значительно облегчают нам жизнь при разработке приложений. Но всяким инструментом надо уметь пользоваться и CocoaPods не исключение.
Под катом информация, которая позволит начать освоение этого инструмента (основано на том, что изложено в документации и собственном опыте). И так, дорогой читатель, отложи в сторону микроскоп, хватит уже им гвозди заколачивать и продолжай читать.

Podfile

Podfile — это как раз и есть та волшебная спецификация, в которой обозначены все зависимости необходимые для нашего проекта. Podfile всегда создает неявную цель (target), названную по умолчанию, которая связывает с первой целью (target'ом) проекта. Этот файл должен быть назван просто Podfile и лежать в одной папке с файлом .xcodepoj.

Для начала очень важно указать для какой платформы и какой ее версии ведется разработка. Это делается вот таким образом:

platform :ios, '8.0'

В этом примере мы указываем, что разрабатываем приложение для iOS версии не ниже чем 8.0

Далее мы можем скрыть все предупреждения от xCode, котоыре касаются подключаемых библиотек:

inhibit_all_warnings!

Target проекта

Если вы хотите использовать подключаемые библиотеки для нескольких target'ов (например для тестов), то для этого можно использовать команду link_with:

platform :ios, '6.0' 

link_with 'MyApp', 'MyApp Tests' 

pod 'AFNetworking', '~> 2.0' 
pod 'Objection', '0.9'

В этом примере мы подключаем библиотеки не только для target'а нашего приложения, но и для тестов. Но с этой командой нужно быть предельно осторожным: эта команда подключает все библиотеки к двум target'ам, а иногда это может привести к ошибкам в работе, например не все привычные нам методы API будут работать для Application Extension (тех же виджетов — Today Extension).

Более надежный способ — вручную задать target'ы для которых будут подключаться те или иные библиотеки:

def shared_pods 
   pod 'AFNetworking' 
   pod 'INTULocationManager' 
end 

target 'myapp' do  
   shared_pods 
   pod 'Reachability', '~> 3.1.1' 
   pod 'sqlite3', '~> 3.8.4.3' 
end 

target 'mywidget' do 
   shared_pods 
end

С помощью такого Podfile'а мы определили те библиотеки, которые будут у нас использоваться и для виджета и для приложения (shared_pods). И обозначили какие именно надо подключать для какого target'а.

Версия библиотеки

Следующий момент тоже очень важен. Чаще всего мы кроме названия библиотеки дополнительно указываем номер версии, которую хотим использовать. Делаем это вот так:

pod 'WebViewJavascriptBridge', '~> 4.1.4'

Так мы это делаем как минимум потому, что подобные рекомендации нам как правило дают в ответе по запросу pod search. И с одной стороны это правильно, но сдругой стороны возможны нюансы.

Небольшой пример.

Вы подключили некую библиотеку (с указанием версии как в примере выше) и активно ее используете, потом на некоторое время приостановили работу над проектом, а вернулись только спустя n времени. И возобновить работу вы решили с команды pod update, которая подтянет новые версии используемых библиотек. Запускаем проект и можем столкнуться с тем, что разработчик библиотеки добавил новые методы, а те что используете вы уже объявил как deprecated или удалил вовсе, или принял merge request от другого программиста проверив его не очень внимательно, а тот допустил критичную ошибку и теперь у нас все крашится.

f***

Как избежать ненужных потерь нервных клеток? Иначе указать версию! Возможностей для этого много.

Таким образом мы указываем точно какая версия нам нужна:

'WebViewJavascriptBridge', '4.1.4'

Кроме этого мы можем использовать и логические операторы, которые пояснять подпробно нет необходимости: '> 4.1.4' или '>= 4.1.4' или '< 4.1.4' или '<= 4.1.4'.

Более подробно нужно рассказать об операторе '~>'. С помощью него мы можем указать версию, которая нам необходимо, но при этом получать нужные для нее bugfix'ы. Например вот так '~> 0.1.2' мы указываем, что хотим использовать версию библиотеки от 0.1.2 и до 0.2, но не включая версию 0.2. Или указав '~> 0.1' мы указываем, что планируем использовать все версии от 0.1 до 1.0, но не включая версию 1.0.
Кроме этого мы можем указать ресурс репозитория с которого будем загружать библиотеку:

pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git'

Но и на этом еще не все. Указав ресурс мы еще можем указать нужную нам ветку,

pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :branch => 'dev'

тег

pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :tag => '0.7.0'

или даже конкретный коммит

pod 'CRToast', :git => 'https://github.com/akhatmullin/CRToast.git', :commit => '082f8310af'

Автоматизируй максимум или post_install

Иногда бывает так, что после установки той или иной библиотеки, нужно открыть тот или иной файл проекта, который был сгенерирован Cocoapods и добавить/убрать/изменить там какой-то параметр чтобы все работало корректно.

Первое что нам приходит в голову в такой ситуации: сделать все как надо и написать в wiki на gitlab'е. Вроде все окей. А! Еще обязательно написать об этом всей команде в Skype… и сделать рассылку в почте! И ссылку на вики обязательно приложу…
Сделано! А теперь все об этом забыли. Как быть? Использовать post_install!

post_install do |add_app_extension_macro| 
   add_app_extension_macro.project.targets.each do |target| 
      if target.name.include?("Pods-widget") 
         target.build_configurations.each do |config| 
            config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS=1'] 
         end
      end
   end
end

В примере выше мы после установки всех необходимых библиотек перебираем в цикле все target'ы проекта автоматически создаваемого cocoapods, находим среди них нужный, а затем перебираем настройки этого target'а и найдя нужную добавляем нужную в build settings. В конкретном примере мы для AFNetworking устанавливаем параметр позволяющий использовать эту библиотеку в Application Extensions. И больше никаких записок в wiki. Совсем! Well done!

Основы использования Cocoapods в разработке приложений под iOS