App version follows semantic versioning
Why it matters
Non-semver strings like 1.0, v1.0.0-beta, or 01.00.00 break downstream tooling that parses app.json — EAS Update channels, Sentry release matching, crash-report grouping, and CI/CD diff-comparison scripts all assume the MAJOR.MINOR.PATCH contract. When the format drifts, release notes collapse into a single bucket, regression bisects miss the breaking commit, and users cannot tell a feature release from a hotfix. Semantic versioning is also the communication channel App Store Connect and Play Console use to render "What's New" prompts correctly.
Severity rationale
Low because malformed versions degrade tooling and release hygiene but do not compromise security or user-facing functionality directly.
Remediation
Set the version field in app.json to three non-negative integers separated by dots and strip any prefixes or pre-release labels — those belong in buildNumber or a separate channel identifier. Automate the constraint in CI so a malformed value fails the pipeline before it reaches a store submission.
// app.json
{
"expo": {
"version": "1.0.3",
"ios": { "buildNumber": "12" },
"android": { "versionCode": 12 }
}
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the App Store Readiness Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from mobile-store-readiness·automated