u/Background-Fig9828

Came across this article about an OTel mobile tracing solution that "actually works" and I'm wondering if it's really so hard, specifically when dealing with mobile? Fairly new to this space and trying to get up to speed.

As exemplified by the maturing of the Kotlin Multiplatform SDK: https://opentelemetry.io/blog/2026/kotlin-multiplatform-opentelemetry/

Anybody it taking advantage of it in real world apps at scale?

Stumbled across this on LinkedIn - interesting post and resource from Caleb Davis at Square:

Mobile observability is complex.

There's a lot of challenges unique to mobile: offline states, background kills, symbolication, correlating client and backend traces. Adding telemetry is easy. Adding telemetry that tells you what actually happened is hard.

I've been using Claude Code for about a month and absolutely LOVING it. But you know that moment when Claude reviews its own code, declares everything perfect... and then you run the app 🫠 🫣

So I decided to codify my philosophy on mobile observability and teach it to Claude.

The result: Mobile Observability Plugin for Claude Code

Now Claude knows how to properly instrument user observability and system observability. I used standardized frameworks so my side projects actually have high-quality telemetry. That way I can easily fix all the pesky bugs that Claude didn't catch in code review 🫡

What's included:
- 8 skills (crash capture, user journeys, network tracing, session replay, etc.)
- 2 agents for codebase analysis and instrumentation review
- /instrument and /audit commands
- Vendor guides for Bitdrift, Sentry, Datadog, Embrace, Bugsnag

Haven't battle-tested it myself yet, but I'm excited to see what breaks 😅

🔗 https://lnkd.in/gKqwJuxf

Came across this from Spotify Engineering and thought it was a great look at how they manage mobile (and desktop) releases:

https://engineering.atspotify.com/2026/2/how-we-release-the-spotify-app-part-2

So much of their process goes beyond just “did it crash or not.” They’re thinking about:

• Gradual rollouts
• Monitoring real user impact
• Catching issues that only show up in production
• Deciding whether to continue or halt releases based on signals

A lot of the hardest problems are subtle issues vs crashes.

“99.9% crash-free” says almost nothing about:

• Slow screens
• UI jank
• Failed network requests that retry silently
• Flows users abandon because something felt broken

A lot of the worst mobile issues never show up as crashes. Was digging into Android Vitals for Google's POV on this - they emphasize things like:

• ANRs
• Slow rendering
• Excessive wakeups

https://developer.android.com/topic/performance/vitals

Feels like crash-free rate is one of the least representative metrics of real UX, even though it's the one everyone pays attention to. Food for thought.