Einführung in das Dependency Management in iOS

Moderne iOS-Entwicklung beginnt selten von vorne. Bibliotheken von Drittanbietern behandeln alles von Netzwerken und JSON-Parsing bis hin zu UI-Komponenten und Image-Caching. Ohne strukturierten Ansatz wird das manuelle Herunterladen von Frameworks, das Lösen von Versionskonflikten und das Verknüpfen von Binärdateien schnell zu einem Wartungsalbtraum. Hier kommen Abhängigkeitsmanager ins Spiel.

CocoaPods und Carthage sind die beiden etabliertesten Tools zum Verwalten von Abhängigkeiten in iOS-Projekten. Während CocoaPods eine schlanke, arbeitsplatzbasierte Integration bietet, folgt Carthage einer dezentralen Build-it-yourself-Philosophie. Das Verständnis der Stärken und Kompromisse von jedem hilft Ihnen, den richtigen Ansatz für Ihr Team, Ihre App und Ihre Bereitstellungspipeline zu wählen.

CocoaPods: zentralisiert und automatisiert

CocoaPods ist seit seiner Einführung der dominierende Abhängigkeitsmanager. Er verwendet einen zentralen Index namens CocoaPods Specs und generiert einen Xcode-Arbeitsbereich, der alle Abhängigkeiten automatisch verarbeitet. Das bedeutet, dass Sie eine Bibliothek hinzufügen können, indem Sie sie einfach in einer Poddatei deklarieren, einen Befehl ausführen und sofort mit dem Importieren beginnen Code.

Installation und Einrichtung

CocoaPods wird über RubyGems installiert. macOS wird mit Ruby ausgeliefert, aber Sie müssen möglicherweise ein Upgrade durchführen oder einen Ruby-Versionsmanager verwenden.

sudo gem install cocoapods

Navigieren Sie nach der Installation zu Ihrem Projektverzeichnis und initialisieren Sie eine Podfile:

pod init

Dadurch wird eine Klartextdatei mit dem Namen Podfile erstellt. Anschließend bearbeiten Sie sie, um Ihre Zielplattform, ein beliebiges -Flag (für Swift-Bibliotheken erforderlich) und die benötigten Abhängigkeiten anzugeben. Eine typische Podfile sieht so aus:

platform :ios, '15.0'

target 'MyApp' do
 use_frameworks!

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

Sobald die Podfile fertig ist, führen Sie aus:

pod install

CocoaPods lädt die angegebenen Versionen herunter, löst Abhängigkeiten auf und generiert eine -Datei. Von diesem Zeitpunkt an müssen Sie den Arbeitsbereich öffnen – nicht das Original – um Ihre App zu erstellen und auszuführen.

Erweiterte CocoaPods Features

  • Unterspezifikationen: Viele Bibliotheken erlauben es, nur eine Teilmenge ihrer Funktionalität zu importieren.
  • Lokale Pfade: Sie können auf einen lokalen Ordner für private Bibliotheken zeigen:
  • Git-basierte Quellen: Abhängigkeiten können aus jedem Git-Repository kommen:
  • Podfile.lock: Diese Datei sperrt jede Abhängigkeit von einer bestimmten Version und stellt reproduzierbare Builds in Ihrem Team und CI sicher.
  • Plugins: Sie können CocoaPods mit Plugins für SwiftLint, Firebase oder benutzerdefinierte Build-Skripte erweitern.

CocoaPods unterstützt auch Multiplattform-Ziele. Sie können verschiedene Abhängigkeitssätze für iOS, macOS und watchOS haben, indem Sie -Blöcke in einer einzelnen Podfile verschachteln.

Post-Install Hooks und Customization

Ein häufiges Bedürfnis ist es, ein Skript nach jedem auszuführen. Zum Beispiel möchten Sie Simulatorarchitekturen von Release Builds entfernen.

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

Solche Hooks geben Ihnen eine feine Kontrolle über das generierte Pods-Projekt, aber sie erhöhen auch die Komplexität. Übernutzung kann Ihre Podfile schwer zu lesen und zu pflegen machen.

Karthago: Dezentralisiert und Hands-Off

Carthage verfolgt einen anderen Ansatz. Anstatt Metadaten zu zentralisieren, stützt es sich auf Git-Tags und die eigentlichen Xcode-Projekte jeder Bibliothek. Carthage baut die Frameworks auf Ihrem Computer und überlässt Ihnen den Integrationsschritt - das Verschleppen von Frameworks in Ihr Xcode-Projekt - völlig. Diese minimale Interferenz ist für Entwickler attraktiv, die volle Kontrolle und einen kleineren Footprint in ihrer Versionskontrolle wünschen.

Installation und Einrichtung

Carthage wird normalerweise über Homebrew installiert:

brew install carthage

Als nächstes erstellen Sie eine Klartextdatei mit dem Namen Cartfile in Ihrem Projektstamm. Die Syntax ähnelt CocoaPods, zeigt aber auf GitHub-Repositories oder eine beliebige Git-Quelle:

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

Nach dem Bearbeiten der Cartfile, ausführen:

carthage update --platform iOS

Dieser Befehl klont die Repositories, prüft die markierten Versionen und erstellt die Frameworks mit Xcode. Die resultierenden Binärdateien werden im Ordner Carthage/Build/iOS platziert. Sie ziehen sie dann manuell in Ihr Xcode-Projekt unter dem Abschnitt "Frameworks, Libraries, and Embedded Content" und stellen sicher, dass sie dem entsprechenden Ziel hinzugefügt werden.

Hauptunterschiede zu CocoaPods

  • Kein Arbeitsbereich: Carthage ändert Ihre Projektdatei nicht.
  • Geschwindigkeit bauen: Carthage kann Builds zwischenspeichern. Auf CI können Sie Abhängigkeiten vorbauen, um die Pipeline zu beschleunigen.
  • Versionierung: Carthage verwendet eine Cartfile.resolved, um Versionen zu sperren, ähnlich wie Podfile.lock.
  • Binäre Frameworks: Einige Bibliotheken versenden Binärdateien. Carthage kann diese direkt herunterladen, den Build-Schritt überspringen und Zeit sparen.
  • XCFramework-Unterstützung: Seit Carthage 0.38 kann es XCFrameworks ausgeben, die nahtlos mit Swift Package Manager arbeiten und die Notwendigkeit, Simulatorarchitekturen zu entfernen, überflüssig machen.

Umgang mit Frameworks mit Abhängigkeiten

Eine Herausforderung bei Carthage ist, dass es Abhängigkeiten nacheinander aufbaut. Wenn Bibliothek A von Bibliothek B abhängt, müssen Sie beide in der Cartfile auflisten. Carthage löst den Abhängigkeitsbaum automatisch auf, aber Sie müssen trotzdem alle transitiven Abhängigkeiten in Ihrem Projekt manuell verknüpfen. Das gibt Ihnen Sichtbarkeit in jede Binärdatei, mit der Ihre App verknüpft ist, aber es erhöht auch die Wahrscheinlichkeit, dass ein erforderliches Framework zur Laufzeit fehlt.

Vergleich von CocoaPods und Karthago: Ein praktischer Leitfaden

Die Wahl zwischen beiden hängt von der Projektgröße, der Teamreife und dem Bereitstellungsworkflow ab. Die folgende Tabelle fasst die wichtigsten Kompromisse zusammen.

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.

Wann man CocoaPods verwendet

  • Sie starten ein neues Projekt und wollen minimal Boilerplate.
  • Ihr Team besteht aus Junior-Entwicklern, die von einer Hands-off-Integration profitieren.
  • Sie benötigen eine Bibliothek, die nur über CocoaPods verfügbar ist (immer noch für einige Legacy- oder proprietäre Pods).
  • Sie verlassen sich stark auf CocoaPods-Plugins (z. B. für Flusenprüfungen oder Codegenerierung).

Wann man Carthage benutzt

  • Sie legen Wert auf Modularität und möchten die Aufblähung "Pods-Projekt" vermeiden.
  • Ihre App ist groß und Sie müssen die Build-Zeiten optimieren, indem Sie vorgefertigte Frameworks zwischenspeichern.
  • Sie migrieren zum Swift Package Manager und möchten einen schrittweisen Übergang, ohne bestehende Integrationen zu unterbrechen.
  • Sie arbeiten in einem Team, das es vorzieht, das Xcode-Projekt schlank zu halten und die Build-Einstellungen manuell zu verwalten.

Migration zwischen Dependency Managern

Der Wechsel von CocoaPods nach Carthage oder umgekehrt ist möglich, erfordert aber eine sorgfältige Planung.

Migration von CocoaPods nach Karthago

  1. Entfernen Sie Podfile, Podfile.lock und den Arbeitsbereich.
  2. Entfernen Sie alle Pods-bezogenen Build-Phasen (z. B. "Embed Pods Frameworks").
  3. Erstellen Sie eine Cartfile und listen Sie die gleichen Bibliotheken auf (sicherstellen, dass sie Carthage unterstützen).
  4. [19] [19]
  5. Fügen Sie manuell jedes Framework aus Carthage/Build/iOS zum Xcode-Projekt hinzu.
  6. Aktualisieren Sie alle Import-Anweisungen – unter Carthage importieren Sie Frameworks direkt (z. B. ).
  7. Testen Sie gründlich; Transitive Abhängigkeiten müssen jetzt möglicherweise explizit verknüpft werden.

Migration von Karthago zu CocoaPods

  1. Entfernen Sie Carthage-bezogene Build-Phasen und Framework-Referenzen aus dem Xcode-Projekt.
  2. Löschen Sie Cartfile und Cartfile.resolved.
  3. Führen Sie aus, um eine Podfile zu erstellen.
  4. Fügen Sie alle Abhängigkeiten mit entsprechenden Versionsbeschränkungen hinzu.
  5. Führen Sie aus und öffnen Sie dann den neuen Arbeitsbereich.
  6. Überprüfen Sie auf doppelte Importe - CocoaPods können Bibliotheken unterschiedlich einbetten.
  7. Aktualisieren Sie die Build-Einstellungen, falls erforderlich (z. B. ).

Best Practices für beide Manager

Unabhängig davon, welches Tool Sie wählen, halten Sie Ihr Projekt gesund, wenn Sie diese Praktiken befolgen.

  • Vermittle Sperrdateien: Immer begehen Podfile.lock oder Cartfile.resolved Versionskontrolle. Dies stellt sicher, dass jedes Teammitglied und CI-Server genau die gleichen Versionen verwendet.
  • Pin-Versionen sorgfältig: Verwenden Sie optimistische Operatoren (), um kleinere Updates zu ermöglichen und gleichzeitig größere Änderungen zu blockieren.
  • Updates absichtlich ausführen: Führen Sie oder nicht aus, ohne die Changelogs der aktualisierten Abhängigkeiten zu überprüfen.
  • Audit for Swift version compatibility: Einige Bibliotheken unterstützen möglicherweise nicht die Swift-Version, die Ihr Projekt verwendet.
  • Entferne unbenutzte Abhängigkeiten: Überprüfen Sie regelmäßig Ihre Cartfile oder Podfile und entfernen Sie Bibliotheken, die nicht mehr verwendet werden.
  • Betrachten Sie SPM für neue Projekte: Swift Package Manager ist jetzt in Xcode integriert und wird von den meisten großen Bibliotheken unterstützt. Wenn Sie bei Null anfangen, ist SPM möglicherweise die einfachste Wahl. Sowohl CocoaPods als auch Carthage sind nach wie vor hervorragend für die Verwaltung großer Legacy-Projekte oder privater Frameworks geeignet.

Problembehandlung bei gemeinsamen Problemen

CocoaPods: „Spec not found

Dies bedeutet normalerweise, dass die Bibliothek nicht in den CocoaPods-Trunk verschoben wurde oder Sie einen falschen Namen verwenden. Überprüfen Sie den Pod-Namen auf cocoapods.org Wenn die Bibliothek privat ist, müssen Sie die Quelle in Ihrer Poddatei angeben.

CocoaPods: Konflikte intransitive Abhängigkeiten

Führen Sie aus und prüfen Sie die Ausgabe. Möglicherweise müssen Sie explizite Versionsbeschränkungen für transitive Pods hinzufügen. Mit und einem neuen kann das Abhängigkeitsdiagramm zurückgesetzt werden.

Karthago: „Kein solches Modul beim Bauen

Oftmals geschieht dies, weil das Framework nicht für die richtige Plattform erstellt wurde (z. B. Sie haben versehentlich mit erstellt). Führen Sie erneut aus und überprüfen Sie den Ausgabeordner.

Karthago: Build scheitert an fehlenden Abhängigkeiten

Wenn eine Bibliothek, die Sie verwenden, eigene Abhängigkeiten hat (wie RxSwift-Abhängigkeiten), müssen Sie diese in Ihrer Cartfile auflisten. Carthage lädt transitive Abhängigkeiten nicht automatisch herunter, es sei denn, sie erscheinen in der Cartfile oder werden als Submodule angegeben.

Hybridansätze: Sowohl CocoaPods als auch Karthago verwenden

Wenn Sie sie kombinieren müssen, halten Sie den CocoaPods-Arbeitsbereich getrennt und verknüpfen Sie Carthage-Frameworks manuell. Achten Sie auf mögliche Konflikte in doppelten Symbolen oder überlappenden Ressourcen. Die einfachere Lösung ist normalerweise, einen Manager auszuwählen und alle Bibliotheken zu migrieren, die nicht unterstützt werden.

Die Zukunft des iOS Dependency Management

Der Swift Package Manager (SPM) gilt heute als Standard von Apple und ist direkt in Xcode 11 und höher integriert. Die meisten Open-Source-Bibliotheken haben SPM-Unterstützung hinzugefügt, und SPM macht externe Tools überflüssig.

  • CocoaPods bietet eine reichhaltige Anpassung durch Hooks und Plugins, und sein Spec-Repository bleibt die größte Sammlung von iOS-Bibliotheken.
  • Carthage gibt Ihnen die volle Kontrolle über den Build-Prozess und ist einfacher zu cachen, was ihn in CI-lastigen Workflows beliebt macht.

Viele Teams verwenden SPM für neue Abhängigkeiten, während sie Legacy-Integrationen mit CocoaPods oder Carthage beibehalten. Im Laufe der Zeit wird erwartet, dass SPM zum Standard wird, aber im Moment ermöglicht das Verständnis aller drei Tools die Arbeit an jeder iOS-Codebasis.

Schlussfolgerung

Effektives Abhängigkeitsmanagement ist ein Eckpfeiler der professionellen iOS-Entwicklung. CocoaPods bietet eine schlüsselfertige Lösung, die den gesamten Integrationsprozess automatisiert und ideal für Teams ist, die Geschwindigkeit und Einfachheit wünschen. Carthage bietet einen schlankeren, transparenteren Ansatz, der Entwicklern eine granulare Kontrolle über Build-Systeme und Projektstruktur gibt. Durch die Beherrschung beider Tools können Sie die richtige Passform für die Größe, Komplexität und den Workflow Ihres Projekts auswählen. Was auch immer Sie wählen, immer Sperrdateien festlegen, Abhängigkeiten absichtlich aktualisieren und ein Auge auf die sich entwickelnde Landschaft des Swift Package Managers haben.

Für weitere Informationen, erkunden Sie die offiziellen CocoaPods Guides und das Carthage GitHub Repository.