You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to this post Capgo will by default use the CURRENT_PROJECT_VERSION key on iOS and versionName key on Android to detect the native version of the application. This perplexes me as it does not align with what I know about mobile app development versioning. In the below table I will show which keys from iOS match with which keys on the android side.
iOS
Android
Common Usage
Example
CFBundleVersion = CURRENT_PROJECT_VERSION
versionCode
internal build number (integer)
841
CFBundleShortVersionString = MARKETING_VERSION
versionName
public version (semver)
3.2.5
First off, you technically shouldn't really be using CURRENT_PROJECT_VERSION, you should be looking for CFBundleVersion or CFBundleShortVersionString as these are the values stored in the info.plist and are retrievable at runtime. Source 1, Source 2.
Secondly, here are some definitions from Apple and Google:
versionName: "A string used as the version number shown to users. This setting can be specified as a raw string or as a reference to a string resource."
versionCode: "A positive integer used as an internal version number."
CFBundleVersion: "This key is required by the App Store and is used throughout the system to identify the version of the build."
Note how versionName and CFBundleShortVersionString are both publicly visible, and represent the semantic version of the app shown to the users. While versionCode and CFBundleVersion are both internal build identification numbers. Hell, for android versionCode can only be an integer! It seems to me like you guys have mismatched the keys. You should be looking at the CFBundleShortVersionString to check for the iOS version, not the CFBundleVersion?
So I guess my questions are:
Is the blog just outdated, and has this already been fixed?
If not, what are the available workarounds so that I can still use Capgo?
Am I just very stupid and completely misunderstanding something? 😅
The text was updated successfully, but these errors were encountered:
Just to give an update, it seems like the CFBundleShortVersionString is actually being used. I tested it out and capgo will correctly target based on the MARKETING_VERSION / CFBundleShortVersionString and not on the CURRENT_PROJECT_VERSION. So it seems like the blog/documentation surrounding this topic is just incorrect. Would it be possible to update this documentation?
Describe the bug/issue
Hi, I am currently looking at using Capgo however I am having trouble understanding this blog post: https://capgo.app/blog/how-version-work-in-capgo/#support
According to this post Capgo will by default use the
CURRENT_PROJECT_VERSION
key on iOS andversionName
key on Android to detect the native version of the application. This perplexes me as it does not align with what I know about mobile app development versioning. In the below table I will show which keys from iOS match with which keys on the android side.CFBundleVersion
=CURRENT_PROJECT_VERSION
versionCode
integer
)CFBundleShortVersionString
=MARKETING_VERSION
versionName
semver
)First off, you technically shouldn't really be using
CURRENT_PROJECT_VERSION
, you should be looking forCFBundleVersion
orCFBundleShortVersionString
as these are the values stored in theinfo.plist
and are retrievable at runtime. Source 1, Source 2.Secondly, here are some definitions from Apple and Google:
Note how
versionName
andCFBundleShortVersionString
are both publicly visible, and represent the semantic version of the app shown to the users. WhileversionCode
andCFBundleVersion
are both internal build identification numbers. Hell, for androidversionCode
can only be an integer! It seems to me like you guys have mismatched the keys. You should be looking at theCFBundleShortVersionString
to check for the iOS version, not theCFBundleVersion
?So I guess my questions are:
The text was updated successfully, but these errors were encountered: