[posthog]

Why

Three SDKs independently moved build-invariant context properties off every event and onto Application Installed / Application Updated in the same week, under the same rationale: the value can only change when the app binary is rebuilt, which is exactly when those events fire, so repeating it on every event costs storage for nothing. The application-lifecycle spec had no rule for this class of property, so nothing stopped the next SDK adding one to its common event context — which is what these three just undid.

Source SDK changes

SDK	PR	Property	Change
posthog-ios	#923	$app_build_xcode, $app_build_sdk	Added, on Installed / Updated only
posthog-flutter	#640, #651	$flutter_version	Added per-event in 5.52.0, then moved to Installed / Updated; dropped on web
posthog-react-native	posthog-js #5254	$react_native_version	Moved from every event to Installed / Updated

What changed

One requirement added to openspec/specs/application-lifecycle/spec.md, Build-invariant context properties:

• A property whose value changes only when the app binary is rebuilt — the wrapper runtime version, or the build toolchain — rides Application Installed and Application Updated, and is not added to the common event context.
• It is omitted when the platform reports no value for it.
• Where the runtime has no lifecycle events, or lifecycle capture is disabled, it is not sent at all rather than falling back to every event. This follows Flutter's choice to drop $flutter_version entirely on web.
• $lib, $lib_version, $app_version and $app_build are exempt and stay on every event. They are build-invariant by the same test, but ingestion, person properties and existing insights read them on arbitrary events.

The install/update step in the Behavior section gets a matching line. Proposed, applied, and archived on this branch under openspec/changes/archive/2026-10-09-send-build-invariant-properties-on-lifecycle-events/.

Uncertainty

• The rule keys off a definition, not a name list. "Changes only when the app binary is rebuilt" is meant to keep covering whatever the next SDK adds in this shape. If the preference is to enumerate property names instead, this is the wrong shape and worth saying so.
• The exemption list is a judgment call. $lib_version and $app_version are build-invariant too; they are carved out because moving them would be a much larger break than the one these SDKs made. That boundary is stated, not derived from any SDK change.
• No acceptance scenario was added. The executable Gherkin binds to concrete property names, and the property differs per SDK, with no harness step today for "this platform's build-invariant property". The spec scenarios state the rule in prose over a worked example. A per-adapter harness step would be a reasonable follow-up.
• Android, Unity and KMP conform only because they send no such property at all; none of them was changed to match.

Validation

openspec validate --specs --strict is unchanged from main (33 passed / 31 pre-existing long-requirement warnings), and the change validated clean before archiving. These are specification checks, not executed SDK conformance tests.

---

Created with PostHog Desktop

🤖 Generated with Claude Code

[marandaneto]

The code looks good; no qualifying findings. Verdict: correct.