12

Do I have to increment the the CFBundleVersion in my extension's Info.plist to ensure it overwrites existing ones? Or if doing so in the main app's Info.plist is enough?

I'm working on today extension, but I guess the question applies to all embedded binaries.

admdrew
  • 3,790
  • 4
  • 27
  • 39
Joseph Lin
  • 3,324
  • 1
  • 29
  • 39
  • I don't think so, extensions are stored within the main app and will be overwritten when you replace the app with a new one. But I could be wrong. For watch extensions especially, since those are presumably copied over to the watch? – Abhi Beckert Jan 14 '15 at 22:32
  • Watch extension is an interesting point. I guess we'll find out soon! – Joseph Lin Jan 22 '15 at 21:57
  • Check this answer. https://stackoverflow.com/a/33421662/5790492 – Nike Kov Jul 22 '19 at 15:27

6 Answers6

13

I think Apple would actually prefer App Extensions to use the same bundle version as the app they are contained in. This is the email I have been getting from iTunes Connect with every submission:

We have discovered one or more issues with your recent delivery for "Awesome App". Your delivery was successful, but you may wish to correct the following issues in your next delivery:

CFBundleVersion Mismatch - The CFBundleVersion value '94' of extension 'Awesome App.app/PlugIns/Awesome App Today Extension.appex' does not match the CFBundleVersion value '99' of its containing iOS application 'Awesome App.app'.

CFBundleShortVersionString Mismatch - The CFBundleShortVersionString value '1.0' of extension 'Awesome App.app/PlugIns/Awesome App Today Extension.appex' does not match the CFBundleShortVersionString value '1.3.0' of its containing iOS application 'Awesome App.app'.

After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.

I can ignore these warnings and the build passes review but this is either a bug in iTunes Connect or the numbers should be the same. This doesn't actually make sense since the extension won't necessarily be updated at the same rate of the app. Anyways

Daniel Galasko
  • 23,617
  • 8
  • 77
  • 97
  • Thanks. I'm also starting to get similar warnings (locally) when building my watch extension, but the weird thing is my today extension doesn't give me the same warning. So like you said, it's either a bug or a new requirement, and it is a weird one. – Joseph Lin May 24 '15 at 19:19
  • I also got that but when I match the versions and upload again, it's said redundant binary upload. – Myat Min Soe May 15 '18 at 18:03
  • In my case version is the same in extension and app target under General Tab. But I found in the Build setting, under Versioning(Current Project Version) Debug has 1 and release has 2 value. So, due to this mismatch version, I got a warning. – Gurjinder Singh Nov 22 '21 at 15:15
7

It's not documented either way, so you should update it. It might not matter, but you can't be certain, and even if it's not necessary now it might become necessary later on. As an undocumented detail, it could change without warning.

It's also just good software development practice. The embedded version number should change whenever the extension changes, even if iOS doesn't do anything with the information.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • 3
    Thanks Tom. I can confirm that the embedded extension always gets installed even if the version is not incremented, but like you said it's undocumented so better safe than sorry. – Joseph Lin Jan 22 '15 at 21:57
  • @Tom Harrington, I have added extension to my app, is there away that my extension app bundle version inherit from main app bundle. – Steven Jun 19 '20 at 22:03
5

To avoid the warning from iTunes Connect, I just bump all the version numbers from my "Bump build number" build script of my main app:

if [ "$BUMP_BUILD_NUMBER" = "1" ] ; then
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${INFOPLIST_FILE}"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "/Users/name/project/ios/Siri/Info.plist"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "/Users/name/project/ios/SiriUI/Info.plist"
fi
``
atomkirk
  • 3,701
  • 27
  • 30
  • 2
    The best answer! Only one suggestion: use `$SRCROOT/ExtensionName/Info.plist` instead of absolute path. – imike Apr 18 '19 at 08:57
1

I've just been looking for the same answer, I've just recently updated an app and found that upon upload, I was presented with a warning regarding the extensions and the version numbers mismatching with the app or something, (can't remember the specific wording) - hence why I am here!

"App Extensions and their containing apps must use the same build number (CFBundleVersion) and version number (CFBundleShortVersionString) as used in the other targets in the Xcode project."

Not much information but it's clear - the versions of App extensions and WatchKit extensions must match the same version as the application they are in.

Seem's a bit pointless even giving us an option to specify separate version numbers, no?

SagarScript
  • 1,145
  • 11
  • 15
1

Building on @atomkirk's answer, in my apps the version and build numbers are set in the xcodeproject. So instead of I need to use xcodebuild to pull out the relevant values:

buildNumber=$(xcodebuild -showBuildSettings -project App.xcodeproj | pcregrep -o1 "PROJECT_VERSION = ([0-9a-f\-]+)")
marketingVersion=$(xcodebuild -showBuildSettings -project App.xcodeproj | pcregrep -o1 "MARKETING_VERSION = ([0-9a-f\-.]+)")

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$SRCROOT/Share Extension/Info.plist"
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $marketingVersion" "$SRCROOT/Share Extension/Info.plist"
weiran
  • 725
  • 1
  • 8
  • 18
0

Yeah, extensions bundle versions (bundle version && bundle version string, short) have to mismatch to main app build && version.

so, bundle version extension = main app build

bundle version string, short = main app version

oskarko
  • 3,382
  • 1
  • 26
  • 26