Skip to content

[feat] Support custom CFBundleVersion for iOS and macOS #12479

@velocitysystems

Description

@velocitysystems
Contributor

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

#10944.

Activity

changed the title [-][feat] Improve mobile app version management[/-] [+][feat] Allow specifying CFBundleVersion for iOS and macOS[/+] on Mar 19, 2025
changed the title [-][feat] Allow specifying CFBundleVersion for iOS and macOS[/-] [+][feat] Support custom CFBundleVersion for iOS and macOS[/+] on Mar 19, 2025
lucasfernog

lucasfernog commented on Apr 12, 2025

@lucasfernog
Member

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

h3poteto

h3poteto commented on May 18, 2025

@h3poteto

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.

velocitysystems

velocitysystems commented on May 18, 2025

@velocitysystems
ContributorAuthor

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

FabianLars commented on May 18, 2025

@FabianLars
Member

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

h3poteto commented on May 19, 2025

@h3poteto

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @h3poteto@velocitysystems@lucasfernog@FabianLars

      Issue actions

        [feat] Support custom CFBundleVersion for iOS and macOS · Issue #12479 · tauri-apps/tauri