Repository navigation
CFBundleShortVersionString format #41
Description
Activity
Hey @Panda-ref, are you using TestFlight to distribute builds to your testers?
Yeah, fastlane into TestFlight.
Gets rejected due to CFBundleShortVersionString = 1.0.0-1 (not Int.Int.Int format).
Anyways there is that difference betweennpm fashionwith semversion support andiOS fashionwithout.
Wonder if we could move that semver suffix out of CFBundleShortVersionString to CFBundleVersion and leave justMAJOR.MINOR.PATCH.I was just thinking the same thing. One has to move from say
1.0.0to1.1.0-1or1.1.0-rc.1to be testing a new feature right? That would mean that we have already satisfied the CFBundleShortVersionString update and we can specify anything for CFBundleVersion and should be ok to submit.Still have to figure out what to do with CFBundleVersion when we do an actual
npm version minorbefore going to production.Didn't quite understand.
Npm semver implementation doesn't support actual semver suffixes yet, for now it's just numerical suffixes like-[0-255].
For prerelease testing of minor update (withnpm version preminor) we prepare artifact with actual package.json version1.1.0-0that isn't a valid CFBundleShortVersionString. To make it valid one has to change actual1.1.0-0to just1.1.0and somehow differ artifacts by changing CFBundleVersion with same version but that satisfies apple rules to1.1.0b1and not1.1.0b0.The final number in the suffix is the build version, which cannot be 0 and cannot exceed 255. When you release the new version of your app, remove the suffix.
After actual
npm version minorwe can remove suffix like1.1.0because1.1.0>1.1.0b1for apple's perspective i think, could be wrong. Or just dosemverUtils.parse(semverString)and usereleasefield of parsed object and add 1.Also there is limitation for those who start their app development with
0.0.1version due toThe build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero
The greatest part in it that you just can't have a package like
node-semverto fully read apple's mind. God i love them.No standardization among Apple teams it seems:
Mail 9.3 (3124)
System Preferences 14.0 (14.0)
Photos 1.5 (370.42.0)
OS X 10.11.4 (15E65)
Safari 9.1 (11601.5.17.1)Oh my, that's a whole bunch of quirks. Thanks for taking the time to research this.
Any news on this?
What if we truncated any last parts of the version to adhere to Apple standards. The problem is though, that Apple required a nonzero number after any letter, so we would have to throw an error to the user if he wrote something like
1.2.8-rcbecause he needs a number afterrc.
How about something like:npm version CFBundleVersion CFBundleShortVersionString 1.2.3 1.2.3 1.2.3 1.2.3-beta1 1.2.3b1 1.2.3 1.2.3-alpha11 1.2.3a11 1.2.3 1.2.3-rc throw missing number error Yes please. Either truncating it, or adding a [.pre] like 1.0.1.17
Hi guys, this is now fixed in v4.0.0 thanks to @DMcNamara! RNV will now only keep the MAJOR.MINOR.PATCH part of your npm version for iOS to satisfy Apple's spec. This means
CFBundleShortVersionStringwill remain the same as you make new pre-release versions. You can bumpCFBundleVersionto get them into TestFlight and later when submitting to the App Store.Check out #176 (comment) for more info.
Parsing and truncating pre-release identifiers seems pretty error-prone, but we'll continue exploring this in #86.
Hi @stovmascript, first of all thanks for your time to make this plugin.
I've found some difficulties with using "
npm versionfashion" for iOS.According to
https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-111349
It appears that Apple decided on October 21st 2015 that they don't like anything except period separated lists of at most three non-negative integers which breaks with the Cocoapods convention of -beta
and npm semver implementation as well. I love all the creative ways they've found to waste our time.
That means having conventional versioning for prereleases like
react-native-version will set
for prerelease versions, that isn't a valid CFBundleShortVersionString
In addition we have CI configured for those prerelease tags to automatically deploy to our testers via iTunes Connect which gets rejected because of invalid CFBundleShortVersionString.
So it looks like more appropriate strategy would be to move this prerelease suffix to CFBundleVersion.
Like stick with 1.0.0b1 for betas (prereleases) or something like that. But definitely both fields should be valid. Thanks in advance for your feedback.