Mobile observability overview

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.