Problem
The iOS and React Native upload wrappers now need the same release metadata that the SDK reports from Bundle.main.infoDictionary:
Both wrappers read CFBundleShortVersionString and CFBundleVersion from INFOPLIST_FILE, resolve simple Xcode build-setting references from the environment, and fall back to MARKETING_VERSION and CURRENT_PROJECT_VERSION. Keeping separate shell implementations risks attribution differences between native symbols and source maps.
Proposed change
Add an --info-plist <path> option to the posthog-cli release arguments used by dsym upload and Hermes source-map commands.
The CLI should:
- read the bundle identifier, short version, and build number from the plist;
- resolve exact Xcode build-setting references such as
$(APP_VERSION) and ${BUILD_NUMBER} from the environment;
- let explicit
--release-name, --release-version, and --build arguments take precedence;
- return no value for unresolved or compound substitutions so callers can retain their existing fallback behavior.
This would let both upload wrappers pass the plist path instead of maintaining duplicate release-resolution logic.
Problem
The iOS and React Native upload wrappers now need the same release metadata that the SDK reports from
Bundle.main.infoDictionary:Both wrappers read
CFBundleShortVersionStringandCFBundleVersionfromINFOPLIST_FILE, resolve simple Xcode build-setting references from the environment, and fall back toMARKETING_VERSIONandCURRENT_PROJECT_VERSION. Keeping separate shell implementations risks attribution differences between native symbols and source maps.Proposed change
Add an
--info-plist <path>option to the posthog-cli release arguments used bydsym uploadand Hermes source-map commands.The CLI should:
$(APP_VERSION)and${BUILD_NUMBER}from the environment;--release-name,--release-version, and--buildarguments take precedence;This would let both upload wrappers pass the plist path instead of maintaining duplicate release-resolution logic.