Cocoapods gilt als der beliebteste Abhängigkeitsmanager für iOS. In den letzten Jahren hat Apple an der Entwicklung seines nativen SPM-Abhängigkeitsmanagers (Swift Package Manager) gearbeitet.Anfangs war seine Verwendung nur für serverseitige Swift- oder Terminalanwendungen möglich. SPM wurde für solche Anwendungen ausgeführt und geändert, die Community wurde mit ihrer Arbeit vertraut gemacht und das Apple-Team erhielt Betatester.Mit der Veröffentlichung von Xcode 11 begann SPM in die Welt der Entwicklung für iOS einzusteigen. Jetzt ist es bereits ein vollwertiges Tool, das verwendet werden kann, jedoch bisher mit Einschränkungen.In der aktuellen Version unterstützt SPM keine Ressourcen (wir warten auf SE-0271 ). In unserem Land ist jedes Modul eine atomare autarke Abhängigkeit, die mit dem Projekt verbunden werden kann, sodass Ressourcen benötigt werden (Lokalisierung, Assets).In der Zwischenzeit können wir uns auf die Migration vorbereiten: um zu verstehen, wie schwierig es ist, ob es automatisiert werden kann und auf welche Probleme Sie möglicherweise stoßen.Warum von Cocoapods auf SPM migrieren?
- Ursprünglichkeit und Integration in das Ökosystem. Xcode schlägt bereits vor, ein SPM-Paket zu erstellen oder hinzuzufügen.
- Im Gegensatz zu Cocoapods ist kein Arbeitsbereich mehr erforderlich, um an einem Abhängigkeitsprojekt arbeiten zu können.
- Nach dem Hinzufügen einer neuen Abhängigkeit müssen Sie nicht das gesamte Projekt installieren und neu erstellen.
- Es ist praktisch, lokale Abhängigkeiten zu verwenden: Die Ordnerstruktur ändert sich nicht, sie wird schneller neu erstellt.
- SPM , Cocoapods, Ruby ( iOS-).
- Cocoapods Xcode Swift.
- Example : Xcode Package.swift .
- abstract_target: SPM .
- blame , .
- Ruby, .
?
Wenn Ihr Projekt viele Abhängigkeiten aufweist, kann der Migrationsprozess nicht an einem Tag abgeschlossen werden. Die Anzahl der Abhängigkeiten in der Poddatei entspricht nicht der Gesamtzahl der Abhängigkeiten, da eine Abhängigkeit mit zehn weiteren gebündelt werden kann. Selbst wenn Sie nicht viele Abhängigkeiten haben, aber Ihre Abhängigkeiten entwickeln, ist es auch in privaten Repositorys möglich, nicht schnell zu migrieren. Glücklicherweise versteht sich SPM gut mit Cocoapods, und der Migrationsprozess kann wiederholt werden. Die Hauptsache ist, die Nuancen zu berücksichtigen:- Es sollte keine Schnittpunkte zwischen den SPM- und Cocoapods-Abhängigkeiten geben.
- Die Migration sollte in den Komponentenentwicklungsprozess integriert werden. Wenn sich die Komponente entwickelt, sollte sowohl für Cocoapods als auch für SPM ein Versions-Upgrade durchgeführt werden.
- Es sollte keine Schwierigkeiten für das Team geben, was bedeutet, dass Sie die Installation aller Abhängigkeiten über einen einzigen CLI-Befehl implementieren müssen.
- Die Migration muss in die CI-CD integriert sein. Das Projekt muss in allen Konfigurationen sowohl lokal als auch auf CI-Agenten erstellt werden.
Wo soll ich anfangen?
Zunächst sammeln wir eine vollständige Liste Ihrer Abhängigkeiten - diese wird in Podfile.lock dargestellt. Sie können Dienstprogramme wie SPMReady verwenden .
Als nächstes gruppieren wir sie nach Beziehung. Beispielsweise hängen fast alle Komponenten von SMENetwork ab. Dies bedeutet, dass wir sie erst nach der Migration von SMENetwork selbst auf SPM migrieren können.Dann wählen wir ein Modul aus, von dem die meisten Module abhängen - SMENetwork.Gehen Sie schließlich zum Repository dieses Moduls, checken Sie es in einen Ordner ein und erstellen Sie ein Modul im Stammverzeichnis dieses Ordners.git clone ssh://.../smenetwork.git Developer/SMENetwork
cd Developer/SMENetwork
swift package init
Creating library package: SMENetwork
Creating Package.swift
Creating Sources/
Creating Sources/SMENetwork/SMENetwork.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/SMENetworkTests/
Creating Tests/SMENetworkTests/SMENetworkTests.swift
Creating Tests/SMENetworkTests/XCTestManifests.swift
Als Ergebnis erhalten wir die Hauptdatei Package.swift und die Ordner Sources and Tests. Wenn Sie sie bereits hatten, werden sie nicht mahlen. Die Dateien SMENetwork.swift, SMENetworkTests.swift, XCTestManifests.swift, LinuxMain.swift wurden für das Beispiel des Paketvorgangs erstellt. Sie können gelöscht werden.Die Datei Package.swift sieht folgendermaßen aus:
Schauen wir uns nun die Datei SMENetwork.podspec an:
Wie Sie sehen können, befinden sich Quellen und Tests in anderen Ordnern. Übertragen Sie die Dateien und testen Sie das Cocoapods-Beispielprojekt.
Wir fügen die Entwicklungsplattform zu Package.swift hinzu und übertragen hier die Abhängigkeiten aus der podspec-Datei. Wir stellen sicher, dass sie SPM unterstützen: Überprüfen Sie einfach, ob in Github eine Package.swift-Datei vorhanden ist. Wenn er nicht da ist und nicht einmal eine PR bei ihm ist, werden wir PR machen und der Open-Source-Community helfen.
Für SPM müssen Sie kein Beispielprojekt erstellen: Öffnen Sie einfach Package.swift in Xcode und es werden die Abhängigkeiten heruntergeladen und verbunden. Erstellen Sie die Ziele gemäß unserer Spezifikation. Wir können nur rennen.
In unserem Fall hat fast alles sofort funktioniert, mit Ausnahme eines Ortes, an dem import Foundation vergessen hat: iOS-Entwickler sind daran gewöhnt, dass UIKit und Foundation optional sind, da es ohne sie funktioniert. Es ist Zeit, diese Gewohnheit zu verlernen.
Paket kompiliert, Tests kompilieren, aber fehlschlagen.
Und hier stoßen wir auf eine Einschränkung des Ressourcenmangels im Paket, die Tests basieren auf den Moks, die in JSON liegen, wir warten auf SE-0271 ...Gesamt
Der Wechsel von Cocoapods zu SPM ist einfach. Die Schritte sind klar, aber der Fluss ist eintönig und erfordert Automatisierung.Ohne großen Aufwand können Sie ein Paket aus der .podspec-Datei erstellen und in das Repository übertragen. Und am wichtigsten ist, dass Sie mit einem Projekt umziehen können und das andere auf Cocoapods verbleibt. Wenn er will, natürlich.