CocoaPods Schnelleinstieg

CocoaPods ist das Tool der Wahl, wenn es darum geht, Abhängigkeiten eines Projekts zu verknüpfen. CocoaPods ist kostenlos und quelloffen – das Beste ist jedoch dass man auch eigene Bibliotheken, die z.B. nur intern genutzt werden problemlos hinzufügen kann. Los gehts.

Installation

Die Installation verläuft angenehm simpel. CocoaPods ist in Ruby geschrieben, was allerdings bei Mac OS immer vorinstalliert ist. Daher reicht es, in einem Terminal den Befehl

$ sudo gem install cocoapods

einzugeben. Danach kann über

$ pod -v

Überprüfen, ob die Installation auch funktioniert hat. Bei mir sieht die Ausgabe davon im Moment so aus, wobei sich die Versionsnummer natürlich stets ändert.

$ pod --version
0.33.1

Wunderbar, wäre dieser Teil geschafft.

Verwendung

CocoaPods besteht in erster Linie aus dem oben schon aufgerufenen Programm 'pod'. Bevor wir jedoch CocoaPods wirklich benutzen können, sind zwei Dinge notwendig. Zum ersten ist das ein leeres Xcode-Projekt. Dazu Xcode öffnen und dort ein neues, leeres iOS-Projekt anlegen. Da wir das Projekt selbst nur am Rande und zum testen unserer Konfiguration verwenden, ist egal welches Projekt-Template verwendet wird. Wichtig ist nur, dass der Ort des Projekts bekannt ist, so dass wir unkompliziert dorthin navigieren können.

Podfile

Dieses neue Projekt ist ziemlich leer und im Moment noch ziemlich nutzlos. Um das zu ändern, wollen wir 2 Bilbliotheken einbinden. Was früher ziemlich aufwendig war, geht dank CocoaPods recht schnell. Als erstes wird eine sog. Podfile benötigt, die Informationen enthält mittels denen CocoaPods bestimmt, welche Plattformen unterstützt werden sollen und welche Abhängigkeiten benötigt werden. Wer sich mit Maven aus der Java-Welt oder Bundler von Ruby auskennt erkennt ein Schema: Eine Konfigurationsdatei ist Grundlage für ein weiteres Tool, dass dann die notwendige Projektkonfiguration erstellt oder aktualisiert. Eine einfache Podfile besteht mindestens aus der Angabe der Plattform, auf der das Projekt basiert.

platform :ios, '7.1'

So weiss CocoaPods, dass unsere Build-Plattform iOS 7.1 ist. Abhängigkeiten werden bei CocoaPods pods genannt, in Anlehnung an die Kakaobohne (Cocoa), die Bohnen in sog. Pods, den Schalen, enthält.

Kakaobohnen in Schalen
Kakaobohnen in Schalen

Jedes Pod definiert genau eine Abhängigkeit. Will man z.B. AFNetworking in sienem Projekt benutzen, fügt man in der Podfile eine neue Zeile ein, die wie folgt aussieht

pod 'AFNetworking'

Achtung, die Namen der Pods sind Case-Sensitive, d.h. unterscheiden nach Groß- und Kleinschreibung!

führt man dann in einem Terminal den Befehl

$ pod install

aus, macht CocoaPods einige Dinge im Hintergrund und auf einmal. Zuerst wird ein Abhängigkeitsgraph erstellt, da es ein üblicher Fall ist, dass Pods ihrerseits von anderen Pods abhängen. Anhang dieses Abhängigkeitsbaums rennt CocoaPods los und läd die entsprechenden Projekte in den pod-Ordner im Projektverzeichneis, in dem alle Artefakte und Quellen gespeichert sind, die von CocoaPods verwaltet werden

Im pods-Ordner sollte man nicht von Hand Änderungen vornehmen, da das Verhalten im besten Fall undefiniert, im schlechtesten Fall katastrophal ist.

Nachdem dieser Schritt zum Ende gekommen ist, wird ein Pods-Projekt angelegt. Dieses Projekt dient einzig und alleine dazu, die Abhängigkeiten in einem Projekt zusammenzufassen und dort in eine statische Bibliothek zu kompilieren.

Für sich ist das schon praktisch, allerdings besteht der kritische Punkt im nächsten Schritt, bei dem CocoaPods einen Workspace erstellt, die unser iOS-Projekt und das Pods-Projekt enthält und diese verknüpft. Diese Verknüpfung besteht im Kern daraus, dass das Pods-Projekt als Abhängigkeit unseres Projekts angegeben wird, so dass dieses immer gebaut wird.

Dieser Workspace ist ab sofort auch der Dreh- und Angelpunkt der Entwicklung – das heisst dass das bisherige .xcodeproj nicht mehr benutzt werden kann, da sonst die Abhängigkeiten fehlen.

Auf der Kommandozeile kann mittels

open Project.xcworkspace

einfach das neu angelegte Projekt bzw. der dazugehörige Workspace geöffnet werden.

Änderungen an der Podfile

Ändert man die Podfile, was in der Praxis natürlich häufig der Fall ist, kann das bestehende Pod-System mittels

pod update

auf den neusten Stand gebracht werden. Sollte Xcode die Änderungen nicht sofort erkennen bzw. Probleme beim Bauen haben hilft oft ein Neustart von Xcode. Sollte das nicht den gewünschten Effekt haben, kann man in der (CocoaPods Troubleshooting guide)[http://guides.cocoapods.org/using/troubleshooting.html] weiter bekannte Probleme und deren Lösungen recherchieren.

Pods finden

CocoaPods kommt mit einem search-Kommando, dass behilflich ist, wenn man Pods finden möchte. Sucht man Beispielsweise ein Pod, dass aus Hex-Farbcodes wie sie in HTML/CSS zum Einsatz kommen, eine UIColor-Instanz baut, kann man einfach danach suchen:

pod search hex

Eine Liste mit verfügbaren Pods wird dann angezeigt, die auszugsweise so aussieht:

-> UIColor-ColorWithHexAndAlpha (1.2.0)
   Create UIColor Objects using Hex Values
   pod 'UIColor-ColorWithHexAndAlpha', '~> 1.2.0'
   - Homepage: https://github.com/ArtSabintsev/UIColor-ColorWithHexAndAlpha
   - Source:   https://github.com/ArtSabintsev/UIColor-ColorWithHexAndAlpha.git
   - Versions: 1.2.0 [master repo]


-> UIColor-Hex (0.1.1)
   Initializes the UIColor using hexadecimal.
   pod 'UIColor-Hex', '~> 0.1.1'
   - Homepage: http://github.com/nakajijapan
   - Source:   https://github.com/nakajijapan/UIColor-Hex.git
   - Versions: 0.1.1, 0.1.0 [master repo]


-> UIColor-HexString (1.1.0)
   Easy, Android-compatible hex strings to UIColor.
   pod 'UIColor-HexString', '~> 1.1.0'
   - Homepage: https://github.com/kevinrenskers/UIColor-HexString
   - Source:   https://github.com/kevinrenskers/UIColor-HexString.git
   - Versions: 1.1.0, 1.0.1, 1.0.0 [master repo]

daraus kann man sich nun den Namen des gewünschten Pods kopieren und in die eigene Podfile übernehmen

Cocoapods und git

Vor Cocoapods war die Verwaltung von Dependencies mittels git submodules oder anderer Techniken oftmals mühsam und hat (in meiner Erfahrung) zu mehr Problemen geführt, als man wollte. Eine bewährte Strategie für den Umgang mit Cocoapods und git ist, die folgenden Dateien und Verzeichnisse komplett in die Versionskontrolle zu übernehmen – so ist es jedem Entwickler nach einem clone sofort möglich, loszuarbeiten, auch ohne selbst Cocoapods installiert zu haben:

Podfile
Podfile.lock
Pods/
$(Projektname).xcworkspace

Ein weiterer Vorteil liegt darin, dass auch eine Continuous Integration-Umgebung dass Projekt auschecken und bauen kann, da alle Abhängigkeiten schon parat liegen.

CocoaPods Schnelleinstieg

In fast jedem Projekt ist man auf Bibliotheken angewiesen, die das leben leichter machen. CocoaPods vereinfacht die Integration von 3rd-Party Software bedeutend, und diese Guide erklärt wies geht.

Verfügbare Formate

Teilen

Sollte Ihnen der Inhalt gut gefallen haben, freue ich mich, wenn Sie einen Link bei Twitter oder Facebook teilen. Danke!

Feedback

Bei Fragen oder Problemen bitte an @moritzhaarmann wenden. Fragen per E-Mail kann ich aus Zeitgründen i.d.R. nicht beantworten.