How to install CocoaPods?
I referred too many links and tried, but had no success. If any one has an idea then please please share with me. I read cocoa pods documents and many times tried to install but always failed because of the starting steps. I found one error whereby I can’t install gems first. Can anyone give me the steps one by one? How to install or demo.
This is one link which I tried.
The screen shot refers to this console error I was given:
24 Answers 24
[ 1 ] Open terminal and type:Gem will get installed in Ruby inside System library. Or try on 10.11 Mac OSX El Capitan, type:
If there is an error «activesupport requires Ruby version >= 2.xx», then install latest activesupport first by typing in terminal.
[ 2 ] After installation, there will be a lot of messages, read them and if no error found, it means cocoapods installation is done. Next, you need to setup the cocoapods master repo. Type in terminal:And wait it will download the master repo. The size is very big (370.0MB at Dec 2016). So it can be a while. You can track of the download by opening Activity and goto Network tab and search for git-remote-https. Alternatively you can try adding verbose to the command like so:
[ 3 ] Once done it will output «Setup Complete», and you can create your XCode project and save it. [ 4 ] Then in terminal cd to «your XCode project root directory» (where your .xcodeproj file resides) and type: [ 5 ] Then open your project’s podfile by typing in terminal:open -a Xcode Podfile
[ 6 ] Your Podfile will get open in text mode. Initially there will be some default commands in there. Here is where you add your project’s dependencies. For example, in the podfile, typepod ‘AFNetworking’, ‘0.9.1’
(this line is an example of adding the AFNetworking library to your project).
Uncomment platform :ios, ‘9.0’ Uncomment user_frameworks! if you’re using Swift
When you are done editing the podfile, save it and close Xcode.
[ 7 ] Then install pods into your project by typing in terminal:Depending how many libraries you added to your podfile for your project, the time to complete this varies. Once completed, there will be a message that says
«Pod installation complete! There are X dependencies from the Podfile and X total pods installed.»
Now close your Xcode project. Then locate and open the .xcworkspace Xcode project file and start coding. (You should no longer open the xcodeproj file)
Mac os pod install
CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over 77 thousand libraries and is used in over 3 million apps. CocoaPods can help you scale your projects elegantly.
CocoaPods is built with Ruby and is installable with the default Ruby available on macOS. We recommend you use the default ruby.
Using the default Ruby install can require you to use sudo when installing gems. Further installation instructions are in the guides.
Search for pods (above). Then list the dependencies in a text file named Podfile in your Xcode project directory:
Tip: CocoaPods provides a pod init command to create a Podfile with smart defaults. You should use it.
Now you can install the dependencies in your project:
Make sure to always open the Xcode workspace instead of the project file when building your project:
Now you can import your dependencies e.g.:
Sometimes CocoaPods doesn’t yet have a pod for one of your dependencies. Fortunately, creating a pod is pretty easy:
You can find a lot of information on the process in the guides. When you’re done you can get an account and push your pod to the CocoaPods Trunk.
Contribute
We’re developing CocoaPods on GitHub. There’s a guide for getting started on the CocoaPods tool. It’s easy and really gratifying to contribute patches! — for a lot of people it’s their first foray into Open Source. We have some easy tickets to look at.
CocоaPods — мощное средство в руках Objective-C разработчика
CocoaPods — это мощное и одновременно изящное средство управления зависимостями Cocoa-библиотек, которые разработчики используют в своих iOS и MacOS X проектах. Как обычно для Cocoa-статей мы сфокусируемся именно на iOS разработке.
iOS-разработчики любит использовать наработки других разработчиков (3rd party разработчиков). И как правило, библиотеки поставляются с исходным кодом. И обычно мы добавляем исходный код библиотек в наш проект, однажды взяв его из репозитория разработчиков. У такого подхода есть несколько недостатков:
- Иногда бывает сложно уследить за версиями библиотек и их связями между собой
- Нет одного общего места, где можно просмотреть список всех доступных библиотек. Безусловно, github — одно из крупных пристанищ opensource-проектов, но не единственное
- Необходимо всегда помнить про то, что исходных код таких библиотек нужно обновлять. (отчасти проблему решили бы средства наподобие git submodules)
- Когда вы скачиваете исходники и добавляете в свой проект часто возникает соблазн изменить код библиотеки локально, что в будущем создать головную боль при обновлении библиотеки.
Средства управлением зависимостями CocoaPods поможет решить многие упомянутые проблемы. CocoaPods разберется с зависимостями между библиотеками, которые вы используете, скачает их, создаст и будет поддерживать структуру проекта в надлежащем виде.
С CocoaPods создать проект, использующий сторонние наработки, намного проще. И так, приступим.
Начинаем
Согласно официальному сайту, CocoaPods — это лучшее средство по управлению зависимостями библиотек в Objective-C проектах.
Вместо скачивания кода из репозитория библиотеки и копирования в папку вашего проекта мы можем предоставить возможность CocoaPods сделать все за нас.
Например, нам необходимо сделать приложение, которые будет общаться с RESTfull API какого-нибудь сервиса, используя JSON.
Наиболее популярная библиотека для работы с HTTP-запросами — это AFNetworking (с тех пор, как ASIHTTPRequest перестала поддерживаться).
Для начала нам необходимо установить CocoaPods. CocoaPods — это Ruby проект, и к нашему счастью интерпретатор Ruby идет в стандартную комплектацию MacOS. Ruby — это единственная зависимость CocoaPods, и сперва нам необходимо обновить список пакетов, в терминале выполнив команду: 
Возможно, для корректной работы нам сперва необходимо будет обновить или установить Command Line Tools for XCode. Сделать это можно, зайдя по XCode > Preferences > Downloads > Components.
После того, как список пакетов обновлен, мы можем установить CocoaPods:
sudo gem install cocoapods &&
pod setup 
CocoaPods установлен.
Hello World
Создаем новый почти пустой проект File > New > Project… > Single View Applciation, для примера: 
Добавляем первую зависимость
Ну вот и он — момент истины. Добавляем нашу первую зависимость в проект.
В терминале переходим в папку проекта и выполняем следующее:
1) Создает Pod-файл 
2) Добавляем библиотеку 
Как можно увидеть, формат файла завиcимостей довольно простой. Мы добавили строку с AFNetworking и указали, что нас интересует последняя, 0.10.0 версия.
Тут подробно рассказано о формате Pod-файла.
3) Генерируем первоначальное окружение, загружаем необходимые файлы как самого CocoaPods, так и исходники библиотек. И главное — будет всегда поддерживать их в актуальном состоянии:
pod install 
После выполнения этих несложных процедур мы получаем новую заготовку проекта. Теперь работать с ним нужно через сгенерированный xcworkspace. То есть забудьте о файле проекта как о самостоятельной сущности, только workspace!
Вот так будет выглядеть структура проекта 
Теперь можно смело подключать AFNetworking.h и использовать эту библиотеку будто вы сами только что скачали ее исходники и разместили их в своем проекте. 
Собственно, это, пожалуй, основной путь работы с CocoaPods. Основной, минимальный и простой.
Файл с зависимостями можно будет дополнить, разбавив одинокий AFNetworking:
pod ‘SSToolkit’
pod ‘AFNetworking’, ‘>= 0.5.1’
pod ‘CocoaLumberjack’
Суть не меняется, простота работы не пропадает.
Вот список наиболее популярных библиотек, доступных через CocoaPods:
- AFNetworking
- ASIHTTPRequest
- BlocksKit
- ConciseKit
- CorePlot
- EGOTableViewPullRefresh
- Facebook-iOS-SDK
- JSONKit
- MBProgressHUD
- Nimbus
- QuickDialog
- Reachability
- SFHFKeychainUtils
- ShareKit
CocoaPods однозначно можно отнести к must have средствам в арсенале Cocoa-разработчика. 
Похожие публикации
Еще с десяток полезных opensource-библиотек для iOS-разработчика
А вы точно инициализируете стек Core Data правильно?
Системы тестирования iOS-приложений
Вакансии компании Luxoft
Комментарии 52
Добавьте уж и создание своих Podspec’ов (например для использования чужого репа), разделение подов по таргетам, ну само создание собственного подспека. А то так статья кажется какой-то неполной.
За обзор спасибо, этот инструмент нужно внедрять в массы.
ЗЫ. почему AFNetworking а не RestKit?
>>> этот инструмент нужно внедрять в массы.
Только не забывайте предупреждать массы о том что это по своей сути костыль copypaste вселенских масштабов.
А на мой взгляд, внедрять в массы нужно умение правильно писать свои библиотеки и frameworks. А то iOS developers отстают от своих коллег в этом плане лет эдак на 50.
Что-то не получается (10.8):
Не думаю что эти доки вам пригодятся 😉
Итак, ложка дегтя, о которой автор умолчал:
>> И обычно мы добавляем исходный код библиотек в наш проект, однажды взяв его из репозитория разработчиков.
добавлять нужно не код, а собранные библиотеки и framework
>> Иногда бывает сложно уследить за версиями библиотек и их связями между собой
Когда они ПРАВИЛЬНО собраны в universal library или framework — проблем со связями никаких
>> Нет одного общего места, где можно просмотреть список всех доступных библиотек.
а CocoaPods разве всезнающий?
>>Когда вы скачиваете исходники и добавляете в свой проект часто возникает соблазн изменить код библиотеки локально, что в будущем создать головную боль при обновлении библиотеки.
а сделать fork и послать pull request разработчикам вам не под силу? Или есть неизвестные проблемы с «git remote add» / «git merge»?
Главное — не сказано что из себя представляют эти CocoaPods.
Это script на ruby, который вытаскивает из github исходники и добавляет их в проект по методу «drag and drop», популярному среди так называемых iOS developer. Получается одна толстая библиотека, в которую тупо компилируются все зависимости.
Из минусов варианта со static library/framework то, что разработчики библиотек медленно приходят к этому подходу. приходится некоторое время maintain-ить свой fork.
Уже есть некоторое количество исправленных нами ( github.com/EmbeddedSources ) библиотек
* CLCascade
* TouchXml
* EGOTableViewPullRefresh
* CocoaLumberjack
* MagicalRecord
* RBFilePreviewer
Большинство из оных pull request-ов уже приняты разработчиками библиотек.
>> CocoaPods однозначно можно отнести к must have средствам в арсенале Cocoa-разработчика.
я лично в этом сомневаюсь.
А вы?
>> Некоторые еще и хардкодят при этом.
Вот им и трудно хардкодить. Потому и изобрели CocoaPods.
С моей точки зрения данный инструмент — большой автоматизированный серебряный костыль. Хотя кому-то, возможно, так удобней.
>> как описываете Вы, делают далеко не все
Я не один такой. автор ghUnit тоже так делает. Может, прочитав это обсуждение кто-либо еще пополнит ряды таких людей.
P.S. Не вполне понял вашу орфографию. Уж не взыщите
>>> так или иначе бывает нужно посмотреть как оно работает, или посмотреть бэктрэйс, а вот собранная либа мне этого не позволит
Ну так собирайте на здоровье! Или вы target dependencies не смогли осилить? 
>>> мне не нужно прописывать для каждой либы Other Linker Flags, добавлять Frameworks
да. Добавить собранный framework с помощью «drag and drop» особенно тяжко…
Вам не послышалось: свой framework нужно тащить к Foundation и прочим ( см. картинку выше ).
>>> Да и главный плюс CP на мой взгляд, это то что мне не нужно прописывать для каждой либы Other Linker Flags.
Если есть исходники — делаем dependence ( см. картинку ).
Иначе — у вас есть universal binary + набор headers. Делаем руками из этого всего framework. Дальше — ваш излюбленный drag and drop.
В общем, если это правильно приготовить, то можно обойтись и без hard core типа Linker Flags, и без костылей подобных CocoaPods.
P.S. а немало времени порой занимает наведение порядка в сторонней библиотеке, заточенной под copy paste. А раздражает то, что многие, называющие себя «iOS developer», так и используют copypaste, считая это прекрасным способом повторного использования кода.
Может, для ruby подобный подход и оправдан. Но Objective C++ ведь не интерпретируемый (и слава богу).
P.S. Если у вас еще остались аргументы в пользу CocoaPods — готов выслушать.
Зачем мне что-то собирать и drag’n’drop-ать если я могу все это сделать просто добавив всего лишь одну строчку в файл и запустить команду в терминале? Я привык пользоваться bundler’ом из RoR и подобный подход считаю очень удобным.
Делать форки всех интересующих либ, добавлять в них таргет для фрэймворка… Зачем мне все это если я хочу сэкономить время?
Ни один из ваших аргументов я не считаю существенным минусом.
CP экономит мое время и потому я им пользуюсь.
И, кстати, я в курсе как собирать bundle’ы и я не люблю drag’n’drop.
Видать, все дело в том что я пришел в iOS development из сурового бородатого C++
И уже привычен к ручным ( ну, или с помощью CMake ) сборкам зависимостей.
>>> Зачем мне все это если я хочу сэкономить время?
1. Framework way идеологически более верен для данной платформы. Framework programming guide
2. Для следующих проектов framework добавляется очень быстро и безболезненно. Так же как для Mac OS X, поскольку используется единый xCode.
3. Помочь сообществу, правильно оформив хорошие библиотеки. Чтобы даже команду в терминале запускать не нужно было. Скачал собранный framework, перетащил — и пользуйся на здоровье.
В качестве примера — тот же gh-unit
И да. В случае Ruby обычно executable == source code. В случае C++/Objective-C сей подход не вполне оправдан.
> Чтобы даже команду в терминале запускать не нужно было. Скачал собранный framework, перетащил — и пользуйся на здоровье.
Спорный аргумент. По мне, так поправить файл и запустить `pod install` несколько проще, чем выкачивать и подключать вручную. Особенно когда либы с зависимостями.
Вот только «либу с зависимостями» и framework (хорошо, несколько framework, ежели у нужного вам есть зависимости) путать не стоит.
С библиотеками — да. Возня есть. Но если уж из нее добрые люди скрутили framework, то подключение сводится к «скачал->drag&drop->можно пользоваться».
P.S. Товарищ дело говорит.
>> На вид все довольно просто, но мне кажется для управления зависимостями в проекте предоставляется слишком большая абстракция, делегирование управления и возможность загнать себя в рамки инструмента
Хм, а чем фреймвок с зависимостями принципиально отличается от либы с зависимостями?
И в том и в другом случае необходимо самостоятельно эти зависимосты трэкать, выкачивать и добавлять в проект. Повторить при необходимости обновиться до свежей версии.
Это может еще осложниться тем, что dependent библиотека может поддерживать не все версии своих dependencies.
Инструменты подобные cocoapods как раз и существуют, чтобы этот процесс упростить и автоматизировать.
К аналогичный подходу к dependency management’у рано или поздно приходят многие платформы.
Прототипом данного проекта, насколько я понимаю, является рубишный bundler; похожие по функционалу инструменты уже существуют для erlang (rebar), node.js (npm), с некоторой натяжкой сюда же можно добавить и maven для java.
Framewok == библиотека + headers + resources.
Отличие — интеграция с xCode. Имея framework не нужно ничего прописывать в header search path и linker flags. Нужную зависимость будет добавить так же легко как Foundation или UIKit, предоставляемые Apple.
>> И в том и в другом случае необходимо самостоятельно эти зависимосты трэкать, выкачивать и добавлять в проект.
Не совсем так. Скачать, собрать из них framework и его добавить. Согласитесь, обновление third party библиотек — не столь частая штука, чтобы пересобирать их каждый раз на основе nightly builds.
>> К аналогичный подходу к dependency management’у рано или поздно приходят многие платформы
Ага. Особенно те, у которых source code == executable. То есть, интерпретируемые языки (в основном, они и попали в ваш список).
Ну неправильно это — использовать copy-paste для повторного использования кода в компилируемых языках, таких как C++ и ObjectiveC. В своем любимом .NET или Java вы ведь исходники библиотек не включаете в основной проект? Конечно, нет, ведь вы создаете package (*.dll или *.jar соответственно). Аналогичный подход стоит применять к ObjectiveC, взяв framework в качестве подобного package.
>> Инструменты подобные cocoapods как раз и существуют, чтобы этот процесс упростить и автоматизировать.
Вот если бы CocoaPods собирал мне нужные frameworks, а не тупо вставлял исходники в мой проект (хорошо, в отдельный static library project) — цены бы ему не было. А так это большой и удобный костыль, поощряющий неряшливый стиль работы с зависимостями и построения собственных библиотек.
>> с некоторой натяжкой сюда же можно добавить и maven для java
А если еще больше натянуть, то можно добавить и make для ObjectiveC чего угодно
Так, еще раз. Я не спрашивал, что такое фреймворк. Я спрашивал в чем принципиальное отличие при мэнеджменте зависимостей.
Да, фреймворк, для подключения в проект лучше, чем копирование исходников. Но фреймворк — это не инструмент управления зависимостями. На трэкинг зависимостей сборка фреймворка вообще никак не влияет. Зависимости приходится находить (в простейшем случае они будут в доке/ридми упомянуты) и добавлять по-отдельности.
Вы упорно отказываетесь понимать, что я говорю в первую очередь про dependency-management. А с инструментами подобными cocoapods это делать удобнее.
> Ага. Особенно те, у которых source code == executable. То есть, интерпретируемые языки (в основном, они и попали в ваш список).
Я только что понял, что бы абсолютно не в курсе как работают bundler, npm и иже с ним.
> А так это большой и удобный костыль, поощряющий неряшливый стиль работы с зависимостями и построения собственных библиотек.
> А если еще больше натянуть, то можно добавить и make для ObjectiveC чего угодно
Вот эту иронию я вообще не понял. Если говорить в контексте управления зависимостями maven работает крайне похожим образом.
Но, в целом, можете дальше продолжать ерничать.
>>> Я только что понял, что бы абсолютно не в курсе как работают bundler, npm и иже с ним.
Вы правы. Мне должно быть стыдно?
>>> Зависимости приходится находить (в простейшем случае они будут в доке/ридми упомянуты) и добавлять по-отдельности.
Нормальный maintainer должен бы выложить у себя framework своей библиотеки + набор framework для ее зависимостей. В случае коллизий выбирать или собирать нужный вариант прийдется вручную, но и CocoaPods, вроде как не особо спасает в таких случаях.
Пока таких maintainer не встречал. Обычно код зависимостей также тупо скопирован в репозиторий библиотеки. В лучшем случае автор осилил git submodule.
>>> Да, фреймворк, для подключения в проект лучше, чем копирование исходников.
>>> Не убедили
1. То есть, вы считаете копирование исходников нормальной практикой в случае ObjectiveC?
2. Перечитайте еще раз мою аналогию с Java/.NET package.
ну, не убедил, так не убедил. что поделаешь…
>>> Вы упорно отказываетесь понимать, что я говорю в первую очередь про dependency-management. А с инструментами подобными cocoapods это делать удобнее.
Вы упорно отказываетесь понимать, что я не против dependency management. Я категорически против copy-paste исходников. Для меня это критичней, чем удобство CocoaPods.
Скорее всего, у меня и не получится убедить вас. Вы сделали выбор осознано.
А многие тупо копируют исходники в проект потому что так было написано в tutorial, по которым они осваивали язык. И как раз эта особенность iOS community меня удручает.
да нет, maven тут как раз к месту, очень похожий workflow: прописали зависимости в файле, выполнили коносльную команду, вуаля, зависимости материализованы. Make, если что, зависимостями не управляет.
Еще раз, что плохого в том, что Вы называете «copy-paste»? Под iOS все равно возможна только статическая линковка с зависимостями (кроме системных). Да даже под OS X, где возможна линковка динамическая, любое приложение — это self-contained bundle, со всеми зависимостями, и пользователю глубого фиолетово, будет там Framework или один толстый статически слинкованный исполняемый файл
>>> Даже под Windows/Unix можно все статически влинковать со всеми зависимостями, и и пользователю глубого фиолетово.
Но вы почему-то так не делаете?
В своих java проектах вы ведь используете *.jar, а не перетаскиваете *.java файлы в каждый новый проект? Вот и для ObjectiveC должен работать тот же принцип. К сожалению, не тут-то было.
>>> Make, если что, зависимостями не управляет.
да что вы говорите?
Он как раз зависимостями и управляет. Только не проека, а команд ( компиляции\линковки\установки итд. ). Да, низкоуровнево и не вполне удобно, но управляет ведь!
окей, под управлением зависимостями я понимаю «получение зависимостей по названию и номеру версии, подготовка к сборке проекта с зависимостями».
Вот первого пункта как раз в make нету, а в maven есть
Костыли не нужны. Нужен набор script-ов.
Есть прекрасный target template ( хотя его можно было бы слегка упростить )
github.com/kstenerud/iOS-Universal-Framework
ну это тоже стороннее решение, его нужно ставить и следить чтоб он не потерялся при обновлении версии Xcode.
Ну вобщем я понял Вашу любовь к фреймворкам, окей, Вам так удобнее, вопросов нет.
а Вы потом все ваши «драг-н-дропнутые» фреймворки храните в дереве исходных кодов вашего проекта? Кладете в vcs?
Прелеть CocoaPods еще и в том, что в vcs достаточно хранить свои исходники, .*.xcodeproject и Podfile. Остальное материализуется на машине разработчика командой «pod intstall»
или, еще хуже, используете git submodules для зависимостей?
Простите, но у Вас все куда более костыльно, а Вы подаете это под соусом «более правильного» подхода.
>>> а Вы потом все ваши «драг-н-дропнутые» фреймворки храните в дереве исходных кодов вашего проекта? Кладете в vcs?
в принципе, да. Я их обновляю нечасто. И да, я делаю это руками.
Пока ни с чем сравнимым по размерам с boost под iOS не пользовался ==> vcs не рвался под их тяжестью.
Для особо тяжелых зависимостей, подобных boost или three20 можно написать script, дергающий за xcodebuild в нужных местах.
>>> Простите, но у Вас все куда более костыльно, а Вы подаете это под соусом «более правильного» подхода.
Чую запах holy war
По сравнению с debian apt/aptitude тоже «как-то блекло»
Для c++/objectiveC в этом вопросе повезло меньше чем интерпретируемым .NET, Ruby, Python.
P.S.
А с native кодом этот ваш NuGet умеет работать?
>>NuGet is a free, open source developer focused package management system for the .NET platform
скорее всего — нет.
>>А с native кодом этот ваш NuGet умеет работать?
А за пивом ваш утюг умеет бегать?
NuGet — штука для managed .NET, она как «дубель» — умеет что-то одно, зато умеет хорошо. Поэтому давайте без холиворов. Другое дело, что большинство авторов библиотек для iOS почему-то не хотят сделать последний шаг, а именно грамотно собрать библиотеку. Соглашусь с товарищем moborb — копипаста исходников в свой проект это не просто зло, а зло в квадрате. К сожалению действительно после разработки под .NET возникает ощущение вселенского бардака. Поэтому не стоит пропагандировать инструменты, которые способствуют разрастанию этого бардака. Авторы, делайте фреймворки и будет нам всем счастье.
>>> А за пивом ваш утюг умеет бегать?
Зря вы так…
.NET вполне отлично дружит с native code ( interop, DllImport и прочие радости ). Вот я и поинтересовался, насколько могуч предложенный вами инструмент. Вдруг ваш утюг и вправду можно было за пивком отправить. Эх, мечты-мечты…
No offence, так сказать.
Кроме того, у вас проблема зависимостей неплохо решена с помощью GAC. А NuGet, как я понял, качает, собирает и правильно все в этом GAC размещает.
И это круто.
Хотя во «вселенском бардаке» есть некое свое очарование и романтика.
Не ставит оно в GAC, за что авторам земной поклон, ибо dll-hell временами бывает почище того самого бардака (демонический смех).
Меня поражает другое: за всё время работы с дотнетом, а это с ранних бет, я могу по пальцам рук и ног сосчитать случаи, когда компоненты поставлялись по принципу «скопируйте в папку и поправьте там внутри». А за свой недолгий сравнительно опыт написания под айдевайсы у меня уже нехватает рук и ног соседей по офису. Ввод в строй ARC вообще доставляет нереально, ибо теперь недостаточно просто скопипастить, частенько нужно идти и еще флаги компиляции выставлять (опять же вручную для каждого файлика, за что поблагодарим Xcode). Так вот, к чему этот крик души — что нужно сделать с авторами, чтобы они начали уважать тех, для кого они это разрабатывают?
На вид все довольно просто, но мне кажется для управления зависимостями в проекте предоставляется слишком большая абстракция, делегирование управления и возможность загнать себя в рамки инструмента. Для меня субъективно конечно, но не очень уютно, когда я не могу в должной мере управлять всеми зависимости на любом уровне и использовать любой вид интеграции при этом не терять управление самим проектом в рамках общих правил (возможно это внешнее представление, но как мне кажется в любом случае я не убегу от дополнительной работы). Причем, желательно иметь возможность наглядно представить работу с проектом другому разработчику без лишней преподавательской работы по вниканию и представлению в скрытые правила и требования, которые используются текущей командой, но которые не видны наглядно либо не выясняются на первом этапе занкомства.
Текущая используемая связка которая пришлась мне по вкусу: это хостить проект на том же github.com или bitbucket.org (у меня bitbucket с Mercurial -> свои критерии выбора), а для управления использовать такой замечательный инструмент sourcetreeapp.com. В котором и происходит управление самим проектом и зависимостями. Причем при использовании библиотек/фрейморков у меня есть правило всегда делать «fork» либо «branch» смотря под чем они хостятся, что позволяет мне вносить правки по своим требованиям в сторонние библиотеки, при этом ничего не теряя. Конечно в каталоге проекта есть соответсвующий каталог со всеми подключаемыми библиотеками/фрейморками. Кстати, не знаю как сложилось, но всегда пытаюсь подключать сторонние вещи только в виде исходников + писать тесты собственного на то, что использую из стороннего, чтобы быть в курсе о критических изменениях в сторонних вещам (которые сам не писал). В sourcetree собственно есть свой набор закладок для основного проекта и зависимостей к нему, что позволяет управлять каждым из них. На этом пожалуй и все, что касается моего управления проектами как OSX/iOS разработчика.
Вопрос: кто какие связки еще использует для управления своими проектом и зависимостями внутри их? На самом деле очень интересно. Возможно мой вариант не самый удобный, подсказывайте свои буду рад узнать ваши приемы и инструменты на которые не обратил внимание, как на этот CocoaPods, про который слышал, но не попробовал даже использовать, почему не знаю.