Mobile observability: Key considerations for the build vs. buy decision

At first glance, implementing observability for mobile apps seems straightforward. The process appears simple:

1. Add an OpenTelemetry-compliant SDK to your mobile app
2. Set up exporters to send telemetry data to your backend
3. Configure a collector to process the data
4. Create dashboards, alerts and visualizations to help troubleshoot

However, mobile environments introduce several critical complexities that aren’t immediately obvious to teams without experience working with mobile telemetry data.

Key considerations when choosing an OpenTelemetry-compliant SDK

When implementing mobile observability, selecting the right SDK is crucial as it directly impacts both your app’s performance and the quality of data you collect. The mobile environment presents unique constraints that aren’t typically encountered in server environments.

Performance impact when looking at OTel SDKs

The OTel SDKs for Java and Swift are built for collecting telemetry on server-side apps, not mobile apps. The resource constraints of these two environments are vastly different, which means a lot of instrumentation within the SDKs is unnecessary and adds weight and overhead to the mobile application.

• Battery impact: Every instrumentation point potentially drains user battery. What might be acceptable in a data center becomes problematic when it causes users’ phones to die prematurely.
• Memory limitations: Mobile devices have limited memory. Instrumentation that works flawlessly in your server environment might cause Out-of-Memory crashes in your app.
• Processing overhead: Heavy instrumentation on the main UI thread can cause jank, frozen frames, and Application Not Responding (ANR) errors – issues that don’t exist in backend environments.

Implementation of the OTel-compliant SDK

There are several attributes that you’d have to add to your logs and traces to get the information that would help troubleshoot your issue:

• Device information: OS version, device model, chip set, memory available, storage available
• Contextual on device: Low memory warning, network connectivity changes
• Context about what else is happening: For example, if you’re evaluating performance, the amount of networking traffic may affect performance. You may also want to know connectivity and the number of concurrent network calls.
• Lifecycle information: There is no concept of a session so you’d need to hook into lifecycle events to understand if the app was in the foreground or the background
• Ongoing maintenance as mobile platforms evolve

Key considerations when setting up exporters to send telemetry data

Mobile users launch and leave apps frequently, creating unique challenges for span collection. As highlighted in a recent CNCF blog post, collecting and sending spans at the right times and with the right end times requires careful implementation.

• Symbolication: Server environments aren’t running compiled code that crashes, so they don’t need to worry about desymbolicating data from error and crash reports. With users running many app versions, your symbolication service has to manage several different ways to process crash data.
• Proper batching and compression to minimize bandwidth usage
• Data buffering: When devices go offline, telemetry data needs to be stored locally and uploaded when connectivity returns, without consuming excessive storage.

Key considerations when configuring a collector to process the data

Once you’ve set up your SDK and exporters, configuring a collector that can properly process mobile telemetry presents its own set of challenges. Mobile data has unique characteristics that many standard collector configurations aren’t designed to handle.

• Delayed and out-of-order data: Mobile telemetry often arrives significantly out of order compared to when events actually occurred. Mobile apps may upload telemetry only upon completion or reconnection, causing data from minutes or even days ago to suddenly appear in your systems. Most backend systems are not set up to process delayed data so significant changes may need to be made depending on how delayed the data is.
• Cardinality explosion: Mobile apps generate high-cardinality data (e.g., device types, OS versions, app versions, network carriers). This level of dimensionality can break traditional monitoring tools designed for server environments.
• SDK version fragmentation: Users don’t update apps immediately. Your telemetry system must handle multiple SDK versions simultaneously.

Key considerations for dashboards, alerts, and visualizations

The final step in your mobile observability implementation is creating effective ways to visualize and understand the data you’re collecting. This is where many platform teams encounter unexpected challenges, as traditional visualization approaches often don’t account for mobile-specific needs.

• Delayed data: The dashboards will not be accurate if they don’t take into account delayed data and the time that the issue actually occurred rather than the time the event was received.
• Visualizations: Current visualization tooling is not good at visualizing all of the context together, which is required for mobile (and not required for backend). For example, in mobile you’d want to see all the networking calls happening at the same time and what the status of the connectivity is to help you troubleshoot what’s actually happening.

If your visualization tool for mobile observability does not show all technical and behavioral data from the perspective of full user experiences, then you’ll struggle to track down the source of many types of common issues:

• Data payload changes: Backend teams can make updates to APIs that break mobile app functionality. Since the network calls successfully retrieve data, there won’t be any obvious issue to trigger an alert. You need client-side tracing that highlights where data parsing issues and failed UI updates occur during user sessions.
• Background app behavior: If your app polls for updates while in the background, it can exceed device resource limits and cause crashes. You need visibility across foreground and background sessions to track down issues that span across app lifecycle boundaries.
• Third-party endpoints: Your app’s startup time could bloat and cause users to abandon, while your first-party API responses are perfectly healthy. You need to understand the impact that third-party SDKs have on app performance, including heavy, blocking, failing, and duplicate network requests.
• User abandons: There are many issues that won’t surface with an error log but nonetheless cause users to churn, like frozen screens and sluggish app experiences. Beyond having a user ID attribute to filter your telemetry on, you want to understand the complete picture of how user, app, and device variables interact over time. That way, you can work backwards from negative user outcomes to surfacing the underlying technical root causes.

Build vs. buy considerations

When evaluating whether to build or buy a mobile observability solution, consider:

Time investment

Building a robust mobile observability pipeline requires:

• Mobile SDK expertise to minimize performance impact
• Infrastructure to handle high-volume, delayed, and out-of-order data
• Mobile-specific dashboards that account for unique mobile metrics
• Ongoing maintenance as mobile platforms evolve

Implementation complexity

A complete solution requires:

• Proper batching and compression to minimize bandwidth usage
• Intelligent sampling that preserves outliers and anomalies
• Mobile-specific visualization for UI performance, network transitions, and user journeys
• Solutions for propagating trace context from mobile devices to backend services

Conclusion

Mobile observability shares common principles with backend observability but introduces unique challenges that require specialized knowledge and tools. The apparent simplicity of “just add a mobile SDK” masks significant complexity in properly implementing, scaling, and maintaining an effective mobile observability pipeline.

For platform teams evaluating their approach to mobile observability, it’s worth considering whether the time and expertise required to build and maintain a custom solution delivers sufficient ROI compared to existing solutions that have already solved these complex challenges.

Whether you build or buy, success requires understanding the fundamentals of mobile environments and how they differ from the server-side world that platform teams typically navigate.