Why you should change your mobile app version format to [year].[week].[iteration]
As a software engineer, I’ve been trained to think that there’s only one way to version software: semantic versioning.
At Photoroom, we used to increment the major version number on big releases to celebrate. Recently, however, we moved our mobile apps to a versioning scheme like like 2025.51.01 (so [year].[weekNumber].[iteration])
The main reason is convenience. At a glance you can know whether a user contacting support is on an old version or not or if a coworker reporting a bug forgot to update.
It’s also quite useful to understand version distribution. You can see below that most users on iOS are on version 2025.50.03 (meaning the third iteration of the 50th week of the year) and are progressively upgrading to 2025.51.01:
One convenient thing you can do is deprecate some routes by looking at the version number to know which clients are older than one year/some duration, here’s some pseudocode:
version = request.headers["pr-app-version"]
weeksSinceAppWasReleased = parseWeeksSinceAppRelease(version)
if weeksSinceAppWasReleased >= 52:
return {error: "APP_OUTDATED", errorMessage: "Your app is outdated, please visit the app store to update"}
The downsides
As App Store version have to be incremental, so once you try this setup, you can’t go back.
When we implemented it, I also worried that such long version numbers would be a bit scary for users on the app store listing page, but it seems they don’t mind. On my side, I’m still a bit worried when I see Uber’s super long version number:
Overall, I’d recommend this setup in a heartbeat if you run a mobile app at scale.
This article was cross-posted on Photoroom’s blog