Capacitor has no built-in rollback for failed upgrades: track the native projects or regenerate them?

Capacitor upgrade rollback: tracking native projects vs regenerating platforms

Capacitor upgrades modify two independent layers: the npm packages (@capacitor/core, @capacitor/cli) and the native ios/ and android/ directories updated through the documented sync step. The framework has no built-in rollback mechanism, so recovery depends on version‑control reverts or regenerating the affected platform.

Confirmed facts: Capacitor does not undo a failed upgrade automatically. The native directories are real, editable projects; their state after a sync step reflects the last npx cap sync run, not necessarily the pre‑upgrade state.

Likely explanation: If you commit ios/ and android/ in git, a git revert or checking out a prior commit can restore the exact native build that worked before the upgrade, but subsequent npx cap sync may re‑apply the newer plugin configuration, potentially overwriting tracked changes. If you exclude them, platform regeneration via npx cap add ios (or android) is idempotent, but any hand‑edited Gradle or Podfile changes outside the sync configuration are not restored.

1. If native directories are tracked: git checkout <previous-tag> -- ios/android, then npx cap sync, then npx cap build android|ios to verify the build succeeds.
2. If native directories are excluded: npx cap add ios (or android), re‑apply any custom native plugin hooks, run npx cap sync && npx cap build to confirm the build works.

Missing diagnostic: Do you have hand‑edited Gradle or Podfile changes that aren’t tracked in the native directories? Answering this will determine whether tracking or regenerating platforms is the safer rollback path for your project.