Swift Package Manager-Download fehlgeschlagen? 2026 Xcode-Fehlerbehebung für Einsteiger

Symptom: Der Swift Package Manager-Download ist fehlgeschlagen oder Xcode bleibt bei „Resolving Package Graph“ stehen. Schnellster Weg: Prüfen Sie zuerst Repository-Zugriff und Git-Lesen, danach die Versionsregeln und Package.resolved; löschen Sie nicht sofort alle Caches. Wenn nur Ihr Schulgerät oder Netzwerk blockiert, verifizieren Sie das Projekt auf einem freigegebenen, sauberen Mac.

Zuletzt aktualisiert am 30.08.2026; die Angaben zu Xcode 26.6, Swift Packages und dem Auflösungsverhalten wurden anhand der offiziellen Xcode-26.6-Versionshinweise sowie der unten verlinkten Apple- und Swift-Dokumentation geprüft.

Dieser Beitrag ist für Sie gedacht, wenn Sie erstmals ein SwiftUI-Kursprojekt mit einem Drittanbieter-Paket ergänzen, die Fehlermeldung in Xcode 26.6 nicht einordnen können oder ein Beispielprojekt von GitHub beim Laden der Abhängigkeiten hängen bleibt. Auch Windows-Nutzer mit einem Remote-Mac sowie Lernende an Schulgeräten und in privaten Gruppenprojekten finden hier eine getrennte Prüfreihenfolge.

Zuerst den Fehlerort feststellen

Ein Paket ist für Ihr Projekt wie ein Lehrbuch, das in einer bestimmten Ausgabe benötigt wird. Swift Package Manager muss zunächst die Bibliothek finden, anschließend eine zulässige Version auswählen und schließlich die ausgewählten Produkte für den Build bereitstellen. Ein Fehler in diesen Phasen sieht ähnlich aus, verlangt aber eine andere Maßnahme.

Ordnen Sie die Meldung zunächst einer dieser Situationen zu:

• Repository nicht erreichbar: Die URL öffnet sich nicht, Git meldet einen Zugriffsfehler oder Xcode findet überhaupt keine Paketbeschreibung.
• Download bricht ab oder bleibt stehen: Das Repository ist grundsätzlich bekannt, aber die Verbindung endet nicht sauber. Netzwerkregeln, Proxy, Zertifikatsprüfung oder ein instabiler Zugriff sind dann mögliche Ursachen.
• Versionsauflösung scheitert: Das Paket wurde gefunden, aber die in Ihrem Projekt verlangte Version passt nicht zu anderen Abhängigkeiten. In diesem Fall ist der Download nicht das eigentliche Problem.
• Build oder Import schlägt fehl: Die Pakete wurden aufgelöst, aber ein Produkt fehlt, ein Modul wird falsch importiert oder der Quellcode passt nicht zur gewählten Version.

Sichern Sie vor jeder Änderung den vollständigen Fehlertext, die Repository-Adresse, den Namen des Projekts und den genauen Arbeitsschritt, der den Fehler ausgelöst hat. Ein Screenshot allein reicht oft nicht: Die entscheidende Information steht häufig in einer längeren Xcode-Meldung oder in den Paketdetails.

Die Apple-Dokumentation zu Swift Packages in Xcode beschreibt, wo Pakete hinzugefügt, Produkte ausgewählt und Abhängigkeiten im Projekt geprüft werden. Nutzen Sie diese dokumentierten Projektfunktionen, statt beliebige Bereinigungskommandos aus Foren zu übernehmen.

Erste Prüfung für ein neues Kursprojekt

Wenn Sie eine öffentliche Bibliothek zum ersten Mal hinzufügen, sollten Sie das Problem möglichst klein machen. Ein Kursprojekt enthält oft bereits eigene Einstellungen, mehrere Ziele und weitere Abhängigkeiten. Dadurch ist später schwer zu erkennen, ob die URL, das Projekt oder die Mac-Umgebung verantwortlich ist.

Schritt 1: Die Repository-Adresse außerhalb von Xcode prüfen

Kopieren Sie die Paketadresse aus dem Kursmaterial und öffnen Sie sie im Browser. Achten Sie darauf, ob Sie tatsächlich auf ein Quellcode-Repository gelangen und nicht auf eine allgemeine Webseite, einen Unterordner oder eine versehentlich mitkopierte Satzzeile.

Prüfen Sie außerdem, ob am Anfang oder Ende der Adresse ein Leerzeichen, ein Anführungszeichen oder ein anderes Zeichen steht. Eine sichtbare Webseite beweist noch nicht, dass Xcode genau dieselbe Adresse korrekt als Git-Repository verwenden kann. Die Grundlagen zu Remote-Repositories und ihrer Rolle bei Git erklärt die GitHub-Dokumentation zu Remote-Repositories.

Verifizierbare Handlung: Kopieren Sie die bereinigte Adresse in Ihre Notizen und vergleichen Sie sie Zeichen für Zeichen mit der Projektdefinition oder der Kursanleitung.

Sicherheitsgrenze: Laden Sie keine unbekannte Datei und führen Sie kein Skript aus, nur weil eine Anleitung dies als „schnelle Reparatur“ bezeichnet.

Stoppbedingung: Wenn das Repository im Browser nicht erreichbar ist, wechseln Sie nicht sofort zu Cache-Löschungen. Klären Sie zuerst, ob die Adresse veraltet, falsch geschrieben oder vorübergehend nicht verfügbar ist.

Schritt 2: Den einfachen Git-Lesezugriff vergleichen

Bei einem öffentlichen Repository sollte ein grundlegender Lesezugriff grundsätzlich ohne persönliche Schreibrechte möglich sein. Bei einem privaten Repository ist dagegen eine bestätigte Identität erforderlich. Diese beiden Fälle dürfen Sie nicht vermischen.

Ein Git-Leseversuch kann zeigen, ob das Problem bereits vor Xcode entsteht. Verwenden Sie dafür nur eine erlaubte, sichere Umgebung und lesen Sie die Fehlermeldung, ohne Zugangsdaten in Befehle, Screenshots oder Kursforen einzutragen. Die Swift-Dokumentation zur PackageDescription erläutert, wie Paketabhängigkeiten in der Paketbeschreibung definiert werden.

Wenn Browser und Git beide keinen Zugriff erhalten, liegt die Ursache wahrscheinlich bei Adresse, Netzwerk oder Berechtigung. Wenn Git lesen kann, Xcode aber nicht, untersuchen Sie anschließend Xcode-Projektkonfiguration, Anmeldezustand und Protokolle.

Schritt 3: In Xcode die Paketquelle und das Produkt kontrollieren

Öffnen Sie in Xcode die Paketabhängigkeiten des Projekts und vergleichen Sie:

• die gespeicherte Repository-URL mit Ihrer Notiz,
• die ausgewählte Versionsregel,
• das gewünschte Produkt oder Modul,
• das Ziel, in dem das Produkt verwendet werden soll,
• die genaue Fehlermeldung während der Auflösung.

Eine Versionsregel ist wie die Ansage „jede Ausgabe ab dieser Version“ oder „nur diese Ausgabe“. Eine Abhängigkeit kann deshalb erreichbar sein und trotzdem nicht aufgelöst werden, wenn zwei Pakete inkompatible Anforderungen stellen. Die [Apple-Referenz zu Package.Dependency](https://developer.apple.com/documentation/packagedescription/package/dependency?utm_source=openai) beschreibt die möglichen Abhängigkeitsanforderungen und ihre Bedeutung.

Schritt 4: Mit einem leeren Projekt gegenprüfen

Erstellen Sie ein minimales Testprojekt und fügen Sie nur das betroffene öffentliche Paket hinzu. Verwenden Sie dabei dieselbe Repository-Adresse und dieselbe Versionsregel, die im Kursprojekt vorgesehen ist.

• Funktioniert das leere Projekt, liegt die Ursache eher im ursprünglichen Projekt, in dessen Zielkonfiguration oder in einer anderen Abhängigkeit.
• Scheitert auch das leere Projekt, prüfen Sie weiter die Umgebung, das Netzwerk, den Repository-Zugriff und die Paketdefinition.
• Wird das Paket aufgelöst, aber nicht gebaut, handelt es sich wahrscheinlich nicht um einen Downloadfehler.

Dieses Vorgehen kostet etwas Zeit, verhindert aber, dass Sie ein funktionierendes Kursprojekt durch großflächige Änderungen an der Paketkonfiguration beschädigen.

Beispielprojekte und Package.resolved richtig behandeln

Beim Öffnen eines Lehrer- oder GitHub-Beispielprojekts sehen Sie möglicherweise eine Datei namens Package.resolved. Sie können sie sich wie das Ausleihprotokoll einer Bibliothek vorstellen: Die Projektbeschreibung nennt mögliche Bücher, während diese Datei festhält, welche konkreten Ausgaben zuletzt ausgewählt wurden.

Package.resolved ist daher nicht automatisch eine Fehlerdatei. Sie dokumentiert die konkret aufgelösten Paketversionen und kann für reproduzierbare Builds wichtig sein. Die [Apple-Anleitung zu Build- und Konfigurationsproblemen](https://developer.apple.com/documentation/xcode/resolving-common-configuration-and-build-issues?changes=_7&utm_source=openai) ist die bessere Grundlage für die Einordnung als ein pauschaler Rat aus einem Forum.

So vergleichen Sie die drei relevanten Ebenen

Prüfen Sie zuerst die Paketdefinition des Projekts: Welche Abhängigkeit wird verlangt und welche Versionsgrenze ist angegeben? Vergleichen Sie danach Package.resolved: Welche konkrete Version und welcher Commit sind dort eingetragen? Zum Schluss sehen Sie sich das Repository selbst an: Existiert die angeforderte Version oder der Commit noch?

Wenn diese drei Ebenen nicht zusammenpassen, kann das Paket erreichbar sein und die Auflösung dennoch scheitern. Ein Beispiel: Die Kursdatei verlangt eine Version innerhalb einer bestimmten Grenze, während Package.resolved auf einen alten Commit zeigt, der im Repository nicht mehr vorhanden ist. Das ist ein Versions- oder Zustandsproblem, kein Beweis für ein schlechtes Netzwerk.

Vor einer erneuten Auflösung sichern

Bevor Sie die Abhängigkeiten neu auflösen, kopieren Sie Package.resolved außerhalb des Projekts und notieren Sie den verwendeten Commit. Nach der Änderung vergleichen Sie, welche Paketversionen neu ausgewählt wurden. Wenn sich mehrere Pakete ändern, melden Sie dies der Kursleitung, bevor Sie Ihren Code weiter umbauen.

Verifizierbare Handlung: Öffnen Sie das Projekt in einem separaten Arbeitsstand oder erstellen Sie einen Git-Zweig, bevor Sie die Paketauflösung ändern.

Sicherheitsgrenze: Übernehmen Sie keine privaten Zugangsdaten aus dem Beispielprojekt und ersetzen Sie keine Projektdateien durch Dateien unbekannter Herkunft.

Stoppbedingung: Wenn die Neuauflösung zwar erfolgreich ist, danach aber SwiftUI-Ansichten oder Importe nicht mehr bauen, kehren Sie zum gesicherten Zustand zurück und klären die erwartete Paketversion mit der Kursleitung.

Eingeschränkte Schulgeräte und Netzwerke sauber prüfen

Ein Schulcomputer kann technisch funktionieren und trotzdem für Ihr Projekt ungeeignet sein. Häufig dürfen Sie keine Entwicklungswerkzeuge installieren, keine Zertifikate ändern oder keinen Proxy selbst konfigurieren. Ein Schulnetz kann außerdem bestimmte Repository-Domains, SSH-Verbindungen oder externe Git-Zugriffe begrenzen.

Prüfen Sie in dieser Reihenfolge:

1. Öffnen Sie die Repository-Adresse im Browser des Schulgeräts.
2. Prüfen Sie einen einfachen Lesezugriff über Git, sofern dies durch die Schulregeln erlaubt ist.
3. Öffnen Sie die Xcode-Protokolle und vergleichen Sie Zeitpunkt sowie Fehlermeldung mit den beiden vorherigen Tests.

Wenn der Browser funktioniert, Git aber scheitert, kann die verwendete Zugriffsmethode blockiert sein. Wenn alle drei Prüfungen scheitern, sprechen die Indizien eher für Netzwerk- oder Gerätebeschränkungen. Ein einzelner Fehlschlag beweist allerdings noch keine bestimmte Ursache.

Deaktivieren Sie keine Sicherheitsprüfung, installieren Sie kein fremdes Zertifikat und umgehen Sie keine Geräteverwaltung. Bitten Sie stattdessen die zuständige IT-Stelle um eine Prüfung der Repository-Adresse, der Proxy-Regeln und der Zertifikatskette. Falls Sie diese Regeln nicht ändern dürfen, ist wiederholtes Neuinstallieren von Xcode keine sinnvolle Lösung.

Wenn Sie für den Kurs einen getrennten macOS-Arbeitsplatz benötigen, können Sie zunächst die verfügbaren Mac-Umgebungen von MACGPU prüfen. Entscheidend ist nicht nur, ob Xcode startet, sondern ob Sie dort Ihr konkretes Projekt unter erlaubten Netzwerk- und Kontobedingungen testen können.

Private Pakete und Gruppenprojekte getrennt behandeln

Ein privates Paket verlangt eine andere Prüfung als eine öffentliche Lernbibliothek. Stellen Sie zuerst fest, ob Ihr eigenes Konto tatsächlich Leserechte für das Repository besitzt. Mitgliedschaft in einer Gruppe bedeutet nicht automatisch, dass jedes Unterprojekt freigegeben ist.

HTTPS-Zugangsdaten, SSH-Schlüssel und Package.resolved lösen unterschiedliche Probleme:

• HTTPS-Anmeldung bestätigt Ihre Identität gegenüber dem Repository.
• SSH-Schlüssel ermöglichen einen anderen sicheren Zugriffsweg, wenn dieser für Ihr Konto und Repository freigegeben ist.
• Package.resolved dokumentiert ausgewählte Versionen; die Datei gewährt keine Berechtigung.

Verwenden Sie niemals den Account oder den privaten Schlüssel eines Mitschülers. Teilen Sie auch keine Schlüsseldateien in einem Chat oder im Kursrepository. Lassen Sie die verantwortliche Person die Leserechte mit einem eigenen, möglichst eingeschränkten Testkonto prüfen.

Verifizierbare Handlung: Testen Sie zuerst ein kleines, freigegebenes privates Repository und erst danach das vollständige Gruppenprojekt.

Sicherheitsgrenze: Erzeugen oder ändern Sie Zugangsdaten nur nach den Regeln Ihrer Gruppe und speichern Sie keine privaten Schlüssel im Projektordner.

Stoppbedingung: Wenn das Testkonto keinen Zugriff erhält, muss die Repository-Verwaltung die Berechtigung klären. Eine Änderung der Versionsregel kann fehlende Rechte nicht ersetzen.

Die offiziellen Hinweise zur Abhängigkeitsverwaltung in Apple-Workflows für Swift Packages und CI/CD zeigen außerdem, warum ein reproduzierbarer Projektzustand auch außerhalb Ihres lokalen Rechners wichtig ist.

Ihre Entscheidung als kurze Prüfliste

Bearbeiten Sie die Punkte in der Reihenfolge. Ein nicht erfüllter Punkt ist ein Signal, dort weiterzuprüfen, nicht sofort zum letzten Punkt zu springen.

• [ ] Vollständige Fehlermeldung, Repository-Adresse und auslösender Arbeitsschritt sind gesichert.
• [ ] Die Repository-Adresse wurde im Browser geprüft und von überflüssigen Zeichen bereinigt.
• [ ] Ein erlaubter Git-Lesezugriff wurde getrennt vom Xcode-Projekt geprüft.
• [ ] In Xcode sind Quelle, Versionsregel, Produkt und Ziel kontrolliert.
• [ ] Ein leeres Testprojekt wurde mit derselben öffentlichen Paketquelle ausprobiert.
• [ ] Package.resolved wurde vor jeder erneuten Auflösung gesichert.
• [ ] Projektdefinition, aufgelöste Version und vorhandener Repository-Stand wurden verglichen.
• [ ] Bei einem privaten Paket wurden die eigenen Leserechte bestätigt.
• [ ] Schulnetzwerk, Proxy, Zertifikate und Geräteverwaltung wurden nicht eigenmächtig umgangen.
• [ ] Derselbe Commit und dieselben Paketversionen wurden auf der Testumgebung erneut geprüft.

Erfüllen Sie die ersten fünf Punkte, bevor Sie die Umgebung wechseln. Wenn das Paket in einem leeren Projekt ebenfalls scheitert, ist ein anderer Mac nur dann sinnvoll, wenn Sie damit Netzwerk, Berechtigungen oder eine verunreinigte lokale Umgebung isolieren können.

Häufige Fragen aus der Xcode-Anfangsphase

Xcode bleibt bei „Resolving Package Graph“ stehen

Prüfen Sie zuerst Browser und Git, nicht den Cache. Wenn beide Zugriffe funktionieren, kontrollieren Sie in Xcode die Paketquelle, die Versionsregel und die Protokolle. Bleibt nur das bestehende Projekt hängen, testen Sie die Quelle in einem leeren Projekt. Erst nach einer Sicherung von Package.resolved ist eine erneute Auflösung vertretbar.

Warum ein GitHub-Paket beim Download hängen kann

Ein sichtbares Repository bedeutet nicht, dass Xcode denselben Zugriff erfolgreich durchführen kann. Proxy-Regeln, Zertifikate, DNS-Auflösung oder eine abweichende Git-Anmeldung können den Vorgang stoppen. Vergleichen Sie deshalb Browser, erlaubten Git-Lesezugriff und Xcode-Protokoll. Bei einem privaten Repository kommt zusätzlich die tatsächliche Leseberechtigung hinzu.

Was bei einem Konflikt in Package.resolved zu tun ist

Löschen Sie die Datei nicht reflexartig. Sichern Sie sie und vergleichen Sie die festgehaltenen Versionen mit den Anforderungen der Paketdefinition und dem Repository. Falls die Kursleitung eine bestimmte Version erwartet, dokumentieren Sie jede Änderung. Eine erfolgreiche Neuauflösung ist nicht automatisch eine erfolgreiche Reparatur, wenn sich dadurch die Schnittstellen des Projekts ändern.

Vorgehen bei fehlenden Swift-Paketen im Schulnetz

Arbeiten Sie ausschließlich innerhalb der Freigaben Ihrer Schule. Prüfen Sie Repository, Git und Xcode-Protokoll und bitten Sie die zuständige Stelle um eine Netzwerk- oder Geräteprüfung. Vermeiden Sie fremde Zertifikate, Skripte und Umgehungsversuche. Wenn die Einschränkung nicht rechtmäßig geändert werden kann, verwenden Sie für den Kurs eine freigegebene Mac-Umgebung.

Wann ein Remote-Mac sinnvoll ist

Ein Remote-Mac ist ein guter Vergleich, wenn das Repository öffentlich oder Ihr Konto bestätigt ist, Ihr Schulgerät aber Pakete nicht zuverlässig laden kann. Verwenden Sie dasselbe Projekt, denselben Commit und dieselben Zugangsdaten. Scheitert die Auflösung dort ebenfalls, liegt die Ursache wahrscheinlich in der Paketdefinition oder Berechtigung. Für einen kontrollierten Test können Sie die MACGPU-Mac-Mietoptionen ansehen.

Die letzte Abnahme: lokal gegen Remote vergleichen

Beenden Sie die Fehlersuche nicht nach dem ersten erfolgreichen Download. Ein Kursprojekt sollte mindestens in drei Zuständen geprüft werden: bei der ersten Paketauflösung, nach dem Schließen und erneuten Öffnen des Projekts sowie beim tatsächlichen Build. Verwenden Sie dabei denselben Commit und denselben Stand von Package.resolved.

Bewerten Sie die Ergebnisse so:

• Nur das ursprüngliche Gerät scheitert: Netzwerk, lokaler Cache, Zertifikate, Benutzerrechte oder eine beschädigte Umgebung bleiben wahrscheinliche Kandidaten.
• Lokales und Remote-System scheitern gleich: Prüfen Sie Repository, Konto, Versionsregeln und Paketdefinition erneut.
• Paketauflösung gelingt, Build scheitert: Untersuchen Sie Produktzuordnung, Import, Zielkonfiguration und die Kompatibilität des Quellcodes.
• Neue Auflösung verändert viele Versionen: Stoppen Sie die Weiterarbeit und klären Sie mit der Kursleitung, welcher Projektstand verbindlich ist.

Für Lernende, die SwiftUI gerade erst beginnen, ist diese Abnahme wichtiger als ein möglichst schneller Erfolg. Sie soll zeigen, ob das Projekt tatsächlich reproduzierbar ist oder nur einmal zufällig auf dem Rechner eines anderen Kursteilnehmers funktioniert.

Wann ein anderer Mac die vernünftigere Lernumgebung ist

Wenn Repository und Paketdefinition nachweislich funktionieren, aber Ihr Schulcomputer wegen Installationsrechten, Netzwerkregeln oder einer schwer änderbaren Umgebung wiederholt scheitert, bringt weiteres Zurücksetzen von Xcode meist keinen Erkenntnisgewinn. Ein sauberer, freigegebener Mac kann dann als Vergleichsumgebung dienen. Das gilt auch, wenn Sie von Windows aus lernen und den macOS-Teil Ihres Swift- oder SwiftUI-Kurses nur für bestimmte Projektprüfungen benötigen.

Ein Remote-Mac ist jedoch keine Reparatur für ein privates Repository ohne Leserecht, einen gelöschten Commit oder widersprüchliche Versionsanforderungen. Sie brauchen weiterhin gültige Kontoberechtigungen, eine nachvollziehbare Projektdatei und ein erlaubtes Netzwerk. Für langfristige, tägliche Schwerlastentwicklung kann ein eigener Rechner wirtschaftlich sinnvoller sein; für einen kurzen Kursabschnitt oder eine unabhängige Verifikation ist Mieten oft flexibler, weil Sie nicht sofort Hardware kaufen und administrieren müssen.

Im Vergleich zur aktuellen Schul- oder Windows-Umgebung bleiben häufig drei konkrete Nachteile: fehlende Installationsrechte, blockierte Repository-Verbindungen und eine Umgebung, die Sie nicht selbst bereinigen dürfen. Wenn Ihr Projekt auf dem vorhandenen Gerät deshalb trotz korrekter Quelle immer wieder an derselben Stelle stoppt, ist eine kontrollierte MACGPU-Umgebung als Gegenprobe die sachlichere nächste Maßnahme. Sie behalten dabei die Projektaufzeichnungen und können vor einer längeren Entscheidung zunächst nur den entscheidenden Kursablauf prüfen.