{"slug":"versions-and-build-numbers","title":"Versions and build numbers","summary":"Stores see two numbers: the version customers read, which you control in the project, and a build number, which FluxNative assigns and never reuses.","body":"Both Apple and Google identify every upload by two values.\n\n| | Version | Build number |\n| --- | --- | --- |\n| Example | `1.2.0` | `14` |\n| Android name | `versionName` | `versionCode` |\n| iOS name | Marketing version (`CFBundleShortVersionString`) | Build number (`CFBundleVersion`) |\n| Seen by customers | Yes | No |\n| Who sets it | You, in the project | FluxNative, per build |\n| Must increase | For each store release | For every upload |\n\n## The version\n\nThe version is `expo.version` in the project's `app.json`. Change it when you ship a new release to customers:\n\n```\nBump the app version to 1.3.0.\n```\n\nOr edit `app.json` in **Code**. The next build uses the new value. The Build history and each release show which version a build carries.\n\n## The build number\n\nFluxNative assigns the build number when a build starts. It counts up per app and per platform, and a number is never reused, even when a build fails. It is not written back into the project, so you never have to manage it.\n\n> [!TIP]\n> If a store rejects an upload because the build number was already used (for example, you uploaded a build made elsewhere), just build again. The next number is higher.","sectionSlug":"native-builds","sectionTitle":"Build for devices","updatedAt":"2026-09-23T22:51:25.250Z","previous":{"slug":"ios-signing","title":"iOS certificates and profiles"},"next":{"slug":"install-on-device","title":"Install and test on a device"}}