Why mobile app reliability is so complicated

Unlike browser-based apps that update automatically, mobile apps are often tied to user behavior, especially when it comes to updates. Users skip versions, ignore notifications or are restricted by outdated OSes. That leads to a staggering number of active app versions in the wild.

• 31% of apps run five to 10 active versions simultaneously.
• 25% of apps support more than 10 versions.
• 6% of apps have 50+ versions live in production.

Supporting this range of legacy versions isn’t just a test coverage challenge. It’s a performance, crash and observability nightmare. Older versions are often slower, less stable and more vulnerable to regressions. Yet, engineering teams are expected to keep all of them running smoothly. Fun!

Device types create their own challenges, as mobile phones operate with different levels of memory and processing power. The Android ecosystem is notoriously fragmented, with 26% of Android devs seeing their apps used across more than 1,000 unique device types.

With each device offering different levels of memory, CPU and OS-level features, optimizing performance at scale becomes nearly impossible. The iOS ecosystem is more controlled when it comes to unique device types, but still far from simple.

The network picture varies across iOS and Android and by geography. Mobile app users rely on different mixes of Wi-Fi and cellular, and this inconsistency can lead to unpredictable app experiences depending on local infrastructure. For example, 30% of users in Africa and 50% of users in Asia rely exclusively on cellular networks for connectivity.

Mobile telemetry can be significantly delayed in reaching the server due to network interruptions, app crashes or user behaviors. Mobile users don’t live in a vacuum — they move! They hop between cellular networks, Wi-Fi connections and dead zones. They lose packets, go offline mid-session and resume hours later. Just think of your favorite hiking trail app. While you’re off the grid, the mobile engineers are in the dark. These connectivity gaps introduce unpredictable telemetry delays.

• 17% of mobile telemetry data arrives more than an hour late.
• 7% takes more than 12 hours to reach observability backends.

This often means engineers are operating with an incomplete picture of app health. They can’t fix what they don’t know is broken. Luckily, a lot of thinking has gone into how time plays a crucial role in aggregating mobile data for observability and what the best practices are.

Traditional observability tools were built for stable, server-side environments, but mobile operates in the wild. Engineers need visibility into what’s happening on real user devices, across unpredictable network conditions and hardware variations they can’t control. Relying solely on backend signals misses key mobile performance issues perceived by users. Think of app freezes, slow launches, crashes on specific devices, blank screens, network dropouts, misbehaving third-party SDKs, inconsistent behavior across app versions and unresponsive UI interactions. Today’s observability strategies must include real user context, including what the user saw, when it happened and why it matters for a successful mobile business.

Mobile isn’t just frontend on a smaller screen. It demands specialized tools, cross-team collaboration and workflows built around OpenTelemetry and user-focused metrics. As organizations align their reliability goals with real-world app experiences, they’re embracing a shift: observability that starts with the user and reflects mobile’s messy, fragmented and mission-critical reality.

To learn more about the complexity of mobile, download the full report from Embrace.