Xcode 13 app archiving is modifying framework plist

Hey, in the company I work for we were also facing this issue. It had a very bad side effect on our release, because all third party frameworks had their CFBundleShortVersionString replaced by our app CFBundleShortVersionString in the process of archiving and generating an IPA when using Xcode 13, and some of those third parties rely on their framework version number to be sent on networking calls for them to behave properly.

The solution for us was to specifically set manageAppVersionAndBuildNumber on the -exportOptionsPlist for xcodebuild, or in our case more specifically via Fastlane's gym export-options property, to false. It seems manageAppVersionAndBuildNumber is a new export option introduced for xcodebuild on Xcode 13, that when set as YES (its default) ends up having this unexpected side effect.

From xcodebuild -help:

Available keys for -exportOptionsPlist:

manageAppVersionAndBuildNumber
        Should Xcode manage the app's build number when uploading to App Store Connect? Defaults to YES.

We are not 100% sure if manageAppVersionAndBuildNumber was indeed introduced on Xcode 13, but in case it was already there, then there was a change in behavior since exporting on Xcode 12.* works just fine without it.

The Xcode 13 release notes doesn't seem to have have any details about it, and we didn't find any other official Apple statement mentioning that as well :/. Would be great to have someone from Apple confirming this.

I hope that helps! 🤞

Automatic version number management is new to Xcode 13. These additions were detailed in a WWDC session, as well as the Xcode 13 Release Notes:

When uploading an app to App Store Connect, the distribution assistant in Xcode detects whether your app has a valid build number (CFBundleVersion). If your app has an invalid number (like one that was used previously, or precedes your current build number), the distribution assistant provides an option to automatically increment it to a valid number. In addition, the distribution assistant ensures that the build numbers of all embedded content in your app (such as app extensions, App Clips, or watchOS apps) are in sync with your app. Note that this doesn’t modify your source code or your archive; Xcode updates the build number in a staged copy of your app before packaging and uploading it to App Store Connect. (59826409)

Thanks, @edford.

We noticed this addition in the release notes, but quite honestly it only mentions CFBundleVersion that stands for the build number, there's nothing about CFBundleShortVersionString being also changed by the distribution assistant. If the assistant would change the version number of the main app, in case that is invalid, it would be reasonable IHMO, however changing the version number of all embedded content of an app doesn't seem to make much sense.

Would be great if the release notes were clear about that, in case it is an intentional behavior. I couldn't find anything specifically mentioning the new xcodebuild export option as well, which would be also great to have.

Unfortunately I didn't have the chance to check that WWDC session video, but thanks a lot for mentioning it. I'd expect though that the notes would give all clarity needed.

this SO answer shows a screenshot of how to disable it using the Xcode 13 UI

https://stackoverflow.com/questions/68237292/manage-version-and-build-number/69562078#69562078

This change brakes our framework's internal logic because of changing it's version.

In my case, option - manageAppVersionAndBuildNumber doesn't work in Jenkins flow ....

framework developer here - anyone know how to get back the framework's version in the cases of stubborn app developers at the company who refuse to set manageAppVersionAndBuildNumber to false?

Is there a way to disable it on xcode?

Need a way to disable it for frameworks. Any help here?

This is still happening in Xcode 14 where it's not just changing the app bundle's plist, but also every embedded framework's plist, which breaks various vendor SDKs that relying on reading the plist to share what version of their SDK is being use. Arguable as to whether that is best practice, but it does feel like this shouldn't touch anything other than the app bundle's plist and not change the values for any dynamic frameworks.

Is this a bug or change we should file something in Feedback Assistant for?

Was this behavior ever modified? We have third party vendor frameworks that seem to rely on reading its own plist to determine the version, and unless this Xcode feature is disabled or fixed so it doesn't rewrite dynamic framework plists, the behavior of the framework turns incorrect.

If you are still stuck in 2024, this fixed the problem for me: Under Target, Info, Bundle Version String (short), instead of a fixed version string, change it to $(MARKETING_VERSION).