fix(react-native): key the release on Info.plist, not the build settings - #4618
Closed
ablaszkiewicz wants to merge 1 commit into
Closed
fix(react-native): key the release on Info.plist, not the build settings#4618ablaszkiewicz wants to merge 1 commit into
ablaszkiewicz wants to merge 1 commit into
Conversation
The SDK reports $app_version and $app_build from the app's Info.plist. posthog-xcode.sh passed Xcode's MARKETING_VERSION and CURRENT_PROJECT_VERSION instead. Those are only the usual source for the plist keys: Expo writes literal versions into Info.plist and leaves the build settings at the template default of 1.0, so a real build created its release as com.example.app@1.0+1 while the app reported 1.0.0. The release did not describe the app that shipped. Read the plist that ships and fall back to the build setting when it holds an unexpanded reference to one, which is how a bare React Native app writes it. Found by building the Expo example end to end on the simulator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Contributor
🦔 ReviewHog reviewed this pull requestNothing worth raising this time, so here's a calming picture instead:
|
Contributor
|
Size Change: 0 B Total Size: 20 MB ℹ️ View Unchanged
|
ablaszkiewicz
marked this pull request as ready for review
August 24, 2026 11:11
Member
|
dupe #4602 ? |
Contributor
Prompt To Fix All With AI### Issue 1
packages/react-native/tooling/posthog-xcode.sh:139-141
**Custom plist substitutions are discarded**
When `CFBundleShortVersionString` or `CFBundleVersion` references a custom or compound Xcode setting such as `$(APP_VERSION)`, this branch discards it and falls back specifically to `MARKETING_VERSION` or `CURRENT_PROJECT_VERSION`, causing the uploaded release coordinates to differ from the processed values reported by the runtime SDK.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(react-native): key the release on In..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+139
to
+141
| case "$posthog_plist_result" in | ||
| *'$('*) return 0 ;; | ||
| esac |
Contributor
There was a problem hiding this comment.
When CFBundleShortVersionString or CFBundleVersion references a custom or compound Xcode setting such as $(APP_VERSION), this branch discards it and falls back specifically to MARKETING_VERSION or CURRENT_PROJECT_VERSION, causing the uploaded release coordinates to differ from the processed values reported by the runtime SDK.
Knowledge Base Used: React Native SDK
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/react-native/tooling/posthog-xcode.sh
Line: 139-141
Comment:
**Custom plist substitutions are discarded**
When `CFBundleShortVersionString` or `CFBundleVersion` references a custom or compound Xcode setting such as `$(APP_VERSION)`, this branch discards it and falls back specifically to `MARKETING_VERSION` or `CURRENT_PROJECT_VERSION`, causing the uploaded release coordinates to differ from the processed values reported by the runtime SDK.
**Knowledge Base Used:** [React Native SDK](https://app.greptile.com/posthog-org-19734/-/custom-context/knowledge-base/posthog/posthog-js/-/docs/react-native-sdk.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
This was referenced Aug 24, 2026
Contributor
Author
|
@marandaneto yeah that's duplicated. Closing mine! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
An Expo app's release in PostHog does not describe the app that shipped. A build whose app reports version
1.0.0creates its release as1.0.The SDK reports
$app_versionand$app_buildfrom the app'sInfo.plist.posthog-xcode.shpassed Xcode'sMARKETING_VERSIONandCURRENT_PROJECT_VERSIONinstead. Those are only the usual source for those plist keys. Expo writes literal versions intoInfo.plistand leaves the build settings at the Xcode template default of1.0, so the two disagree.Seen on a real simulator build of a stock Expo app:
The release row landed as
com.posthog.example.rnexpo@1.0+1.A bare React Native app writes
$(MARKETING_VERSION)into its plist instead, so it never diverged and is unaffected.Changes
Info.plist.$(MARKETING_VERSION)or has no value at all.PRODUCT_BUNDLE_IDENTIFIER.Info.plistreferences it rather than repeating it, and the SDK reports the resolved value.Note
An existing Expo project on the default release mode will start creating release rows under its real version. Releases already created under the old version are untouched, so expect a new row rather than a changed one.
The test file gains a helper that runs the wrapper against a posthog-cli stub and records its arguments. That helper is new surface, not a change to existing tests.
Release info Sub-libraries affected
Libraries affected
Checklist
How did you test this code?
Found by building the
react-native-expoexample in PostHog/error-tracking-examples end to end on the iOS simulator, not by reading the code. Before this change the build createdcom.posthog.example.rnexpo@1.0+1while the app on screen reported1.0.0. After it, the same build creates@1.0.0+1.Three new cases, each running the real script against a posthog-cli stub:
keys the release on Info.plist rather than the build settings— the regression itself, a literal plist version losing toMARKETING_VERSION.falls back to the build settings when Info.plist only references them— a bare React Native app breaking, which is the larger installed base.falls back to the build settings when there is no Info.plist at all— the same, for a project that sets noINFOPLIST_FILE.Not checked: an Android build, which does not use this script, and a physical iOS device.
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Authored with Claude Code (Claude Opus 5). Skills invoked:
/writing-tests,/writing-code-comments,/writing-pr-descriptions.Split out of #4617, which stacks on this branch. That PR adds experimental event release mode, where this bug stops being cosmetic: the server rebuilds the release key from the event's app metadata, matches nothing, and every exception reports no release. The fix stands on its own, so it is here rather than buried in the feature.
Nothing in this PR draws on non-public material.