Symptom → fastest safe response: Claude Code changed your Swift assignment, and you are not sure what is wrong. Stop asking it to edit, duplicate the project, inspect the file differences, and restore only changes you can identify.
This guide is for students learning Swift or iOS development who use Claude Code to review or edit coursework. It is especially useful when a project no longer builds, a file looks unfamiliar, or you need to check your work before submitting it.
What to do when Claude Code breaks a Swift assignment
Do not start by deleting files or resetting the whole project. First, record what you see: the error message, unexpected behavior, or files that appear to have changed. Then make a separate copy of the entire project, including its project settings and supporting files.
Claude Code can work with project files, so a change may involve more than the Swift file currently open in Xcode. The Claude Code getting-started documentation explains its use in a coding project. That is a reason to inspect the project as a whole, not evidence that a particular change is automatically wrong.
Keep the original copy untouched. Use the duplicate for inspection and recovery. If there is no backup, no Git history, or no clear understanding of what a file does, preserve it until you can compare it with a trusted version.
A useful first pass is:
- Note the action that happened immediately before the problem.
- Save the complete error text or a screenshot of unexpected behavior.
- Copy the project to a separate folder.
- Open the copied project and check whether the same problem occurs.
- Avoid asking Claude Code to “fix everything” before you know which files changed.
That last step matters. A second broad edit can make the original problem harder to identify.
File changes and symptoms
A Swift assignment can look “broken” in different ways. A file may have been edited, the project may fail to build, the app may run but behave differently, or the code may simply be unfamiliar. Treat each symptom as a separate investigation.
| What you notice | What to check first | Safer next move |
|---|---|---|
| A file contains unfamiliar code | Compare the file with its earlier version | Keep the changed copy; restore only after confirming what should replace it |
| Xcode reports a build error | Read the first relevant error and identify its file or setting | Check the named code and project configuration before changing unrelated files |
| The project builds but behaves differently | Reproduce the behavior and compare it with the assignment brief | Trace the changed code path and test the required behavior |
| Files seem to be missing or newly added | Check the project file list and version-control status | Do not delete a file based only on its name |
The project file list is only a starting clue. A file that looks generated or unfamiliar could still be required by the assignment or project settings. Compare its contents and role before removing it.
How to see what Claude Code changed in a Swift project
If the project uses Git, open a terminal in the project folder and run:
git status --short
git diff --name-status
The first command gives a compact view of the working tree. Git’s short status format uses a two-character status code to distinguish the state of a path; the official status documentation explains how to read it. The second command lists paths with differences. Neither command changes your files.
To inspect an individual file, use:
git diff -- Sources/Example.swift
Replace the sample path with the path shown in your project. By default, git diff compares working-tree changes with the index; the Git diff documentation describes this comparison and other forms. Read the lines marked as removed and added together. A removed line is not necessarily useless, and an added line is not necessarily correct.
If you staged changes, compare the staged version separately:
git diff --cached -- Sources/Example.swift
This checks the staged content against the latest commit. You can also review recent project history with:
git log --oneline
Use the Git log documentation to understand what the history shows. A commit is a saved point in the project, but it is not proof that the code meets your course rubric.
Recovery without Git history
How to recover a changed assignment file without Git
If there is no Git record, do not run a reset command or copy an old file over the project immediately. Make another copy of the current project first. Then look for a reliable comparison source: the original course download, a backup you made before editing, or a separate copy supplied by the instructor.
Work one file at a time:
- Compare the current file with the trusted original.
- Identify which sections differ.
- Check whether the assignment expects any changes made after that original version.
- Restore only the confirmed section or file in your working copy.
- Keep the changed version in the backup in case you need to revisit it.
If the trusted source is older than your latest work, replacing the entire file may erase your own changes. In that case, preserve both versions and compare the relevant code blocks manually. Do not assume the “cleaner-looking” version is the right one.
If you cannot tell whether a file belongs to the assignment, leave it in place for now. You can ask a course instructor or compare it with the project instructions before removing it.
Git recovery by change type
Once you have a separate project copy, choose the recovery method based on what Git reports. Git distinguishes changes in the working tree, staged changes, and saved commits. Those states are different, so “undo” is not one universal action.
For an unstaged edit, inspect the exact file first:
git diff -- Sources/Example.swift
If you decide that a tracked file should return to its current staged version, Git documents git restore --worktree -- <path> for restoring the working-tree file from the index. If the intended source is the latest commit instead, a command such as the following selects that source explicitly:
git restore --source=HEAD --worktree -- Sources/Example.swift
This overwrites the working copy of that path. Use it only after checking the path and preserving a separate copy. The official restore documentation explains the source and destination options.
Staged changes require a separate decision. git restore --staged -- <path> removes the path from the staging area while leaving the working-tree content in place. That is not the same as restoring the file’s contents. Check the command’s effect against the restore reference before running it.
For a saved commit, first inspect the history and identify the version you want. Restoring a file from a commit is not the same as moving the whole project back to an earlier state. Avoid commands that reset the entire working tree when the assignment contains other work you need to keep.
Untracked files are another special case: Git has no earlier tracked version to restore for them. Do not treat them as disposable. Check whether they are new assignment files, generated files, or work you created yourself.
If only part of a tracked file needs restoring, Git also provides interactive restore options. Review the official command documentation before using them, and read each proposed change carefully. Do not accept a whole-file restore simply because one block is wrong.
Build failures and assignment checks
What to do when the Swift project will not run after Claude Code
A failed build does not automatically mean the Swift code is the only problem. Separate the possibilities: a code error, an Xcode project setting, a missing resource, or an incompatible development environment.
Start with the first useful error in Xcode’s build report. Record the file name and line number if shown. Then check whether the changed code is in that location. If the message points to a target, build phase, or missing resource instead, inspect the project configuration before rewriting Swift code. Apple’s documentation on customizing build phases describes how build-phase settings affect what happens during a build.
Next, compare the project’s Xcode version and macOS requirements with the environment required by your course. Apple’s Xcode system requirements are the reference for supported combinations. If an assignment specifies Xcode 27, check the requirements for that release rather than assuming another installed version is interchangeable. The general Xcode documentation is a starting point for project and build topics.
If the project builds but the result is wrong, compare what it does with the assignment instructions. Check the required screens or outputs, the expected file structure, and the submission rules. A successful build only shows that Xcode completed the build; it does not show that the assignment meets its requirements.
Understanding the changes before submission
Claude Code’s explanation can help you investigate, but it cannot confirm that an edit matches your instructor’s criteria. Read each changed section and write down, in your own words, what it does. If you cannot explain a block, do not submit it as though you had verified it.
For each meaningful change, ask:
- Does it implement a requirement in the assignment brief?
- Does it change behavior outside the requested task?
- Can you explain why the code or setting is needed?
- Does the project still behave correctly after the change?
- Are any comments, files, or required submission steps missing?
Test the actual requirements, not just whether the app launches. For example, if the assignment asks for a particular input and output, check that case directly. Keep a record of any remaining errors and ask for help with the specific behavior rather than requesting a broad rewrite.
The Claude Code CLI usage guide covers command-line interaction. Use focused questions when you need an explanation, such as asking what a specific changed function does. Then verify the answer against the code and assignment brief. An AI explanation is a lead to check, not a grading decision.
When a Mac is needed for verification
If the course requires macOS and Xcode and there is no suitable Mac available, first check what the instructor or institution permits. A school lab, an approved remote environment, or a Mac already available to you may be enough. If you only need to inspect a non-Mac-specific part of the code, a different development environment may help, but it cannot replace the Xcode build check required by a course.
Remote Mac access can be an option when you need a real macOS environment temporarily but do not want to buy a computer just for one assignment. NUMACS provides remote access to hosted Mac computers through VNC, SSH, or a web console, with root access, under weekly, monthly, or quarterly plans. Check the NUMACS getting-started guide for access information and the plan comparison before deciding whether that setup fits your course.
This option is not automatically the best choice. If you need a Mac every day for sustained work, buying or using a local machine may be more convenient. If you need a physical port or hardware connection, remote access may not meet that requirement. For a short verification task, though, it can avoid buying a Mac, while still letting you open the project in macOS and Xcode. Review current options on the NUMACS plans page before choosing; no plan removes the need to understand and verify your own code.
Before submitting: keep the untouched copy, restore only changes you can identify, rebuild the project, and check every required behavior against the course brief. If you need a Mac only to verify an Xcode project and do not have one available, compare an approved local or remote option first; use NUMACS only if its remote setup and rental period suit the assignment.
Further reading
NUMACS Cloud Mac
Test Your Swift Project on a Dedicated Mac
Run your Swift project on a dedicated Apple Silicon Mac mini from NUMACS.