CFBundleShortVersionString format

[Panda-ref]

CFBundleShortVersionString format

[stovmascript]

Hey @Panda-ref, are you using TestFlight to distribute builds to your testers?

[Panda-ref]

Yeah, fastlane into TestFlight.
Gets rejected due to CFBundleShortVersionString = 1.0.0-1 (not Int.Int.Int format).
Anyways there is that difference between npm fashion with semversion support and iOS fashion without.
Wonder if we could move that semver suffix out of CFBundleShortVersionString to CFBundleVersion and leave just MAJOR.MINOR.PATCH.

[stovmascript]

I was just thinking the same thing. One has to move from say 1.0.0 to 1.1.0-1 or 1.1.0-rc.1 to 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 minor before going to production.

[Panda-ref]

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 (with npm version preminor) we prepare artifact with actual package.json version 1.1.0-0 that isn't a valid CFBundleShortVersionString. To make it valid one has to change actual 1.1.0-0 to just 1.1.0 and somehow differ artifacts by changing CFBundleVersion with same version but that satisfies apple rules to 1.1.0b1 and not 1.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 minor we can remove suffix like 1.1.0 because 1.1.0 > 1.1.0b1 for apple's perspective i think, could be wrong. Or just do semverUtils.parse(semverString) and use release field of parsed object and add 1.

Also there is limitation for those who start their app development with 0.0.1 version due to

The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero

[Panda-ref]

The greatest part in it that you just can't have a package like node-semver to fully read apple's mind. God i love them.

[Panda-ref]

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)

[stovmascript]

Oh my, that's a whole bunch of quirks. Thanks for taking the time to research this.

[JReinhold]

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-rc because he needs a number after rc.
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

[RWOverdijk]

Yes please. Either truncating it, or adding a [.pre] like 1.0.1.17

[stovmascript]

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 CFBundleShortVersionString will remain the same as you make new pre-release versions. You can bump CFBundleVersion to 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.