Skip to content

feat(mobile): attach app version to all custom events#2404

Merged
Gilbert09 merged 1 commit into
mainfrom
posthog-code/mobile-app-version-super-property
May 28, 2026
Merged

feat(mobile): attach app version to all custom events#2404
Gilbert09 merged 1 commit into
mainfrom
posthog-code/mobile-app-version-super-property

Conversation

@Gilbert09
Copy link
Copy Markdown
Member

Summary

  • Mirrors desktop PR feat(analytics): attach app version to all custom events #2372 on the React Native app: register app_version as a PostHog super property at boot so every captured event (autocapture + manual screen events) carries the shipped app version, with no per-call wiring required.
  • Version is resolved from expo-application.nativeApplicationVersion and falls back to Constants.expoConfig.version from app.json, so OTA-updated binaries report their real shipped version while Expo Go / web builds fall back to the config value.
  • Hook is wired into RootLayoutNav next to useScreenTracking, so it runs inside PostHogProvider once the client is ready.

Test plan

  • pnpm --filter @posthog/mobile test — 112 tests pass, including the new src/lib/posthog.test.ts (7 cases covering version resolution, no-op paths, and super-property registration).
  • Manual smoke: build the app, capture any event, and confirm app_version is present in PostHog event properties.

Mirrors #2372 on the React Native app: register `app_version`
as a PostHog super property at boot so every captured event (including
autocapture and manual screen events) carries the shipped app version.

The version is resolved from `expo-application.nativeApplicationVersion`
with a fallback to `Constants.expoConfig.version` from `app.json`, so
OTA-updated binaries still report their real shipped version while
Expo Go / web builds continue to fall back to the config value.

Generated-By: PostHog Code
Task-Id: d2c2384c-852a-4130-a07e-476395746cc1
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 28, 2026

Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/mobile/src/lib/posthog.test.ts:40-67
**Prefer parameterised tests for `getAppVersion`**

The three `getAppVersion` cases share an identical structure — set `nativeApplicationVersion`, set `expoConfig`, call `getAppVersion`, assert the result. The project convention is to consolidate these into a single `it.each` table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in `registerAppVersion`.

Reviews (1): Last reviewed commit: "feat(mobile): attach app version to all ..." | Re-trigger Greptile

Comment on lines +40 to +67
describe("getAppVersion", () => {
it("prefers the native application version when present", async () => {
expoApplication.nativeApplicationVersion = "9.8.7";
expoConstants.expoConfig = { version: "0.0.0-test" };

const { getAppVersion } = await import("./posthog");

expect(getAppVersion()).toBe("9.8.7");
});

it("falls back to the Expo config version when no native version is available", async () => {
expoApplication.nativeApplicationVersion = null;
expoConstants.expoConfig = { version: "1.2.3" };

const { getAppVersion } = await import("./posthog");

expect(getAppVersion()).toBe("1.2.3");
});

it("returns null when neither source has a version", async () => {
expoApplication.nativeApplicationVersion = null;
expoConstants.expoConfig = null;

const { getAppVersion } = await import("./posthog");

expect(getAppVersion()).toBeNull();
});
});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Prefer parameterised tests for getAppVersion

The three getAppVersion cases share an identical structure — set nativeApplicationVersion, set expoConfig, call getAppVersion, assert the result. The project convention is to consolidate these into a single it.each table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in registerAppVersion.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/mobile/src/lib/posthog.test.ts
Line: 40-67

Comment:
**Prefer parameterised tests for `getAppVersion`**

The three `getAppVersion` cases share an identical structure — set `nativeApplicationVersion`, set `expoConfig`, call `getAppVersion`, assert the result. The project convention is to consolidate these into a single `it.each` table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in `registerAppVersion`.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

@Gilbert09 Gilbert09 added the Stamphog This will request an autostamp by stamphog on small changes label May 28, 2026
Copy link
Copy Markdown

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean additive feature with tests. The only review comment is a bot style suggestion (prefer parameterised tests) — not a blocking issue.

@Gilbert09 Gilbert09 merged commit bd32626 into main May 28, 2026
17 checks passed
@Gilbert09 Gilbert09 deleted the posthog-code/mobile-app-version-super-property branch May 28, 2026 14:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Stamphog This will request an autostamp by stamphog on small changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant