SemVer Helper
Parse any version number, understand what each part means, and get the right next version suggested.
Version numbers carry meaning — or at least they should. Semantic versioning gives each of the three positions in MAJOR.MINOR.PATCH a job: major for breaking or headline changes, minor for new backwards-compatible features, patch for bug fixes. This helper parses whatever version you paste, labels each component, validates the format, and suggests the correct next major, minor, and patch versions.
It also covers the app-store wrinkle that trips up SemVer purists: Apple’s CFBundleShortVersionString is the user-visible version (up to three period-separated integers), while CFBundleVersion — the build number — is a separate counter that must increase with every upload. Knowing which number to bump, and when, keeps App Store Connect from rejecting your build.
How to use the SemVer helper
- 1
Paste or type a version number — 2.4.1, 3.0, or even 1.5.0-beta.2 — into the field above.
- 2
Read the breakdown: each component is labeled (major, minor, patch, plus any pre-release or build metadata) with a plain-English explanation of what bumping it signals.
- 3
Check the format validation — App Store versions must be one to three period-separated integers, so suffixes like -beta belong in internal builds, not the store version.
- 4
Copy the suggested next version that matches your release: patch for a bug-fix update, minor for new features, major for a redesign or breaking change.
What major, minor, and patch actually promise
Semantic versioning (semver.org) defines the contract precisely for libraries: bump MAJOR for incompatible API changes, MINOR for functionality added in a backwards-compatible way, PATCH for backwards-compatible bug fixes. Consumer apps don’t have API consumers, but the same grammar still communicates well — users and app reviewers read 3.0 as “big update, expect changes”, 2.5 as “new stuff”, and 2.4.3 as “fixes”. Consistency is the real win: once your team agrees what each position means, changelogs, support tickets, and crash reports all become easier to reason about.
SemVer also defines pre-release and build metadata: 2.0.0-beta.1 marks an unstable pre-release that sorts before 2.0.0, and anything after a plus sign (2.0.0+42) is build metadata ignored for precedence. These are great for TestFlight naming conventions and CI pipelines — just keep them out of the version you submit, because the App Store version field accepts only plain numbers and periods.
Apple’s two numbers: version string vs. build number
iOS apps carry two independent identifiers. CFBundleShortVersionString is the marketing version users see on the store — Apple expects one to three non-negative integers separated by periods (so 2.4 and 2.4.1 are valid; 2.4.1.7 and 2.4-beta are not) and each release’s version must be higher than the last. CFBundleVersion is the build number, which must be unique and ascending among the builds uploaded for a given version; teams commonly reset it to 1 per version or drive it from a CI run counter.
The most common upload rejection here is reusing a build number: uploading a second build for version 2.4.1 without bumping CFBundleVersion fails immediately. Android mirrors the split with versionName (the human string, where SemVer fits naturally) and versionCode (a single integer that must strictly increase forever and can never be reused — Google Play caps it at 2100000000, so leave room in any date-based scheme).
Frequently asked questions
What do the numbers in a version like 2.4.1 mean?
In semantic versioning, 2 is the major version (breaking or headline changes), 4 is the minor version (new backwards-compatible features), and 1 is the patch (bug fixes). Bump exactly one position per release and reset the positions to its right — after 2.4.1, a feature release becomes 2.5.0, not 2.5.1.
What is the difference between the version number and the build number on iOS?
CFBundleShortVersionString is the public version shown on the App Store (e.g. 2.4.1). CFBundleVersion is the build number, an internal counter that must be unique for every binary you upload under that version. You can upload builds 1, 2, 3 of version 2.4.1 to TestFlight — users only ever see 2.4.1.
Can I use a version like 2.4.1-beta on the App Store?
No. The App Store version field accepts only up to three period-separated integers — letters, hyphens, and a fourth component are rejected. Keep pre-release labels like -beta.2 in your internal build naming or TestFlight notes, and submit a clean numeric version.
Do app version numbers affect ASO or rankings?
Not directly — the algorithm doesn’t reward a bigger number. Indirectly, versioning matters: regular updates signal an actively maintained app, and each release’s “What’s New” notes are a real conversion surface that returning users and cautious first-time installers actually read.
Should my Android versionName match my iOS version?
It’s good practice when the releases are equivalent — one version number across platforms simplifies support, changelogs, and marketing. The stores don’t require it though, and the numeric constraints differ: sync the human-readable versions, but manage iOS build numbers and Android versionCode independently per platform.
When should I go from version 1.x to 2.0?
For an app (rather than a library), 2.0 is a communication decision: reserve it for a redesign, a major feature set, or a repositioning you want users and the press to notice. Shipping 2.0 for a routine update wastes the signal — and inflating major versions quickly leads to meaningless numbers.
Version, release notes, rollout — one flow
Appalize creates App Store versions, localizes your release notes, and manages the rollout through its App Store Connect integration — scriptable end to end via the Appalize MCP and API.
Related free tools
Release Timing Planner
Pick the right day to submit and release your app update, with review times and rollout curves accounted for.
App Version Viewer
Look up any app’s current version, release date, and full release notes without opening the store.
Pre-Submission Checklist
Run through every App Store submission requirement before you press “Submit for Review”.
Metadata Diff Tool
Compare two versions of any metadata text with a word-level diff.