Real User Monitoring (RUM) Setup for Mobile Apps: Why You Need It
Imagine this: a user on a Xiaomi Redmi Note 9 complains that the product list screen lags. Synthetic monitoring shows a perfect 60 FPS, but on LTE in their region, there's a network timeout at 8 seconds. Without RUM, you only find out from Play Market reviews. RUM captures every UI stutter, every ANR, every network error. Our experience shows: 30% of critical bugs are invisible in synthetic tests. Implementing RUM across 50+ projects cuts diagnostic time by 3x and saves up to $1500/month by quickly pinpointing bottlenecks.
The difference between RUM and synthetic monitoring
RUM collects data from real devices, while synthetic monitoring runs in a controlled environment. Synthetic monitoring won't show that the payment screen on a Huawei P40 lags due to overdraw in a FrameLayout. RUM captures every event: View, Action, Resource, Error, Long Task. Among these, Long Task is the most diagnostically valuable metric. Datadog RUM docs (Datadog RUM docs) state that over 50% of performance incidents are discovered through Long Tasks.
What data does RUM collect?
Standard event set in mobile RUM:
- View — screen transitions (open, close, duration)
- Action — tap, swipe, scroll, LongPress
- Resource — HTTP request: URL, method, status, size, latency
- Error — handled exception, unhandled exception, ANR, crash
- Long Task — operation on main thread > 100ms (Android) / main runloop > 16ms (iOS)
Of all events, the most diagnostically valuable is Long Task correlated with View. If a 250ms Long Task occurs during the payment screen transition for 15% of users, that's a concrete performance bug, not a vague "it sometimes lags."
Why Long Task is the key indicator
Long Task directly indicates UI blocking. For example, on one project after RUM integration, we discovered that loading the order list on Android performed a heavy sort on the main thread (Long Task 400ms). The fix: move the sort to a coroutine. Without RUM, this issue would have gone unnoticed.
RUM tool comparison
| Tool | Features | Sampling | Approx. cost per 100k sessions |
|---|---|---|---|
| Datadog RUM | Full mobile+server stack, W3C tracing | Up to 100%, flexible | $300–$450 |
| Sentry | Free tier, strong release comparisons | Default 100% | $0 (up to limits) |
| Firebase Performance | Free, Google ecosystem only | Automatic | $0 |
| New Relic Mobile | Powerful NRQL, enterprise | Up to 100% | $500+ |
For most products, Firebase Performance is a good start (free, zero-config for networking). But as soon as you need correlation with server traces or custom business attributes, you move to Datadog or Sentry. Datadog processes 10x more events than Firebase Performance at a comparable cost.
How to choose sessionSampleRate
sessionSampleRate determines the percentage of sessions sent to RUM. With high DAU (e.g., 1 million), 100% sessions is expensive. Standard practice: 100% for new releases for the first 48 hours, then drop to 20–30%. To find rare errors (e.g., ANRs on 0.5% of devices), you need high sampling. A balanced choice is 50%.
Setup example with Datadog RUM
SDK integration
import DatadogRUM RUM.enable(with: RUM.Configuration( applicationID: "your-rum-app-id", sessionSampleRate: 80, // 80% of sessions telemetrySampleRate: 20, trackBackgroundEvents: false // do not track background events )) Manual View instrumentation (SwiftUI)
struct ProductListView: View { var body: some View { List(products) { product in ProductRow(product: product) } .trackRUMView(name: "ProductList") } } Monitoring a specific network request
// With URLSession + Datadog let delegate = DDURLSessionDelegate() let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) Datadog automatically injects x-datadog-trace-id into every request via this session — no additional interceptors needed.
Typical issues when implementing RUM
A common bug: Views close too early. For example, in UIKit without an explicit stopView call, the agent closes the View on viewWillDisappear, but if the controller presents a bottom sheet over itself, the View closes and reopens, creating a duplicate entry. Solution:
// iOS — explicit View lifecycle management override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) RUM.monitor?.startView(viewController: self, name: "ProductDetail") } override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) if isMovingFromParent { RUM.monitor?.stopView(viewController: self) } } RUM implementation process
| Stage | Duration | Result |
|---|---|---|
| Current app analysis | 0.5 day | List of bottlenecks |
| Tool selection and architecture | 0.5 day | Technical specification |
| SDK integration and instrumentation | 1–2 days | Working prototype on staging |
| Testing and A/B test with synthetic | 1 day | Data verification |
| Production deployment and dashboard launch | 0.5 day | Real-time monitoring |
What's included in the work?
- Tool selection based on stack and budget (Datadog / Sentry / Firebase / New Relic)
- SDK integration with optimal sessionSampleRate
- View transition instrumentation (iOS, Android, Flutter)
- HTTP interceptor setup for network resource tracking
- Consent logic configuration for GDPR compliance
- Dashboard construction: p75/p95 View load time, Error Rate, Long Task Rate
- Team training on dashboard usage
Timeline and cost estimation
Basic RUM setup takes 1–2 days. Custom attributes and dashboards add another 1–2 days. On average, the investment pays off within 2–3 months by reducing bug-finding time. The cost is calculated individually based on app complexity and chosen tool. Contact us for a precise assessment. Our team has 7+ years of experience in mobile development. Get a consultation on selecting the right RUM tool.