Observability for Mobile with OpenTelemetry
In the latest episode of OpenObservability Talks, we dove into a space that doesn’t always get the spotlight it deserves: mobile app observability. While backend systems and cloud infrastructure tend to dominate observability conversations, the reality is that mobile environments present an entirely different set of challenges, from capturing real user interactions to dealing with network constraints and battery efficiency.
I invited Hanson Ho, Android architect at Embrace and an approver on the OpenTelemetry Android SDK, to join me on this episode. Hanson also brings a wealth of experience from Twitter, Salesforce and SAP.
Let’s unpack the key takeaways from my fireside chat with Hanson.
The Unique World of Mobile Environments
Mobile environments aren’t just a smaller version of server infrastructure. They’re an entirely different beast. Network connectivity is unreliable, devices are resource-constrained, and app performance is tightly coupled to user experience. This unique setting calls for a rethinking of how we approach observability.
This distinction becomes even more apparent when you factor in the fragmented nature of mobile ecosystems. The open-source nature of Android means a staggering variety of device manufacturers, custom OS forks, and hardware capabilities. Unlike Apple’s tightly controlled ecosystem, Android developers face an unpredictable mix of screen sizes, performance specs, aged OS versions, and vendor-specific quirks. As Hanson pointed out, “Building observability for Android is like preparing for an obstacle course — you never know what combination of hardware and software your app will encounter.”
Bringing Observability to Everyday Frontend Development
For frontend developers, observability might feel like a backend concern — after all, servers are where the logs, metrics, and traces live, right? Not anymore. Modern frontend development, particularly on mobile, demands visibility into how users experience the app.
Slow screen loads, janky animations, and unresponsive taps all create friction that drives users away. Observability helps pinpoint these issues, empowering developers to fix performance bottlenecks proactively. “Frontend performance isn’t a bonus — it’s the first impression. If your app stutters or stalls, users don’t wait around to figure out why,” Hanson explained.
Beyond performance, this visibility also sheds light on user behavior. Which features are engaging users? Where are they dropping off? Are push notifications driving conversions or uninstalls? Observability bridges the gap between technical performance and user experience, enabling developers to build not just functional apps, but delightful ones.
Business Metrics: Why Mobile Observability Matters More Than Ever
Observability isn’t just a developer’s tool — it’s a business enabler. Mobile apps are often the primary touchpoint between companies and their customers, whether it’s a ride-sharing service, an e-commerce store, or a banking app. When apps crash or slow down, the impact isn’t limited to tech teams; it hits revenue, retention, and brand reputation. “Your app’s reliability is your business’s reliability — customers don’t separate the two,” my guest emphasized.
By connecting telemetry data with business metrics, companies can measure the real-world impact of performance issues. A 3-second delay on the checkout screen isn’t just a lag — it’s a lost sale. Similarly, in the case of a ride-sharing service, Hanson shares, “When a user tries to book a ride and the app stalls, it’s not just a minor inconvenience — it’s a potential lost fare and, more importantly, a lost customer.” Observability helps correlate app health with business outcomes, turning raw telemetry data into actionable insights that drive growth.
Collecting Telemetry on Constrained Devices
One of the biggest challenges in mobile observability is collecting telemetry in a highly constrained environment. Take battery life, for example. Mobile devices have limited energy resources, and developers must avoid overloading the app with telemetry data that could drain the battery. This is particularly crucial for apps that need to run in the background, like fitness tracking apps that monitor physical activity throughout the day. In these cases, telemetry collection must be both light and efficient, only gathering data when it’s necessary or during idle periods, ensuring that the app doesn’t interfere with the user’s experience.
Data usage is another constraint, particularly in regions with slower or limited connectivity. As Hanson pointed out, “When you’re working in areas with spotty 3G or 4G connections, every byte counts — telemetry needs to be compressed and sent sparingly, or else you risk not only performance issues but also user frustration.” Techniques like batch processing and adaptive sampling allow mobile apps to reduce the frequency of data transmissions and send data in chunks when network conditions are more favorable.
Additionally, telemetry must be adaptable to a variety of device capabilities. Lower-end devices with limited processing power may struggle to handle large amounts of telemetry data, leading to performance degradation. In these cases, lightweight telemetry solutions that only capture essential metrics — such as app launch times or crash events — ensure that the app remains responsive without putting undue strain on the hardware. This is why a tailored approach to mobile telemetry is crucial: balancing the need for insight with the constraints of the device ensures that observability doesn’t compromise the user experience.
Twitter-Scale Observability on Mobile Apps
When apps scale to the size of platforms like Twitter, mobile observability reaches an entirely new level of complexity. Millions of devices, countless app versions, and global distribution make it impossible to rely on traditional monitoring methods. “At Twitter scale, you’re not monitoring an app — you’re monitoring a living, breathing ecosystem of devices, networks, and user behaviors,” my guest described.
Scaling observability to this magnitude requires innovations like dynamic sampling, real-time event streams, and federated data collection. These techniques allow companies to track performance across a sprawling user base without being overwhelmed by data volume.
Having such mass of mobile users enables taking a measured, incremental approach to rolling out observability capabilities. As Hanson explained, “We didn’t rush to put everything in place immediately. We started small, testing out features with small user groups and validating the impact on performance and data quality before expanding.” This careful rollout allowed the team to evaluate how these new features affected app performance in real-world conditions, catching issues like battery drain or network congestion early on, and verifying that the user experience isn’t impacted, before scaling to a wider audience.
OpenTelemetry: Expanding from Backend to Client-Side
Originally designed for server-side workloads, OpenTelemetry is now expanding into client-side environments — including web and mobile. This shift recognizes that user experience begins the moment someone taps an app icon. End-to-end observability is no longer a nice-to-have; it’s essential for modern mobile development, and OpenTelemetry, as the de-facto open standard for observability, is making an impact. As Hanson put it, “OpenTelemetry isn’t just coming to mobile — it’s redefining what mobile observability looks like.”
This expansion was initiated with the formation of the OpenTelemetry Client-Side Telemetry Special Interest Group (SIG). The SIG was created to focus on defining best practices, addressing unique challenges, and contributing to the development of SDKs for mobile environments like Android and iOS. More importantly, it defines semantic conventions that formalize the language to describe the basic tenets of client-side telemetry. This provides a standard way of naming and structuring telemetry data across mobile platforms, in much the same way OpenTelemetry does for CI/CD observability and other domains.
Check out the SIG’s project board for more on the ongoing and planned activity.
The OpenTelemetry Android SDK Working Group
The OpenTelemetry Client Side Telemetry SIG is assisted by various specialized working groups, one of which is the OpenTelemetry Android SDK Working Group (WG).
One of the key areas of focus for the WG has been optimizing the SDK for resource-constrained devices. The group has worked tirelessly to ensure that the SDK remains lightweight, flexible, and efficient, avoiding unnecessary overhead that could impact app performance. Hanson explained, “When we talk about Android, we need to be mindful of how resource-hungry some of these SDKs can be. Our goal is to make sure we’re collecting the right data without draining the user’s battery or causing performance issues.”
The WG also works on integrating OpenTelemetry with Android-specific features, such as background task management, network management, and various UI frameworks. Additionally, the group has focused on ensuring that the SDK can work across different Android versions, devices, and customizations, without compromising on reliability or flexibility.
The WG has also been collaborating on enhancing mobile tracing. Mobile apps often rely on asynchronous interactions, making it tricky to capture accurate traces of user activity. The team has worked on improving how OpenTelemetry handles asynchronous operations, ensuring that traces are continuous and provide a comprehensive view of user actions and app behavior.
Want to learn more? Check out the OpenObservability Talks episode: Observability for Mobile with OpenTelemetry.
