What are you trying to achieve?

I would like to propose a minimal set of semantic conventions for replay-adjacent telemetry in native mobile applications (iOS and Android).

The goal is not to standardize full session replay (such as screenshots, DOM/view hierarchy capture, or replay players), but to define portable, log-based interaction telemetry that enables replay-style debugging across vendors.

Specifically, I want to align on how to represent:

• user interactions (tap, click, gesture, scroll)
• screen/view context
• lifecycle transitions
• rendering quality signals (e.g. jank, frozen frames)
• session correlation (session.id)

Existing basis already includes app.screen.click, app.widget.click, and app.jank; the remaining gap is how to compose these with additional mobile interaction types, lifecycle, and session.id correlation for replay-style debugging.

What did you expect to see?

I expected to find either:

1. Existing semantic conventions that cover replay-adjacent mobile interaction telemetry in a consistent way, or
2. An ongoing proposal that defines how native mobile interaction events should be modeled for replay-style debugging.

While there are related pieces (RUM discussions, session semantics, mobile/app events, Android interaction instrumentation), there does not appear to be a unified or minimal model that connects these into a coherent approach.

Additional context.

This proposal intentionally focuses on a narrow, incremental step:

• Use log-based events (aligned with current direction away from span events)
• Reuse existing namespaces where possible (app.*, device.*, session.*)
• Avoid introducing a new signal or "replay" category
• Exclude sensitive or heavy data (no screenshots, no full view hierarchy, no raw input values)

The goal is to define a minimal, privacy-safe, and portable event model that can serve as a foundation for replay-style debugging, without standardizing storage, transport, or playback.

Related areas:

• Client-side / RUM discussions
• Android interaction and gesture instrumentation
• Swift/iOS gaps in interaction and lifecycle coverage

If this direction makes sense, I can follow up with:

• a concrete draft of event names and attributes
• Android prototype instrumentation alignment
• Swift/iOS parity proposal

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}