-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Labels
Description
Describe the problem
For iOS, Tauri synchronizes both CFBundleVersion
and CFBundleShortVersionString
with the version property in tauri.conf.json
. Android separately defines a versionCode
property which is settable in the bundle configuration.
This means we cannot distinguish between the user-facing version visible in stores and the developer-facing build version. Expo for React Native handles this well by defining the following configuration properties:
Property | Description |
---|---|
version |
The user-facing version visible in stores. On Android, it represents versionName name in android/app/build.gradle. On iOS, it represents CFBundleShortVersionString in Info.plist. |
android.versionCode |
The developer-facing build version for Android. It represents versionCode in android/app/build.gradle. |
ios.buildNumber |
The developer-facing build version for iOS. It represents CFBundleVersion in Info.plist. |
Describe the solution you'd like
Implement a similiar approach in tauri.config.json
for defining the developer-facing build version for iOS and macOS.
Alternatives considered
N/A
Additional context
yokuze, Choochmeque, setoelkahfi and aldewaal-jw
Activity
0.1.0-1
) #12470[-][feat] Improve mobile app version management[/-][+][feat] Allow specifying CFBundleVersion for iOS and macOS[/+][-][feat] Allow specifying CFBundleVersion for iOS and macOS[/-][+][feat] Support custom CFBundleVersion for iOS and macOS[/+]lucasfernog commentedon Apr 12, 2025
note that
tauri ios build
has a--build-number <number>
option to allow appending a build number to the version stringh3poteto commentedon May 18, 2025
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 like20250401.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 semanticversion
(e.g.1.12.3
), which is lower than our previous date-based versions. Since the App Store requiresCFBundleVersion
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.velocitysystems commentedon May 18, 2025
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?
FabianLars commentedon May 18, 2025
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.
h3poteto commentedon May 19, 2025
@velocitysystems
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,
CFBundleVersion
when nobundleVersion
is specified.CFBundleVersion
when special characters are specified.$timestamp