OpenTelemetry for native mobile apps

Mobile observability has a different trust boundary from a backend service. The app runs on a device you do not control, it moves between foreground and background, connectivity disappears, and every secret shipped in the binary should be considered recoverable.

That changes the setup, but not the goal. A tap or screen transition should be able to lead into a network request, a backend trace, a queue, a database call, or an agent run without losing the application and release context that started it.

Use the platform's OpenTelemetry implementation

For Swift/iOS, start with OpenTelemetry Swift and the instrumentation that fits the app. For Android, use the OpenTelemetry Android ecosystem rather than trying to make a server Java setup behave like a phone.

Initialize telemetry early enough to capture the important startup and network activity. Attach stable application identity, version, build, environment, and session context. Preserve screen or route information and error/performance signals when the platform instrumentation supports them.

Do not ship a privileged server key

A backend can keep an API key in a secret manager. An iOS IPA or Android APK/AAB cannot. Obfuscation is not a security boundary.

This rule also applies to browser JavaScript, React Native bundles, desktop clients, and any other software delivered to end users.

Propagate trace context into the backend

The mobile side becomes much more useful when the backend can continue the same trace. Instrument outbound HTTP or gRPC requests so the receiving service can extract trace context. That gives you a path like:

screen / user action
  -> mobile network request
    -> API service
      -> database / queue
      -> agent workflow
        -> model / tool
      -> downstream service

The mobile release/build stays visible at the top of the trace while server releases identify the code that handled the request later.

Account for lifecycle and offline periods

Phones are routinely suspended, backgrounded, disconnected, or killed. Mobile telemetry needs lifecycle-aware export and bounded buffering. Use the capabilities provided by the platform instrumentation instead of assuming every event can be sent immediately.

Do not let buffering become an unbounded local data store. Put limits on retained telemetry and avoid storing sensitive payloads just because the network is unavailable.

Swift/iOS and Android need slightly different context

On iOS, app version/build, session, screen/navigation, network calls, crashes/errors, and performance signals are the useful foundation. On Android, activity/fragment lifecycle, session, network state, startup, crashes/ANRs, and slow or frozen rendering can also be valuable when the selected instrumentation provides them.

Keep custom spans for product operations that matter, not every UI callback. A span named for a checkout confirmation or media upload is useful. A trace full of individual button-handler spans usually is not.

React Native has two instrumentation layers

React Native can expose both JavaScript and native telemetry. Decide which layer owns each signal so a single network request is not recorded twice. Keep shared session and trace identity, and prefer the native layer for lifecycle or performance information that JavaScript cannot see accurately.

Connect mobile to agentic work

Many user-facing AI features start on a phone but execute in a service or durable worker. Preserve the trace from the native request into the agent runtime. Then model calls, retrieval, MCP tools, and handoffs remain attached to the actual user interaction without putting prompt or private tool payloads into the mobile telemetry stream.

For a platform-oriented setup checklist, see the native/mobile agent guide.