mobile-observability-overview

name	mobile-observability-overview
description	Mobile observability - metrics, traces, logs, and events within the constraints of battery, network, and storage. Use when defining what to collect, how to sample, and how to pipe signals to analytics and APM tools.

Mobile Observability Overview

Instructions

Mobile observability is not "backend observability, but smaller". Devices are constrained: battery, flaky networks, storage quotas, privacy boundaries, and the impossibility of hotfixing. Collect what you need, sample aggressively, and never ship a telemetry SDK that costs more than it informs.

1. The Four Signals, Mobile-Flavored

Signal	Why	Constraints
Metrics	Numeric trends (startup time, crash-free, conversion)	Low volume, aggregate client-side
Traces	Causal chain across calls (cold start, feature flow)	Sample heavily; one trace per flow
Logs	Event narrative	Expensive to ship; breadcrumbs are preferable
Events (analytics)	Product decisions	Deduplicate and batch; respect consent

2. What to Measure

Minimum set every mobile app should emit:

• Cold start time to first frame, to first interactive.
• Warm start time.
• Frame drops / jank on key screens.
• Network: p50/p95 latency per endpoint, error rate per endpoint, retry counts.
• Crash-free sessions / users (see crash-reporting-strategy).
• ANRs (Android), hangs (iOS).
• Battery drain signals via OS tooling; not a per-event metric.
• Sync: outbox length, drain success rate, conflict rate.
• Funnel events: sign-in started/completed, checkout stages, key feature start/complete.

3. Cold Start Budget

• Target under 2s to first meaningful paint on mid-range devices.
• Measure with MetricKit on iOS and Macrobenchmark / StartupTracing on Android.
• Budget: every new SDK adds 50-200ms; every synchronous disk read in Application startup adds 20-100ms.

// Android: AppStartup + Firebase Performance
class PerformanceInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        FirebasePerformance.getInstance().isPerformanceCollectionEnabled = true
    }
    override fun dependencies(): List<Class<out Initializer<*>>> = emptyList()
}

// iOS: MetricKit
class MetricsObserver: NSObject, MXMetricManagerSubscriber {
    func didReceive(_ payloads: [MXMetricPayload]) {
        for p in payloads { Metrics.send("launch.time", p.applicationLaunchMetrics?.histogrammedTimeToFirstDraw) }
    }
}
MXMetricManager.shared.add(MetricsObserver.shared)

4. Tracing

Use tracing for end-to-end flows that span UI, local storage, and network. Typical traces:

• Cold start: process start -> splash -> first screen render.
• Sign-in: tap -> auth API -> token exchange -> first authed screen.
• Checkout: cart -> address -> payment -> confirmation.

Keep per-trace spans shallow (under 20). Sample heavily (5-10% on production, 100% in dev/staging). Attach trace IDs to logs for correlation.

5. Logs vs Breadcrumbs

• Ship breadcrumbs to the crash reporter; they travel with the next crash.
• Do not stream every log to a backend. It burns battery and bandwidth.
• For debugging in the field, ship a log export feature that bundles recent logs with the user's consent and a support ticket.

6. Analytics Events

• Maintain a spec (JSON schema) for every event: name, required properties, versioning.
• Gate event emission on consent where legally required (GDPR, CCPA).
• Deduplicate: retry-safe events carry a client event ID; the pipeline dedupes.
• Batch and flush on:
  • Network available + above threshold N events.
  • App backgrounding (with a short budget).
  • Foreground recovery after offline.

// React Native - simple batcher
const queue: AnalyticsEvent[] = [];
function track(event: AnalyticsEvent) {
  queue.push({ ...event, id: uuid(), ts: Date.now() });
  if (queue.length >= 20) flush();
}
AppState.addEventListener('change', (s) => { if (s === 'background') flush(); });

7. Privacy and Consent

• Never send PII in telemetry. Hash stable IDs; do not send email, name, phone.
• Respect App Tracking Transparency on iOS for anything that qualifies as tracking.
• Respect Play Data Safety declarations; the label must match what you actually collect.
• Provide in-app opt-out for analytics/crash reporting. Persist the choice across reinstalls if legally required (keychain on iOS).
• Do not store telemetry buffers in backups that might sync to iCloud/Drive with PII.

8. Sampling and Cost

• Client-side sampling: traces and non-critical metrics at 1-10%. Scale with user base.
• Server-side backstop: pipeline rejects over-quota events to keep costs sane.
• Aggregate on-device where possible (histograms over events) and send summaries.

9. Dashboards and Alerts

• One dashboard per release showing: crash-free sessions, key funnel, top endpoints, cold start.
• Alerts tied to SLOs, not raw metrics.
• Release-aware: the alert knows which version is rolling out and compares cohorts.

10. Tool Menu

• Firebase Performance + Crashlytics: free, baseline.
• Sentry: traces + release health + errors + logs.
• Datadog RUM, New Relic Mobile, Dynatrace: enterprise APM.
• PostHog, Amplitude, Mixpanel: product analytics.
• OpenTelemetry for mobile: growing; useful if your backend is OTel-native.

Do not stack five SDKs. Inventory every one against privacy labels and startup cost.

11. Anti-Patterns

• Logging every function call "just in case". Data volume drowns the signal.
• Streaming real-time logs from production clients. Use breadcrumbs and support bundles.
• Sending full URLs with query strings containing secrets.
• Collecting precise location for analytics. Truncate or avoid.
• Not versioning event schemas. Breaking downstream consumers silently.
• Letting the analytics backlog grow unbounded on disk.

Checklist

• Core metrics (cold start, jank, crash-free, network p95) are collected per release.
• Tracing is set up for critical flows with sane sampling.
• Analytics events follow a versioned schema with a single spec.
• Consent gates telemetry where legally required.
• No PII or secrets travel in telemetry.
• Breadcrumbs replace always-on log streaming.
• Event batches flush on backgrounding and on network recovery.
• Dashboards are release-aware with cohort comparison.
• Telemetry SDK count is audited against privacy labels.
• Per-endpoint error and latency signals feed rollout halt criteria.