note that tauri ios build has a --build-number <number> option to allow appending a build number to the version string

It's great that the CFBundleVersion can now be specified manually.

However, I have an error when releasing my tauri app.
In previous versions, the CFBundleVersion was automatically generated based on the current date and time. For example, a value like 20250401.1234 would be set automatically. This was very convenient, and we had been releasing our app to the App Store using this format.

After updating to the latest Tauri version, our releases fail with an error from the App Store. This is because CFBundleVersion is now automatically set to the semantic version (e.g. 1.12.3), which is lower than our previous date-based versions. Since the App Store requires CFBundleVersion to always increase, the upload is rejected.

The only workaround now is to manually specify bundleVersion every time, using our previous date-based format. This feels like a step backwards — what used to be handled automatically now requires manual work for every release.

Would it be possible to reintroduce an option for automatic timestamp-based CFBundleVersion, or at least provide a way to opt into this behavior? It would help a lot for teams that rely on automated pipelines.

Thanks for your comments @h3poteto. It's helpful to understand your use-case. I would comment that while this may have worked before it isn't the responsibility of the build toolchain to handle automatic generation of CFBundleVersion. This becomes restrictive when applications have different and unique versioning requirements.

I would suggest simply injecting the value you require in the CI/CD pipeline. This can be done with a simple script i.e. Shell, PowerShell etc and integrated into your pipeline of choice i.e. GitLab, GitHub, Azure DevOps etc. I'm happy to provide sample scripts if that would be helpful?

In theory I totally agree with you but since it's something tauri did I still wonder if we should allow users to specify "timestamp" for example and let tauri do the old behavior. Maybe not forever but for v2? Really unsure, maybe it's better to just rip the bandaid while there aren't that many published apps yet.

@velocitysystems

I would comment that while this may have worked before it isn't the responsibility of the build toolchain to handle automatic generation of CFBundleVersion.

If it had acted like that from the beginning, there would have been no problem, and I agree with you. However, the behavior has changed midway, so people who had already published apps are having problems.

In fact, apps that already used a datetime-based (the old behavior) bundleVersion cannot add a free CFBundleVersion. It just adds extra work.
As @FabianLars suggested, wouldn't it be better to allow specifying the old format at least for v2? For example,

• Use a datetime-based (the old format) CFBundleVersion when no bundleVersion is specified.
  • Currently, the app version is used for it by default.
• Use a datetime-based CFBundleVersion when special characters are specified.
  • e.g. $timestamp