Apm mobile

APM for Mobile -- Vendor Comparison

Instructions

"Mobile APM" overlaps with crash, RUM, and tracing. Picking one tool (or a small stack) depends on what you need to attribute -- user journeys, backend latency, or native crashes. Choose consciously; do not stack four overlapping SDKs.

1. The Competing Dimensions

• Coverage: crashes, ANR/hangs, app start, HTTP, custom transactions, session replay.
• Backend correlation: does it connect client transactions to server spans via OpenTelemetry / W3C / proprietary ids?
• Sampling flexibility: can you sample dynamically by release, user segment, error status?
• Privacy posture: EU data residency, masking defaults, CMP integration.
• Cost: per-session vs per-event, replay surcharge, retention tiers.
• SDK size and startup overhead: mobile-sensitive.

2. Vendor Capsule Comparison

Firebase Performance

• Strength: auto app-start, HTTP, custom traces; free under generous caps; integrates with Firebase Crashlytics and GA4.
• Weakness: no OTel-native propagation; limited custom trace flexibility; no session replay.
• Fit: apps already in the Firebase ecosystem, not needing backend trace correlation beyond its own dashboards.

FirebasePerformance.getInstance().isPerformanceCollectionEnabled = true
val trace = FirebasePerformance.getInstance().newTrace("home_feed_load")
trace.putMetric("items_returned", 42L)

Sentry Performance

• Strength: unified errors + transactions + replay; OTel-compatible; strong release health; mobile replay with mask-by-default.
• Weakness: metric pricing on high-volume apps; replay cost; some mobile auto-instrumentations still maturing.
• Fit: apps wanting one tool for crashes, perf, and replay with privacy defaults.

See sentry-mobile.

Datadog RUM Mobile

• Strength: first-class backend correlation with the rest of Datadog; rich mobile vitals (vitals, long tasks, frozen frames); session replay (recent); log/trace/metric unified.
• Weakness: enterprise pricing; heavier SDK; less focus on crash grouping than Sentry/Crashlytics.
• Fit: orgs standardized on Datadog for backend who want full-stack sessions.

Datadog.initialize(
    appContext: .init(),
    trackingConsent: .granted,
    configuration: Datadog.Configuration.builderUsing(
        rumApplicationID: "...", clientToken: "...", environment: "prod"
    ).trackURLSession(firstPartyHosts: ["api.example.com"]).build()
)

Embrace

• Strength: session-centric timeline; strong ANR and startup attribution; native network correlation.
• Weakness: smaller ecosystem; custom query language; more mobile-specific and less useful for full-stack teams.
• Fit: mobile-first companies with complex session diagnostics needs.

New Relic Mobile

• Strength: enterprise workflows; good MTTR with APM correlation to NR backends.
• Weakness: dated UI; heavier agent; EU data residency requires separate plan.
• Fit: existing New Relic shops.

3. OpenTelemetry as the Default

If you start greenfield, prefer OpenTelemetry for traces and metrics, then send to the vendor via OTLP. This keeps the wire format portable and lets you change vendors without re-instrumenting the app. See distributed-tracing-mobile.

4. Sampling and Cost Modelling

• Firebase Performance: free tier has daily trace caps per app -- do not over-instrument custom traces.
• Sentry: billed per transaction + replay; use tracesSampleRate = 0.15 and replaysSessionSampleRate <= 0.05.
• Datadog: billed per session + replay; use sessionSampleRate and sessionReplaySampleRate separately.
• Embrace: billed per MAU; less sampling flexibility, more inclusive.
• New Relic: billed per host/user; mobile licensing varies by contract.

Budget your monthly DAU * session/user * sample rate to estimate cost within 10% before rollout.

5. Stack Recommendations

• Small team, Firebase ecosystem: Crashlytics + Firebase Performance + GA4.
• Product-led startup, privacy-sensitive: Sentry (errors + perf + replay) + Amplitude or Mixpanel for product analytics.
• Datadog backend org: Datadog RUM Mobile + Datadog Logs/Metrics/APM, with Crashlytics retained if you want store-integrated crash reports.
• Regulated industries (health/fin): OTel + self-hosted collector -> your own Elastic/Grafana; vendor SDKs only with contractual data residency.

6. Mandatory Configuration Per Vendor

Whatever you choose:

1. Separate project per platform.
2. Consistent release identifier across crash, perf, logs.
3. Symbolication automation in CI (see symbolication).
4. Consent gating (see analytics-privacy).
5. Redactor between app code and SDK transport.
6. Dashboards per release and per device class.

7. Migration Playbook

Moving between vendors:

1. Run both SDKs in parallel for one release cycle (tolerate the extra weight temporarily).
2. Validate identical counts on crashes, transactions, sessions (within 5% tolerance).
3. Cut over alerts and dashboards before removing the old SDK.
4. Remove old SDK in the next release; keep symbols uploaded for the retention window so historical issues remain readable.

8. Red Flags

• Multiple APM SDKs ingesting the same data: you are double-paying and your numbers won't match.
• Vendor enabled before consent prompts on EU users.
• SDK init happens off the main thread before Application.onCreate completes: instability.
• Custom traces wrapping micro-operations (< 1 ms) -- noise, not signal.

9. Verification

• Record the SDK size impact on APK / IPA (./gradlew :app:analyzeReleaseBundle, xcrun size Build/Products/Release-iphoneos/MyApp.app).
• Measure cold-start before/after; reject any vendor that adds > 120 ms on mid-tier devices.
• Run a 48-hour soak on staging builds; review the vendor's dashboard to confirm data shape matches expectations.

10. Exit Strategy

• Keep instrumentation vendor-agnostic (OTel primitives).
• Log the same event to both vendors during a migration window.
• Store your own symbols archive so you can re-symbolicate historical crashes without the vendor.

Checklist

• Selected vendor matches app stage, stack, and budget.
• No duplicate SDKs ingest the same crash/perf data unintentionally.
• OTel is preferred for custom instrumentation; vendor SDK is a transport.
• Consent gating, redaction, and symbolication automation are in place regardless of vendor.
• Cold-start impact measured and within budget.
• Migration plan is documented with a parallel-run window.
• Cost projection validated against first-month DAU.