Mobile RUM
Mobile RUM puts an SDK into native apps such as iOS and Android and records crashes, launch time, and per-screen slowness from the real user's device. The billing unit is the same session as browser RUM; only the items you can see are mobile-specific.
What it does
SDKs for iOS, Android, React Native, Flutter, Kotlin Multiplatform, .NET MAUI, Unity, Roku, and C++ collect sessions, screens (Views), actions, and errors from the device. Crash reports are symbolicated with dSYM or mapping files, and launch time, hangs, ANRs, and rendering delays are gathered as Mobile Vitals.
When to use it
Use it to get out of the state where you first learn about a crash from a store review. Typical uses are checking version by version whether the crash rate went up after shipping a new release, finding the version whose launch got slower, and tracing why actions freeze on a specific screen all the way down to the trace.
An everyday analogy
It is a drive recorder fitted to a sales car that goes out to customers. Sudden braking on the road (crashes) and traffic jams (slow launches) that cannot be seen from the shop (the server) are recorded by the car itself and brought back. You can see which car model (app version) and which road (screen) they happen on most.
Bottom line - the counting unit is the same session as browser RUM; what you see is mobile-specific
Mobile RUM is part of RUM. The official documentation covers Browser, Android, iOS, React Native, Flutter, Kotlin Multiplatform, .NET MAUI, Unity, Roku, and C++ (as of September 2026, source: Application Monitoring). The Android SDK supports Android 6.0 and later (source: Android and Android TV Monitoring). The billing unit is the same session as browser RUM: both tiers, RUM Measure and RUM Investigate, are billed as a monthly amount per 1,000 sessions (source: Datadog Pricing). The two-tier mechanism is covered in the RUM explainer. What differs is the content: crashes, slow launches, and frozen screens that never appear in server logs arrive from the real user's device.
Crash reports and symbolication - dSYM and mapping files
The first value is crashes. On iOS, to get symbolicated stack traces, you upload the .dSYM files from your build to Datadog. There is also a procedure for confirming arrival with a test crash (as of September 2026, source: Apple Platform Crash Reporting and Error Tracking). Android supports deobfuscated reports via mapping files, NDK crashes for C / C++, and ANR reporting (source: Android Crash Reporting and Error Tracking). For iOS-specific app hangs, fatal ones where the app stopped responding and terminated are marked "Crash" in Error Tracking and the RUM Explorer, while ones that recovered carry no mark. Without the key, the stack traces that arrive cannot be read. Building dSYM and mapping uploads into CI is the practical first step of adoption.
| Item | iOS SDK | Android SDK |
|---|---|---|
| What is used for symbolication / deobfuscation | .dSYM files | mapping files |
| Native code crashes | Not described (within the scope referenced by this article) | NDK crash reports (C / C++) |
| Detecting unresponsiveness | App hangs (fatal = Crash mark, non-fatal = no mark) | ANR reporting |
| Verification after setup | Trigger a test crash, restart, and confirm arrival | Confirm arrival of deobfuscated stack traces |
Launch time and Mobile Vitals are measured on the device side
Device-side performance never appears in server logs. Application Launch Monitoring measures the time until the first frame is drawn (time to initial display) and the time until the app becomes interactive (time to full display) on iOS and Android (as of September 2026, source: Apple Platform Monitoring). Mobile Vitals is a group of device metrics: refresh rate, slow renders, frozen frames that stall for more than 700 ms, CPU ticks, memory utilization, and on iOS the hang rate. The crash-free session rate per version is on the same screen, and when you select a screen in the RUM Explorer, recommended benchmark ranges are shown (source: Mobile Vitals). Neither traces nor logs can substitute for these. Even if the server responds in 50 ms, if the device stalls for 700 ms, the user sees a frozen app.
| Metric | What it measures |
|---|---|
| Refresh rate | Whether main-thread rendering stays smooth |
| Slow renders | The share of frames whose rendering fell behind the benchmark |
| Frozen frames | Frames where rendering stalled for more than 700 ms and appeared frozen |
| CPU ticks per second | CPU consumption per screen (impact on battery) |
| Memory utilization | The state just before an out-of-memory crash |
| Hang rate (iOS) | By Apple's definition, the number of seconds unresponsive per hour |
| Crash-free session rate | The share of sessions that did not crash, per app version |
Use the screen (View) as the unit and compare by app version
The unit of recording is the screen (View). View timings capture per-screen performance, and there is an API to signal that loading has completed (as of September 2026, source: Apple Platform Monitoring App Performance). Vitals and crashes are both tied to Views, so "only the checkout screen is slow" shows up by screen name. The other axis is version: the Vitals screen shows trends across versions and can be filtered by version (source: Mobile Vitals). Because old versions keep running until users update, "the crash I thought I fixed is still arriving" is the old version's share, and when laid out by version, the spread of the fixed version and the remaining crashes can be read on the same graph. Background tracking and deferred sending while offline are included (source: Android and Android TV Monitoring), so records are not lost even on a plane. Frustration Signals and Web View Tracking are available on both OSes.
What it means to count under the same SKU as browser RUM
Billing is shared with browser RUM, and the two tiers, Measure and Investigate, are covered in the RUM explainer. Here we only cover the mobile-specific way of counting. A session expires after 15 minutes of inactivity and is defined to last at most 4 hours. If someone opens the app for 1 minute during their commute and closes it 10 times a day, that is 10 sessions because the 15-minute expiry falls between them, which feels different from one long visit on the web. Starting your estimate from "monthly active users x launches per user" keeps you from missing by an order of magnitude. The additional charge for Session Replay and the differences in replay coverage between SDKs are covered in the Session Replay explainer. The overall pricing structure is summarized in the pricing guide.
- Assumptions: 50,000 monthly active users, 20 launches per user per month, 1 launch = 1 session
- Monthly sessions = 1,000,000 = 1,000 in units of 1,000 sessions
- RUM Measure: 1,000 x the Measure unit price (per 1,000 sessions)
- RUM Investigate: 1,000 x the Investigate unit price if all sessions are included; 100 x the Investigate unit price if filtered down to 10%
Do not confuse it with Mobile App Testing
Mobile App Testing has a similar name and is easy to mix up, but it is real-device testing on the Synthetics side. On the official pricing page it is billed as a monthly amount per 100 test runs, counted under a SKU separate from RUM (source: Datadog Pricing). RUM is observation of what happened on real users' devices; Mobile App Testing is verification that operates a real device even when no user is present, and the roles are complementary. RUM tells you that crashes increased late at night; Mobile App Testing tells you whether the pre-release build launches. The units also differ: RUM counts sessions and Mobile App Testing counts test runs, and neither can substitute for the other. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
| Aspect | Mobile RUM | Mobile App Testing |
|---|---|---|
| Product family | RUM (real user monitoring) | Synthetics (synthetic monitoring) |
| Who operates it | Real users | Datadog simulates actions on a real device |
| What you see | Crashes, launch time, Vitals, per-screen slowness | Whether a defined scenario passes on a real device |
| Billing unit | Per 1,000 sessions (two tiers: Measure / Investigate) | Per 100 test runs |
| Question it suits | What is happening on users' devices | Whether the pre-release build works |
How to layer Error Tracking and Session Replay
After adoption, build up in 3 stages. Stage 1 is RUM itself, where crashes, ANRs and hangs, launch time, and Vitals line up by screen and version. Stage 2 is Error Tracking, which groups crashes with the same cause into a single Issue and notifies you only when a new Issue appears. Stage 3 is Session Replay, which reproduces what the user was doing just before the crash. The reason for this order is cost and effort: stage 1 is established with the SDK plus dSYM or mapping uploads, and stage 2 requires no additional SDK. Stage 3 adds a per-1,000-session unit price, so it is reasonable to narrow it to the screens where crashes concentrate. Right after adoption, simply reviewing the Issue list every morning gets you to a state where you learn about crashes before store reviews do. Separating "is the slowness on the device side or the server side" can wait until you connect APM afterward.
Things to watch out for
- This article is based on the official documentation as of September 2026. Supported platforms and SDK features may be added, so when adopting, give priority to each platform's setup page.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
- To receive crash reports in readable form, you need to upload the iOS .dSYM and Android mapping files for every build (as of September 2026). We recommend building this into your CI pipeline before shipping to production.