u/32GB_of_RAM

I love you guys. For context I had a very unique game running on flutter but I was outgrowing Thermion. I tried flame 3d but it’s unstable on so many Android devices. Then comes in flutter scene…that thing is magic. Incredible performance. No longer need to move to a game engine. It also comes with an ecosystem such as flutter scene soloud for 3D Spatial Audio at incredible performance.

In the end my game was about 70 mb on iOS and 150 mb on Android. Considering what the game is that’s incredibly impressive.

Btw if you guys want to see the game I’m talking about: lightwarsar.com

Quick backstory: our app kept losing users on Android edge cases and we had zero idea why. Sentry's RN SDK does basically everything we needed like crashes, tracing, profiling, session replays, and works. Which is great, but "everything" also means a few hundred KB and a chunk of main-thread time sitting inside your app.

Also we hated the dashboard. It was so much stuff everywhere, was missing a lot of business side metrics, and we had to often do something like bundle in ANOTHER tool on top of it to track bussiness metrics.

So we would end up with a stupidly heavy combo like PostHog + Sentry. Two big packages just to get everything you need.

So we built our own, much smaller thing. It's called Rejourney, it's open source (Apache licensed), and this project taught us more about mobile perf than any conference talk has.

When we started building it, we were very set-minded on how to NOT copy Sentry. The whole scope iswe want all the good stuff it does but much leaner, and you can't do that by looking at how they do it.

@/sentry/react-native: ~478kB minified, 157kB gzipped, 6 deps

@/rejourneyco/react-native: ~47kB minified, 15kB gzipped, 0 deps

Roughly 10x smaller on paper (Bundlephobia, July 2026 but your mileage will vary once native code, tree-shaking, etc. get involved, so don't take it as a final-APK number).

How it works (Mostly Native Code -- big win)
For React Native, JS is just the dispatcher. TypeScript decides "should we even record this session," pulls remote config, wires up navigation then hands off to native code (Swift/Kotlin) that does the actually expensive stuff. This includes screenshots for user recording, compression, uploads, crash capture. Keeping JS as a thin control layer instead of doing heavy lifting there was probably 80% of the performance win.

Also one thing we learned is to never touch RN APIs at module import time. Newer bridgeless RN will just throw if you poke TurboModuleRegistry too early. Lazy-load everything, resolve it on init(), fall back gracefully, never let the SDK crash the host app just by being imported. Learned that one the hard way.

User Replay is "frames" to make a video
There's no DOM to snapshot on mobile, so "replay" = 1-3 FPS which you can configure remotely via the dashboard based on your performance and replay requirements. We then layer it with a timeline of taps, scrolls, screen changes, and network calls.

We had edge cases to deal with such as Mapbox/GL views render pitch black in a plain screenshot because they're GPU surfaces, so we had to special-case that capture. And reading map pixels mid-pan causes visible stutter, so we skip frames while the map's moving and grab one once it settles (we call this the "idle heuristic").

Network/Logs with Replays (breadcrumbs)
Network queue caps at 100, event ring caps at 5,000, screenshot buffer caps at 500 frames, and so on. If the app produces data faster than we can ship it, we drop the oldest stuff. Unbounded queues are the classic way an observability SDK ends up eating someone's phone.

Crash capture has to survive the process actually dying
You can't upload a crash report the instant it happens as the process is usually already gone. So everything gets written to disk first and gets picked up on the next app launch instead. We really tried to find a way around this, but this seems to be the industry standard and nothing yet has figured this part out.

Privacy, because obviously
Text inputs, password fields, and camera views are masked by default — before the screenshot is even encoded, not after, so raw pixels never touch the JPEG. Wrap anything else in <Mask> to hide it too. There's also an observeOnly mode for crash/network/error data with zero screenshots.

Integration is stupidly small
import { Rejourney } from '@rejourneyco/react-native';

Rejourney.init('pk_live_your_key');
Rejourney.start();

No provider, no wrapper hell. Auto-detects Expo Router, has a hook for React Navigation.

Was it worth it?
Yes. We love this tool and the extremely simple dashboard to go with it. We can easily add what we wish and keep everything clean and simple. We also released it publicly for a cloud version and teams using it seem to love it for the sample reason. A few things we want to add that Sentry has but we don't include source maps, but we haven't seen feature requests for that yet since people just dump context we collect into AI, and it can figure out the cause really well.

Repo's here if you want to poke around: https://github.com/rejourneyco/rejourney

Here is the cloud version:
rejourney.co

Happy to answer questions about any of the native/RN weirdness above.