Version code 1 has already been used — who owns that number, app.json or EAS?

I was shipping an update for one of my wallpaper apps when the Play Console upload stopped on a single line.

Version code 1 has already been used. Try another version code.

My app.json said versionCode: 2. I had bumped it. So my first assumption was that the Console was showing a stale value, and I waited a while and uploaded the same file again. Same result.

The problem was on my side, not Play's. The number I had bumped never made it into the build.

That number can live in more than one place. What decides the outcome is not where you wrote it — it's which location owns it. Here is how to tell, with something you can actually run.

The number is consumed even if you never published

Start with the Play side. versionCode is the integer Android uses to order updates, and Play will not let you reuse one it has already accepted. The part that catches people out is that a number is consumed even when nothing was released:

• you attached the bundle to a draft release and never rolled it out
• you uploaded it to internal testing or a closed track
• you saved a release without discarding the artifact

In all three cases the number counts as used. "Nobody has installed it, so it must still be free" is not how this works.

You can see the current state under Release → App bundle explorer in the Play Console. Every accepted bundle is listed with its version, so one glance tells you the highest number you have burned through. Open that screen before you start guessing at replacements.

From there you have two options:

1. Detach the bundle from the draft release, delete it in App bundle explorer, and free the number
2. Pick a higher number and rebuild

If you take the second route, the numbers do not have to be consecutive. Going from 2 straight to 10, or to 100, is fine as long as each upload is strictly higher than the last. When I burn a few numbers while debugging, I usually skip up to a round figure and restart from there — a visible gap in the history is easier to read later than a tightly packed sequence that hides the fact that something went sideways.

One thing that is not optional: rebuild after changing the number. The versionCode is baked into the AAB, so editing a config file and re-uploading the same artifact sends the old number to Play all over again. That loop is exactly what cost me the first hour.

Why the number you bumped never made it in

Here is the part that matters. In an Expo project, three places can decide versionCode:

• expo.android.versionCode in app.json (or app.config.js)
• a value stored on EAS servers, when cli.appVersionSource in eas.json is remote
• versionCode in android/app/build.gradle, when the android directory is committed to your repo

Which one wins depends on how the project is set up. When the place you edited is not the place that wins, you get the "I bumped it and it still shipped the same number" outcome.

The gap between what a config file declares and what the build actually reads is not unique to versionCode. I ran into the same shape of problem in the three places I had to fix before a Rork project actually targeted API level 36 — a config entry is a declaration, not the value the build consumes.

Reading this by eye is unreliable, so I let a script do it. No dependencies, just Node's standard library.

#!/usr/bin/env node
// Check the versionCode that will actually reach Play, before you build
import { readFileSync, existsSync } from "node:fs";
import { join } from "node:path";
 
const root = process.argv[2] ?? ".";
const readJson = (p) => (existsSync(p) ? JSON.parse(readFileSync(p, "utf8")) : null);
 
const appJson = readJson(join(root, "app.json"));
const easJson = readJson(join(root, "eas.json"));
const gradlePath = join(root, "android", "app", "build.gradle");
const hasNativeDir = existsSync(gradlePath);
 
const expo = appJson?.expo ?? {};
const declared = expo.android?.versionCode ?? null;
const versionName = expo.version ?? null;
 
let gradleCode = null;
if (hasNativeDir) {
  const m = readFileSync(gradlePath, "utf8").match(/versionCode\s+(\d+)/);
  gradleCode = m ? Number(m[1]) : null;
}
 
const source = easJson?.cli?.appVersionSource ?? "(not set)";
const profile = process.argv[3] ?? "production";
const autoIncrement = easJson?.build?.[profile]?.autoIncrement ?? false;
 
const notes = [];
let effective;
 
if (hasNativeDir) {
  effective = gradleCode;
  notes.push("android/ is committed, so build.gradle wins over app.json");
} else if (source === "remote") {
  effective = "managed by EAS (the local value only seeds it)";
  notes.push("the value lives on EAS, not in your files: run eas build:version:get");
} else {
  effective = declared;
  notes.push("app.json is the source of truth: forget to bump it and you ship the same number");
}
 
if (source === "(not set)") notes.push("eas.json has no cli.appVersionSource: decide who owns the number first");
if (!autoIncrement) notes.push(`autoIncrement is false for profile "${profile}": nothing bumps automatically`);
 
console.log(`project         : ${root}`);
console.log(`versionName     : ${versionName ?? "(not set)"}`);
console.log(`app.json declares: ${declared ?? "(not set)"}`);
console.log(`build.gradle    : ${hasNativeDir ? gradleCode : "(no android/)"}`);
console.log(`appVersionSource: ${source} / autoIncrement(${profile}): ${autoIncrement}`);
console.log(`goes into build : ${effective ?? "(undetermined)"}`);
notes.forEach((n) => console.log(`  - ${n}`));

The reason it prints a verdict rather than a table of values is that the value was never the confusing part. Seeing 2 tells you nothing about whether that 2 reaches the build. So the last line names the winning path outright.

Running it against three project shapes gives this:

==========
project         : a
versionName     : 1.0.0
app.json declares: 1
build.gradle    : (no android/)
appVersionSource: (not set) / autoIncrement(production): false
goes into build : 1
  - app.json is the source of truth: forget to bump it and you ship the same number
  - eas.json has no cli.appVersionSource: decide who owns the number first
  - autoIncrement is false for profile "production": nothing bumps automatically
==========
project         : b
versionName     : 1.2.0
app.json declares: 7
build.gradle    : (no android/)
appVersionSource: remote / autoIncrement(production): true
goes into build : managed by EAS (the local value only seeds it)
  - the value lives on EAS, not in your files: run eas build:version:get
==========
project         : c
versionName     : 1.3.0
app.json declares: 12
build.gradle    : 9
appVersionSource: local / autoIncrement(production): true
goes into build : 9
  - android/ is committed, so build.gradle wins over app.json

Shape c is the one I was in. app.json said 12; the build used 9. I had run prebuild once, kept the generated android directory in the repo, and then continued bumping only on the JavaScript side. Two plausible-looking numbers sitting in two files is not something you catch by scrolling.

In shape b, the local 7 is only a seed. After the first build the real value lives on EAS, so no amount of reading local files tells you what comes next — you ask with eas build:version:get.

Decide who owns the number, once

The scramble only happens when ownership was never decided. In EAS, cli.appVersionSource in eas.json states whether your files or the EAS servers hold the build version.

Choosing remote with auto-increment on the production profile looks like this:

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

One caveat worth stating plainly: switching to remote does not bump anything on its own. Moving ownership and incrementing automatically are two separate settings. I assumed they were one feature, set appVersionSource to remote, and was puzzled when a build came out with the same number as before. That is why the script above always prints autoIncrement alongside the source.

Right after you switch to remote, the value from your local config seeds the server-side counter. So during the migration, it is worth confirming that the local number is not lower than what Play has already consumed.

What I settled on for shipping six apps together

I run several wallpaper and calm-themed apps as configuration variants of one codebase. On days when I refresh the artwork, all six go out together — and that is where the numbering scheme started to matter.

My first approach derived the code from the version name: 1.4.2 became 10402, with digits allocated per component. Readable, and the correspondence was obvious at a glance. Then I shipped a second fix on the same day and ran out of room in the last field. Adding a digit meant re-checking the ordering against every previous release by hand.

Now I keep the two apart:

• versionName (expo.version) is set deliberately, because that is the number readers see
• versionCode is left to EAS autoIncrement, because it only needs to increase and carries no meaning

Since deciding that it carries no meaning, release day no longer includes any thinking about it. Each of the six keeps its own counter, so the numbers do not line up across apps — which I accepted after noticing that a case where alignment would have helped me had never actually come up.

That trade-off fits a solo or very small operation. If someone downstream reads the code to make a decision, keeping it meaningful under local management will serve you better.

Three lines before every submission

These days I run three things before building an AAB:

node audit-version.mjs .                 # which path actually wins locally
eas build:version:get --platform android # the server-side value, if remote
# Play Console → Release → App bundle explorer: the highest consumed number

Local configuration, server-side value, Play's record. When the three agree, the upload screen does not stop you. It takes about a minute.

Discovering the mismatch after the fact costs an entire build cycle instead, and EAS builds are not quick. That minute pays for itself easily.

What to do next

Open eas.json and check one thing: whether cli.appVersionSource is there at all. If it isn't, ownership of the number is undecided. Pick remote or local, write it down explicitly, and the next release is unlikely to end on that upload screen.

I shipped a good number of apps before I got around to writing that single line myself.