Version Control Strategy

Mobile apps ship binaries, not just source. Every production build must trace back to an exact git commit and tag. When a crash report says 'version 2.4.0 build 20400', your team must checkout that tag and reproduce.

Tie git tags to store builds

Maintain one source of truth for version strings — typically app.json, package.json, or a dedicated version.json updated by Fastlane.

Version mapping flow

Version fields explained

versionName / CFBundleShortVersionString — user-visible '2.4.0' on store listing.
versionCode / CFBundleVersion — integer build number; must always increase per upload.
Git tag v2.4.0 — immutable pointer to the release commit.
CI build number — optional fourth identifier for internal tracking (e.g. CI run ID).

app.json version fields (Expo / RN)

{
  "expo": {
    "version": "2.4.0",
    "ios": { "buildNumber": "20400" },
    "android": { "versionCode": 20400 }
  }
}

Fastlane increment_version_number

increment_version_number(bump_type: "patch")
increment_build_number(xcodeproj: "ios/MyApp.xcodeproj")
# Android: update versionCode in build.gradle via gradle helper

Changelog discipline

Keep CHANGELOG.md with sections: Added, Changed, Fixed, Removed per release.
Auto-generate from conventional commits using standard-version or release-please GitHub Action.
Paste changelog into Play Console 'Release notes' and App Store 'What's New' fields.