[Feature request]: Add prerelease identifier to CFBundleShortVersionString in Info.plist

[cdwmhcc]

Is your feature request related to a problem? Please describe

No response

Describe your feature request!

Currently, prerelease versions (beta, rc, etc.) don't include the prerelease identifier in the app's Info.plist file, which causes version comparison issues for third-party update checkers.

Current behavior:

• GitHub Release tag: 2.5.0-beta.0
• CFBundleShortVersionString in Info.plist: 2.5.0.0 ❌
• CFBundleVersion in Info.plist: 164

Expected behavior:

• GitHub Release tag: 2.5.0-beta.0
• CFBundleShortVersionString in Info.plist: 2.5.0-beta.0 ✅
• CFBundleVersion in Info.plist: 164

Why this matters:
When comparing versions programmatically:

• 2.5.0.0 (from Info.plist) > 2.5.0-beta.0 (from GitHub) ❌ Incorrect
• Update checkers think the local version is newer than the latest release
• This breaks automatic update detection

Suggested fix:
Include the prerelease identifier in CFBundleShortVersionString to match the semantic versioning standard:

<key>CFBundleShortVersionString</key>
<string>2.5.0-beta.0</string>

Thank you for considering this improvement!

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[CodeDoctorDE]

Hi, thanks for the idea.
Sadly CFBundleShortVersionString needs to have a specific format: https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring

[cdwmhcc]

Thanks for the response! I'd like to clarify an important point about Apple's guidelines:

Key distinction: App Store vs. Direct Distribution

The fundamental point: Prerelease versions (beta, canary, etc.) are NEVER submitted to the App Store - they are only distributed directly (via GitHub, website downloads, etc.)

Therefore, there is NO conflict between:

1. ✅ Using 7.0.0-beta.6 in CFBundleShortVersionString for direct distribution
2. ✅ Using 7.0.0 in CFBundleShortVersionString for App Store submission

Apple's guideline context

When Apple says "use major.minor.patch format," they're talking about App Store submissions. This makes sense because:

• App Store doesn't have a concept of "channels" (beta/stable)
• TestFlight handles beta testing separately
• Production App Store releases should use clean version numbers

But for direct distribution? Apple's documentation simply states:

"The version number string can contain alphanumeric characters and periods."

There's no prohibition against using prerelease identifiers like 1.0.0-beta.1.

2.5.0.0 > 2.5.0-beta.0  // ❌ Incorrect comparison

Third-party tools think the beta is "older" than what's installed.

Proposed solution

Use different build configurations for different channels:

For GitHub beta releases (direct distribution):

<key>CFBundleShortVersionString</key>
<string>2.5.0-beta.0</string>

For App Store releases (if/when you submit):

<key>CFBundleShortVersionString</key>
<string>2.5.0</string>

Bottom line

There is no conflict because:

1. ❌ Prerelease versions are never submitted to App Store
2. ✅ Prerelease identifiers are only for direct distribution
3. ✅ This follows semantic versioning standard
4. ✅ Many apps successfully use this approach

Using 2.5.0-beta.0 in Info.plist for beta builds doesn't violate any Apple guideline - it just makes version management work correctly for tools and developers.

Would you reconsider this approach? It would greatly improve compatibility without any downside. 🙏

---

References:

• Semantic Versioning 2.0.0

[CodeDoctorDE]

yeah sure. currently it is set by the flutter framework. feel free to update the github actions ci to use the real name.
the bash commands to find the version:

          BUTTERFLY_VERSION_REGEX="version:\s(.+)\+(.+)"
          [[ $(grep -E "${BUTTERFLY_VERSION_REGEX}" app/pubspec.yaml) =~ ${BUTTERFLY_VERSION_REGEX} ]]
          BUTTERFLY_VERSION="${BASH_REMATCH[1]}"

[cdwmhcc]

Okay, thank you.

You can also check out the documentation on Channels in Sparkle, the well-known macOS update framework: https://sparkle-https://sparkle-project.org/documentation/publishing/

The core issue now is that once a user installs 2.5.0-beta.0, unless they subscribe to GitHub update notifications, they will not be able to receive update notifications until 2.5.1 is released.