Claude Code hat die Swift-Aufgabe beschädigt? Wiederherstellungsleitfaden für Einsteiger 2026

Symptom → Schnellster sicherer Schritt: Wenn Claude Code eine Swift-Aufgabe verändert hat, stoppen Sie weitere Änderungen, kopieren Sie das Projekt und prüfen Sie zuerst den Unterschied zur vorherigen Version. Stellen Sie erst danach einzelne Dateien aus Git oder einer Sicherung wieder her und bauen Sie das Projekt in Xcode erneut.

Das gilt besonders, wenn unklar ist, welche Dateien betroffen sind oder ob der Fehler im Code, in den Projekteinstellungen oder in der Entwicklungsumgebung liegt.

Dieser Leitfaden ist für Studierende gedacht, die gerade Swift lernen und Claude Code zum Erklären oder Ändern von Übungscode verwenden.
Er eignet sich, wenn eine Aufgabe plötzlich anders aussieht, nicht mehr baut oder sich nicht mehr wie erwartet verhält.

Erst den Fehler eingrenzen, dann handeln

„Beschädigt“ kann mehrere Dinge bedeuten. Eine Datei kann verändert worden sein, ohne dass der Build scheitert. Umgekehrt kann ein unveränderter Swift-Quelltext wegen einer Projekteinstellung oder einer fehlenden Ressource nicht mehr gebaut werden. Auch ein anderes Laufergebnis ist nicht automatisch ein Beleg für beschädigten Code.

Halten Sie vor der Wiederherstellung fest, was genau auffällt:

Dateiinhalt geändert: Eine Funktion, eine Ansicht oder ein Kommentar sieht anders aus als im Kursmaterial.
Projekt baut nicht: Xcode meldet einen Fehler beim Kompilieren oder beim Verknüpfen.
Programm läuft anders: Die App startet, zeigt aber eine andere Ansicht oder liefert ein unerwartetes Ergebnis.
Änderung ist unverständlich: Das Projekt funktioniert möglicherweise noch, aber die neue Lösung lässt sich nicht nachvollziehen.

Notieren Sie die Fehlermeldung vollständig oder sichern Sie einen Screenshot. Kopieren Sie anschließend den ganzen Projektordner an einen zweiten Ort. Belassen Sie die ursprüngliche Fassung unverändert. Eine Sicherung ist wichtig, weil auch eine gut gemeinte Wiederherstellung den letzten brauchbaren Stand überschreiben kann.

Claude Code stellt Funktionen für die Arbeit in der Kommandozeile und für Berechtigungen bereit. Das bedeutet nicht, dass jede vorgeschlagene Änderung zum Kursauftrag passt. Prüfen Sie vor der nächsten Aktion die offizielle Einführung zu Claude Code und die Dokumentation zur Kommandozeilennutzung, statt eine Erklärung des Werkzeugs als Beleg für die Richtigkeit Ihrer Lösung zu behandeln.

Wichtig: Löschen Sie keine Datei allein deshalb, weil ihr Name unbekannt ist. In einem Swift-Kursprojekt können auch Einstellungen, Ressourcen oder generierte Projektdateien für den Build wichtig sein.

Geänderte Dateien sichtbar machen

Wie lässt sich erkennen, welche Teile des Swift-Projekts Claude Code geändert hat? Öffnen Sie, falls vorhanden, das Projektverzeichnis in einem Terminal und lassen Sie sich zunächst den Status anzeigen. Bei einem Git-Projekt zeigt git status den Zustand der Arbeitskopie. Die Git-Dokumentation zu git status erklärt die angezeigten Zustände.

git status --short

Die Ausgabe kann zum Beispiel so aussehen:

 M Sources/ContentView.swift
?? Sources/Helper.swift
 D Assets/OldIcon.png

Hier ist ContentView.swift als geändert markiert, Helper.swift als neue, noch nicht verfolgte Datei und OldIcon.png als gelöscht. Diese Zeilen sagen zunächst nur, welche Pfade auffällig sind. Sie erklären nicht, ob eine Änderung für die Aufgabe falsch oder eine Datei entbehrlich ist.

Fragen Sie anschließend Git nach den Änderungen:

git diff -- Sources/ContentView.swift

git diff zeigt die Unterschiede zwischen dem Arbeitsstand und dem passenden Vergleichsstand. Hinzugefügte und entfernte Zeilen werden dabei gegenübergestellt. Die Git-Referenz zu git diff beschreibt, wie Änderungen verglichen werden. Für eine schnelle Übersicht über betroffene Pfade ist auch diese Form hilfreich:

git diff --name-status

Lesen Sie den Unterschied in kleinen Abschnitten. Prüfen Sie, ob eine erwartete Funktion geändert wurde, ob neue Dateien hinzugekommen sind und ob Ressourcen oder Projekteinstellungen betroffen sind. Ein Blick auf den Dateinamen genügt nicht: Eine scheinbar nebensächliche Datei kann für das Projekt gebraucht werden.

Wenn Änderungen bereits zum Git-Index hinzugefügt wurden, zeigt ein normaler Aufruf von git diff sie nicht unbedingt an. Vergleichen Sie dann zusätzlich den vorgemerkten Stand:

git diff --cached

Die Unterscheidung ist wichtig: Nicht vorgemerkte Änderungen und bereits vorgemerkte Änderungen stehen an verschiedenen Stellen im Git-Arbeitsablauf. Wer nur eine der beiden Ansichten prüft, kann einen Teil der Änderungen übersehen.

Wiederherstellung ohne Git-Verlauf

Wie lassen sich geänderte Kursdateien ohne Git-Aufzeichnung zurückholen? Sichern Sie den aktuellen Zustand zuerst als vollständige Kopie und vergleichen Sie ihn dann mit dem Original aus dem Kurs, einer früheren Sicherung oder einer zweiten unveränderten Projektkopie.

Arbeiten Sie nicht direkt über der einzigen vorhandenen Fassung. Erstellen Sie beispielsweise eine Kopie des gesamten Projektordners und vergleichen Sie darin die betroffenen Dateien einzeln mit der Kursvorlage. Übernehmen Sie nur den Inhalt, dessen Herkunft und Zweck klar sind. Wenn eine Datei im Kursmaterial nicht vorkommt, behalten Sie sie zunächst und klären Sie, ob sie neu angelegt wurde oder zu einer anderen Projektkonfiguration gehört.

Eine vorsichtige Reihenfolge ist:

Den aktuellen Projektordner unverändert kopieren.
Die konkrete Fehlermeldung und das sichtbare Problem festhalten.
Geänderte, neue und fehlende Dateien sammeln.
Die betreffenden Dateien mit der Kursvorlage oder einer eigenen Sicherung vergleichen.
Nur bestätigte Inhalte zurückübernehmen.
Das Projekt in Xcode öffnen und erneut prüfen.

Fehlt eine verlässliche Originaldatei, ist das kein Grund, auf Verdacht ganze Ordner zu ersetzen. Fragen Sie gegebenenfalls die Lehrkraft oder vergleichen Sie die Abgabeanforderungen mit dem vorhandenen Projekt. So vermeiden Sie, dass eine Datei mit eigenen, noch gültigen Änderungen durch eine ältere Vorlage ersetzt wird.

Gibt es keine Sicherung und ist der ursprüngliche Inhalt nicht mehr verfügbar, lässt sich eine frühere Fassung nicht zuverlässig aus dem aktuellen Stand ableiten. In diesem Fall ist es sicherer, die unklaren Dateien aufzubewahren und den möglichen Wiederherstellungsweg zu klären, bevor weitergeschrieben wird.

Git-Änderungen gezielt zurücknehmen

Was ist zu tun, wenn Git vorhanden ist, aber nur ein Teil der Änderungen zurückgenommen werden soll? Prüfen Sie zuerst den Status und den Diff. Stellen Sie anschließend nur die bestätigten Dateien oder Änderungen wieder her. Die Befehle zum Vergleichen und Wiederherstellen sind in der Git-Dokumentation zu git diff und in der Referenz zu git restore erläutert.

Beginnen Sie erneut mit einer Sicherheitskopie und einer Übersicht:

git status --short
git diff --name-status
git diff -- Sources/ContentView.swift

Ist eine Datei seit dem letzten Commit geändert worden und soll ihre nicht vorgemerkte Arbeitskopie auf diesen Stand zurückgesetzt werden, kann git restore verwendet werden:

git restore --worktree -- Sources/ContentView.swift

Dieser Befehl ist nicht bloß eine Vorschau. Er ersetzt die ausgewählte Arbeitskopie durch den entsprechenden Inhalt aus dem Git-Verlauf. Führen Sie ihn deshalb erst aus, wenn die Datei geprüft, der Pfad korrekt und eine Kopie des aktuellen Projekts vorhanden ist. Ein versehentlich zu breit gewählter Pfad kann mehr eigene Arbeit verwerfen als beabsichtigt.

Vorgemerkte Änderungen sind davon zu unterscheiden. Prüfen Sie vor einer Wiederherstellung, ob Dateien im Status als vorgemerkt erscheinen, und lesen Sie die Dokumentation zu den Optionen von git restore. Verwenden Sie keine Befehle, deren Wirkung auf Index und Arbeitskopie unklar ist.

Geht es um einen bereits gespeicherten Commit, finden Sie zuerst heraus, welcher Stand für den Vergleich infrage kommt:

git log --oneline

Die Git-Dokumentation zu git log beschreibt, wie sich die Commit-Historie anzeigen lässt. Ein früherer Commit kann helfen, den alten Inhalt einer Datei zu finden. Er bedeutet aber nicht, dass das gesamte Projekt ohne Prüfung auf diesen Stand zurückgesetzt werden sollte. Stellen Sie einzelne Dateien aus einem bekannten Commit nur dann wieder her, wenn klar ist, warum gerade dieser Stand zur Aufgabe passt.

Möglichkeit	Geeignet, wenn	Wichtigstes Risiko	Sichere Entscheidung
Vergleich mit Kursvorlage	Kein Git-Verlauf, aber unveränderte Kursdateien vorhanden	Eigene Änderungen können durch die Vorlage verloren gehen	Projektkopie anlegen und Datei für Datei vergleichen
`git restore` für eine ausgewählte Datei	Git-Verlauf vorhanden und Zielstand bekannt	Arbeitsänderungen der Datei werden ersetzt	Diff prüfen, Sicherung anlegen und Pfad genau auswählen
Wiederherstellung aus einem Commit	Eine frühere Version im Verlauf identifiziert wurde	Ein falscher Commit passt nicht zur aktuellen Aufgabe	Verlauf und Dateiinhalt prüfen, nicht pauschal das ganze Projekt zurücksetzen
Änderung zunächst behalten	Herkunft oder Funktion einer Datei unklar ist	Fehler bleibt zunächst bestehen	Datei sichern und vor dem Löschen oder Ersetzen klären

Funktionierende App und Kursanforderungen getrennt prüfen

Ein erfolgreicher Build beweist nur, dass Xcode das Projekt unter den aktuellen Bedingungen bauen konnte. Er bestätigt nicht, dass die Lösung die Aufgabenstellung erfüllt, die erlaubte Dateistruktur einhält oder von der lernenden Person verstanden wird.

Gehen Sie deshalb getrennt vor:

Aufgabenstellung: Sind alle geforderten Funktionen vorhanden?
Projektstruktur: Wurden nur erlaubte Dateien oder Bereiche geändert?
Laufzeitverhalten: Stimmen Eingaben, Ausgaben und Ansichten mit der Aufgabe überein?
Nachvollziehbarkeit: Können Sie die geänderte Funktion Zeile für Zeile erklären?
Abgabe: Sind Format, Dateinamen und weitere Vorgaben der Lehrkraft eingehalten?

Lassen Sie sich unbekannte Änderungen erklären, aber prüfen Sie die Erklärung am Code und an der Aufgabenbeschreibung. Eine plausible Erläuterung durch Claude Code ist kein Nachweis, dass der Code richtig ist oder den Bewertungsmaßstab erfüllt. Übernehmen Sie keine Lösung, die Sie nicht selbst nachvollziehen können.

Für ein Swift-Kursprojekt kann der Versionsname Xcode 27 relevant sein, wenn die Aufgabe eine bestimmte Entwicklungsumgebung voraussetzt. Prüfen Sie die installierte Version und die dazu passenden Anforderungen in Apples Xcode-Systemanforderungen. Die Anforderungen unterscheiden sich je nach Xcode-Version; vergleichen Sie daher die Angabe der Lehrkraft mit Apples offizieller Übersicht, statt anzunehmen, dass jede installierte Version passt.

Build-Fehler von Umgebungsproblemen unterscheiden

Was hilft, wenn das Swift-Projekt nach den Änderungen nicht mehr läuft? Sichern Sie die vollständige Fehlermeldung und bestimmen Sie, in welcher Phase der Fehler auftritt. Eine Meldung zu einer Swift-Datei weist auf eine andere Fehlerstelle hin als ein Problem mit einem Ziel, einer Ressource oder einer Projekteinstellung.

Öffnen Sie das Projekt in Xcode und prüfen Sie die erste aussagekräftige Fehlermeldung. Folgefehler können lediglich durch den ersten Fehler ausgelöst worden sein. Notieren Sie außerdem, ob der Fehler bereits vor der Änderung auftrat, ob er nach einer gezielten Wiederherstellung verschwindet und ob eine bestimmte Datei oder ein bestimmtes Ziel betroffen ist.

Apple dokumentiert die Arbeit mit Xcode in der offiziellen Xcode-Dokumentation. Wenn der Build auf eine Phase oder einen Build-Schritt verweist, kann Apples Erklärung zum Anpassen der Build-Phasen eines Ziels helfen, Projektkonfiguration von Swift-Code zu unterscheiden. Ändern Sie dort nichts auf Verdacht: Eine Änderung an Build-Phasen kann andere Teile des Projekts betreffen.

Prüfen Sie der Reihe nach:

Swift-Fehler: Verweist die Meldung auf eine Datei oder eine bestimmte Codezeile?
Ressourcenfehler: Wird eine erwartete Datei, ein Asset oder ein Projektelement nicht gefunden?
Projekt- oder Zielkonfiguration: Scheitert der Build, bevor der betroffene Swift-Code geprüft wird?
Umgebung: Passt die verwendete Xcode-Version zu den Vorgaben der Aufgabe und zu den Systemanforderungen?

Wenn ein Kursprojekt ausdrücklich macOS und Xcode verlangt, aber kein geeigneter Mac verfügbar ist, vergleichen Sie zunächst die zugelassenen Möglichkeiten Ihrer Bildungseinrichtung mit den Projektanforderungen. Die Einführung in die Nutzung von NUMACS bietet einen Einstieg, um eine entfernte Mac-Umgebung als mögliche Option einzuordnen. Prüfen Sie vor einer Nutzung, ob der Zugriff und die Arbeitsweise den Vorgaben des Kurses entsprechen. Informationen zur Verarbeitung personenbezogener Daten finden Sie in den Datenschutzhinweisen von NUMACS.

Eine entfernte Mac-Umgebung ist nicht für jeden Fall die beste Lösung. Wer dauerhaft intensiv arbeitet, einen eigenen Mac benötigt oder bestimmte physische Anschlüsse vor Ort braucht, sollte die Anschaffung eines eigenen Geräts oder die bereitgestellte Ausstattung der Hochschule prüfen. Für eine zeitlich begrenzte Prüfung eines Swift-Projekts kann eine Miete dagegen einen Kauf vermeiden. Die verfügbaren Möglichkeiten lassen sich auf der Angebotsseite von NUMACS nachlesen; konkrete Eignung hängt von den Anforderungen des Kurses und dem benötigten Zugriff ab.

Bevor eine Aufgabe abgegeben wird, sollte die Wiederherstellung immer in einer Projektkopie nachvollzogen werden. Erst wenn der relevante Unterschied geprüft, der Build in einer passenden Xcode-Umgebung getestet und die Lösung mit den Kursvorgaben abgeglichen wurde, ist die Abgabe belastbar. Wer derzeit nur an einem unklaren Fehler arbeitet, sollte zuerst die lokale Sicherung und die Git-Ansicht nutzen; wer für die Prüfung zwingend macOS und Xcode braucht, kann anschließend bewerten, ob ein eigener oder vorübergehend gemieteter Mac besser zum Lernbedarf passt.