iOS CFBundleVersion is created with invalid leading zeroes, which Apple then attempts to strip out.

[alanthomson]

When an iOS build is made, the builder automatically creates a CFBundleVersion using the format yyyy.mm.ddhhmm
Apple treats the 3 elements as numbers, and if one of those numbers starts with a zero they are stripping that leading zero.

So they interpret 2020.12.011744 as 2020.12.11744. This then causes builds to fail to update, because a mismatch is detected between then original CFBundleVersion inside the binary and the stripped version on the App Store.

See screenshot for example of how the bundle version using late November dates are correct, but early December is not.

If leading zeroes are removed prior to building, I believe that should resolve this issue.

[Shchvova]

Fixing it by prepending lucky 7 before the date.

[alanthomson]

I think it might need the 7 before the month as well, otherwise element 2 of the CFBundleVersion could have a leading zero in months 01-09 might have the same problem.

[Shchvova]

For sure. I have no idea why I thought it would be different for month.

[Zorfware]

I don't want to test this problem until next year, where the leading digits on both month and day will become single digit again, but I find it a problem that the dataformat is changed and becomes longer. A real fix would be to remove the the leading zeros before building to preserve existing logic and not change dataformat.