In the world of Expo and React Native development, versioning is often a source of friction. You set
a version in your `app.config.ts` , run a build with the `--auto-increment` flag, and suddenly
realize your app store listing hasn't moved from "1.0.0" even though you've made ten builds.
This blog post aims to clear the "versioning fog" by explaining exactly what EAS automates, what it
ignores, and how to build a workflow that actually works.
The Root of Confusion: One Name, Two Roles
The primary reason for confusion is that "version" is used colloquially to mean two very different
things in mobile development:
- The Marketing Version: The Semantic Version aka SemVar string of the format Major.Minor.Patch (e.g., 1.2.3) that users see in the App Store. The mobile config files like `app.config.ts` typically has this.
- The Build Identifier: An internal counter (e.g., `versionCode 15`) that tells the OS or CICD or Android PlayStore that this binary is newer than the previous one.
If you are like me, who leverages Expo's EAS services for Android app builds, it is important to know that the `--auto-increment` is designed to handle the Build Identifier but not the semantic marketing version.
Incrementing The (Private) Build Identifier
When you trigger a build with auto-increment enabled, EAS performs a cloud check of your previous build and updates specific platform fields - `expo.android.versionCode` in the case of Android build, and increments the integer by 1, from its earlier integer value. You have two ways to do this:
1. The CLI Override
```
eas build --platform android --auto-increment
```
2. The "Smart" Configuration (Recommended)
Below is a reference example of an `eas.json` that has this configured in it.
--
--
Incrementing The (Public) SemVar Marketing Version
If you need to update your Major, Minor, or Patch version, you have two reliable paths. You can
either override it at the command line or use a dynamic configuration.
1. The CLI Override
If you want to push a specific version without touching your config file, use the `--version` flag like below:
```
eas build --platform android --version 2.0.0
```
2. The "Smart" Configuration (Recommended)
A better way to clarify your workflow is to link your `app.config.js` directly to your `package.json` like below in the reference config example:
--
--
--
A Clean Release Workflow
To keep your versions consistent across your code, your store listings, and your internal builds,
follow this sequence:
- Use `npm version patch` (or minor/major) to update your `package.json`.
- Commit the change to Git.
- Run `eas build --profile development`
By using this flow, your "Marketing Version" is explicitly managed by you, while the "Build
Numbers" are invisibly managed by EAS.