version number

No, it won't make a difference. I think the "1.0" is mainly for historical reasons. Ever since people started numbering software releases Way Back When, the initial public release version of anything is traditionally "1.0".

The plist key is CFBundleShortVersionString which gives a hint - it's treated as a string when displayed to the user, so no it will not be truncated. You could use 1.0.0.0 if you like. But 1.0 is normal.

An aside - there is actually a downside to using 1.0, if my memory serves me correctly. In the sandbox, if you go to verify an application receipt, the original purchase version is always 1.0. So if you ever need to do something differently for people who purchased 1.0 vs. 1.1 or something (maybe you switched to freemium in 1.1), it is difficult to test. But that's an edge case.

From the iTC Developer Guide:

https://developer.apple.com/library/prerelease/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Appendices/Properties.html#//apple_ref/doc/uid/TP40011225-CH26-SW1

Version Number(required)

The version number of the app you’re adding. This is the version number that will display on the App Store for customers. Numbering should follow typical software versioning conventions (for example, 1.0 , 1.0.1 , 1.1 ).

When you create a new app or platform the version number will always default to 1.0, but this can be changed before you submit the app for review.

Important: Make sure this App Store version number matches the version number set in the bundle. If these don’t match, upload errors for later updates might occur.

Interestingly, this sandbox issue (and the original_application _version in any receipt) applies to the "Build" number (i.e. the CFBundleVersion) not the "Version" number (i.e. the CFBundleShortVersionString). Many don't realize that!

Because these are strings, there is a difference between "1.0" and "1". And it makes no 'difference' what you call it - until you want to signal to iTunes Connect or the user that there is a 'new' version. Avoid "1.0" as a developer and as a user. Start with "1.1" and keep the "build" the same as the "version" but with an extra .X at the end. When you submit new versions (i.e. the soon to be version 1.2) submit new development builds with Version number "1.2" and Build numbers 1.2.1 and 1.2.2 all the way up to the final perfect 1.2.36 which you submit for approval with a Version number 1.2.

Have uploaded 1.1.0001(1) build 1st.Later uploaded 1.1.1(2) build both comes falls under version 1.1.001 series only ..Does apple truncate it and consider 1.1.1 as 1.1.0001 ?

I have the same issue. In AppstoreConnect there is a version 1.029 and now when I'm trying to upload a new version 1.1.0 it says Asset validation failed (90062) This bundle is invalid. The value for key CFBundleShortVersionString [1.1.0] in the Info.plist file must contain a higher version than that of the previously approved version [1.29]. Please find more information about CFBundleShortVersionString at https:// developer.apple.com documentation bundleresources/information_property_list/ cfbundleshortversionstring.

But there is no version 1.29. I have only verion 1.029. Does apple truncate it and consider 1.029 as 1.29 ?

I have only verion 1.029. Does apple truncate it and consider 1.029 as 1.29 ?

Yes, exactly. The individual segments in a version string are treated as integers and leading zeroes are meaningless. A two-segment version string may look like a decimal fraction but it’s not.