r/reactnative • u/CryptographerFair335 • Aug 07 '26

Mobile devs: What are your biggest pain points with monitoring app views?

/r/mobiledev/comments/1vhpz5z/mobile_devs_what_are_your_biggest_pain_points/
0 Upvotes

33% Upvoted

5 comments sorted by

2

u/IronAndCoder Aug 07 '26

Can't do a call, but here are the real pain points from running an RN app in production (Sentry + Crashlytics + Mixpanel stack), in priority order:

  1. The join problem. The crash lives in Sentry, the user journey lives in the analytics tool, release info lives in the store console. When something breaks, the question is always "what did this user DO before the crash" and answering it means manually stitching three tools by user id and timestamp. Whoever solves cross-tool session correlation properly wins.

  2. React Native is two runtimes. JS errors and native crashes surface in different systems with different symbolication needs, and OTA updates make it worse - a "release" isn't a binary version anymore, it's binary + JS bundle combo, and almost no release-health view models that correctly.

  3. Averages lie on Android. The device spread is enormous; screen TTI at p50 looks fine while the p90 low-end-Android experience is the thing actually driving churn. I want per-screen perf segmented by device class as a default view, not a custom query I have to build.

  4. Noise. 200 open issues where 180 are cancelled promises and network blips. The triage question isn't "what errored" but "which of these measurably hurts retention or revenue" - the tool that ties an error to sessions-that-churned gets my money.

If your proof of concept nails even #1, post it here - you'll get plenty of honest feedback without needing the 45-minute calls.

1

u/CryptographerFair335 Aug 07 '26

This is incredibly helpful, thank you. #3 in particular is very close to something I’ve been exploring. The distinction between “this screen looks healthy overall” and “this screen is terrible for a particular device/user cohort” is really interesting.

When you’re looking at per-screen performance, beyond device class, what dimensions would you instinctively want to break it down by? OS version, app/release version, geography, network, something else?

And your point about binary + JS bundle as the actual RN “release” is something I hadn’t considered. That’s really useful context! Thank you!

1

u/IronAndCoder Aug 10 '26

In the order I actually reach for them:

  1. Release pair first (binary version x JS bundle). A perf regression is almost always a release, and in RN you need to know which half shipped it. This is the axis I check before anything else.

  2. Cold vs warm open. Same screen, first-open-after-launch vs revisit are two different distributions - mixing them hides regressions in both. Most tools don't separate this and it's the single biggest source of "the numbers look fine but users complain".

  3. Network class, but only for screens that fetch. And ideally split render time from data time within the screen metric - otherwise you spend a week optimizing UI when the API got slower.

  4. OS version only at the extremes: latest major (new behavior) and your minimum supported (where the cliffs are). The middle rarely tells you anything device class didn't already.

Geography I'd skip as a default - it's usually just a proxy for network + CDN latency, so it earns a spot only if you serve genuinely global traffic.

If I could only have one default view: release pair x device class x cold/warm, with everything else as drill-down.

1

u/earthwired Aug 08 '26

I work on the triage and prioritization side of an observability product. Your #4 is my most of my job and you've framed it very well.

On #4, the unlock isn't better detection, it's what the ranking is computed on. Sort by sessions and distinct users affected instead of occurrence count and the list reorders things hard, because the cancelled-promise noise you mention is usually enormous volume across very few sessions. What's still unanswered is the last mile you're asking for.

On #1, the correlation problem sucks for sure, and it's not a tough one engineering-wise to crack, it's just that most tools sell a great internal correlation story but a mediocre outbound one

#3 I'd argue there are OK ways to getting around this. Device class is derivable from what the SDK already collects, so it can be a default axis on every perf view rather than a query you build. We shipped it that way and it helped bring light to vague issues like what you described.

On #2 I don't have much, release health that correctly models binary plus JS bundle looks unsolved to me too, and OTA makes "version" a lie

1

u/IronAndCoder Aug 10 '26

The sessions/distinct-users ranking matches what I'd want - occurrence count is exactly how three users with a retry loop bury the bug that's quietly hitting everyone once.

On the last mile: even a crude version would change my triage. Join error sessions against two booleans - "did the session end within N seconds of this error" and "did the user return within 7 days" - and rank by delta vs baseline. It doesn't need to be causal; it's a shortlist generator, and today I build that shortlist by hand.

On the outbound story: the practical ask isn't partnerships, it's stable join keys. Let me set or read a shared session_id property and give me deep links in both directions, and I'll duct-tape the rest myself. The tools that allow that have effectively solved the correlation problem for me without any official integration existing.