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

Two layers, no automatic undo

A Capacitor upgrade touches two layers: the npm packages (@capacitor/core, @capacitor/cli, and the platform packages) and the native ios/ and android/ projects, updated through the documented sync step that copies web assets and plugin configuration. Because those native directories are real, editable projects, there is no built-in rollback for a failed upgrade; recovery rests on version control or on regenerating a platform.

Two constraints complicate the choice:

• Committing ios/ and android/ preserves manual native customizations and makes a git revert a candidate recovery path, but it complicates regeneration-based rollback.
• Excluding them keeps rollback simple, but hand-edited Gradle or Podfile changes are not restored by the sync step alone.

Major-version upgrades can also require toolchain-side changes (Xcode, Android Studio, Gradle), so reverting app code may not undo everything an upgrade touched. Exact steps vary by major version and should be checked against the matching upgrade guide.

For a team standardizing on one approach:

1. Should the native directories be committed so a revert restores the exact native state, or excluded in favor of regenerating platforms?
2. When a platform is regenerated, how are plugin-specific native hooks re-applied reliably?
3. Does reverting package.json and reinstalling dependencies fully restore a working build when the native directories are tracked?