Xcode Source Control as a Project Backup: Configuring the Restore and Verification Boundary

The goal is to configure Xcode's built-in source control as the primary backup and restore path for an app project: regular commits to a local Git repository, with recovery performed through the Source Control navigator by discarding changes or checking out an earlier commit.

The constraints have fuzzy edges. The legacy Snapshots feature was retired around Xcode 9, and snapshot menu items and automatic-snapshot preferences have shifted across releases, so available options must be confirmed in the installed version. Xcode offers no one-click verify-restored-backup action; after files are restored, integrity checking is manual, and stale DerivedData state (indexes and build products, safe to delete and regenerated) can mask recovery problems. Certificates and provisioning profiles live outside the project folder, so a repository restore does not cover signing. A local repository alone does not protect against disk loss.

Three decisions need pinning down before this setup can be called a backup policy:

1. Can Xcode's local Git integration stand alone as the backup of record, or must an external remote be mandatory to close the disk-loss gap?
2. After restoring files from a prior commit, is a Clean Build Folder pass plus a full test-suite run sufficient verification, or should DerivedData always be cleared first?
3. Which signing assets require a separate backup path outside the repository?