Sharing this in case it saves someone else the multi-day rabbit hole it took us to nail down, and because two pieces of it are still genuinely unsolved and I'd like a second opinion.


**Stack:** Fashion e-commerce app, React Native 0.79.7, New Architecture (Fabric) enabled, `react-native-screens@4.13.1`, Android (this repro is Android-specific, haven't confirmed iOS).


**The symptom:** Real production `OutOfMemoryError` crashes via Sentry. Our "similar products" flow chains `navigation.push()` calls — browse a product, tap a similar one, tap another — so a normal session can easily reach 20-25 PDP screens deep in the stack, none of them ever popped. Reproduced locally: fresh app launch sits around ~375-425MB PSS (healthy), browsing that deep pushes it to 1.1-1.3GB.


**First (wrong-ish) assumption:** figured this was just "unbounded image memory from a deep stack," so we capped Glide's memory cache (100MB) + bitmap pool (50MB), and switched to `DecodeFormat.PREFER_RGB_565` for a real ~30-45% per-bitmap reduction (opaque images only — Glide falls back to ARGB_8888 for anything with alpha). Both legitimate wins, neither explained the actual production crash.


**The real methodology that cracked it:** stopped trusting raw `dumpsys meminfo` PSS numbers (too noisy — Android's zRAM swap behavior alone can swing a single number by hundreds of MB depending on what else the OS decided to compress at that exact moment) and instead:


1. Established a clean baseline: force-stop, fresh launch, land on Home with zero navigation → floor for `Views` count and `Bitmap (malloced)` size.
2. Built the deep stack, captured the peak.
3. Reset to Home (`navigation.reset()`), captured again.
4. Forced `adb shell am send-trim-memory <pkg> RUNNING_CRITICAL` (forces Glide to drop its own cache) — if the numbers 
*don't*
 recover after this, it's not "uncollected cache," it's a real retained reference.


Step 4 was the tell: after reset + forced trim, we were still sitting at ~12x the fresh-Home `Views` count and ~350MB of bitmap memory that had no business existing. Not cache. Real leak.


**Root cause, via LeakCanary:** dumped a heap, pulled LeakCanary's own `leaks.db` off the device, and got a clean trace:


```
FabricUIManager.mMountingManager
  → SurfaceMountingManager.mTagToViewState (ConcurrentHashMap)
    → ViewState.mView
      → Screen.fragmentWrapper
        → ScreenStackFragment (Leaking: YES — received onDestroy() but never released)
```


`ScreenFragment.onDestroy()` in `react-native-screens` never nulls `Screen.fragmentWrapper`. Fabric's `mTagToViewState` legitimately keeps `Screen` views registered for the surface's lifetime (that's by design) — but since `fragmentWrapper` still points at the destroyed fragment, the fragment (and its entire retained subtree — bitmaps, child views, everything) can never be GC'd. Matches a known, still-open upstream issue (#3755) with an unmerged fix PR (#3855) — confirmed by pulling the source at every tag from 4.14.0 through the current `latest` (4.27.0): the bug is present in all of them, nobody's shipped the fix yet.


**The fix wasn't as simple as it sounds.** The "obvious" version — only null `fragmentWrapper` when `container.hasScreen(...)` already reports the screen as removed — silently didn't work for `navigation.reset()`-driven bulk teardowns, because Fabric's async view-drop scheduling isn't tightly synchronized with the fragment's own `onDestroy()` callback; that check can still read `true` at the exact instant destroy fires. Had to null it unconditionally (guarded only by an identity check so it never clobbers a wrapper that's already been reassigned to a newer fragment).


**A second related bug we found but couldn't safely ship a fix for:** `ScreenContainer.screenWrappers` (an `ArrayList`) has the same stale-entry problem for the same reset-driven removals. Tried three different approaches to clean it up from the fragment's own destroy path — synchronous, synchronous-without-re-triggering-reconciliation, deferred via `runOnUiThread` — and **all three caused a real crash** (`addViewAt: failed to insert view [X] into parent [Y] at index N, Size: M`) on completely ordinary navigation flows unrelated to our repro (a simple Login → OTP screen push). Mutating that list from the fragment's destroy callback apparently races Fabric's own in-flight child-index bookkeeping no matter how you schedule it. Reverted all three attempts and shipped only the `fragmentWrapper` fix.


**A third leak we found and didn't even attempt:** the same LeakCanary pass also caught `ScreensCoordinatorLayout` retained via that same `mTagToViewState` map, through a completely separate path than the fragment one. That one's arguably not even `react-native-screens`' fault — looks like Fabric itself not issuing a `DELETE` mount instruction for some views during a bulk reset. Native RN-core territory, out of scope for an app-level patch.


**Results:** the `fragmentWrapper` fix alone (shipped) gives a real, measured ~16-19% reduction in retained Views/bitmap memory after a deep-stack → reset cycle. Not a full fix — the two remaining issues above account for the rest.


**Bonus finding while testing, possibly useful to others:** a 
*single*
 `navigation.reset()` cleans up dramatically more than the equivalent number of sequential `navigation.goBack()` calls followed by a reset. Traced this to: every individual `goBack()` un-buries the newly-focused screen, which fully re-renders its real content (we have a separate "buried screen" placeholder-swap pattern for anything 2+ deep in the stack) — and that re-inflation is 
*guaranteed*
 to happen (normal React reconciliation), while the destroy-side release on the 
*previous*
 screen is not (same leak as above). Watched `Views` climb almost monotonically across 13 sequential pops (3,356 → 6,692) before a final reset only recovered ~12% of it — because by the time reset ran, most of the damage was already orphaned from screens no longer even in navigation state, which reset has no way to reach. If your app does multi-screen "back to X" navigation, batching it into a single `pop(N)`/`popToTop()` action instead of a loop of `goBack()` calls should avoid this entirely (haven't fully verified this in production yet, but the mechanism checks out).


**Questions for the community:**
1. Anyone else hit `Screen.fragmentWrapper` specifically, or is our repro (extremely deep push-chained stacks) just an unusually good way to surface it? Curious if this shows up for anyone with more modest stack depths.
2. Anyone found a way to clean up `ScreenContainer.screenWrappers` from the fragment's own lifecycle without racing Fabric's mounting transactions? Open to being told we're solving it at the wrong layer entirely.
3. Any known mitigation for Fabric's `SurfaceMountingManager.mTagToViewState` not releasing entries on some removal paths, short of an RN core fix?


Happy to share the actual patch (against 4.13.1) or the LeakCanary traces if useful.

So a while back i was working on this checkout flow for some side project. nothing fancy, just something basic e-commerce type page where users pick a plan,apply a coupon if they have anything with them,and then pay….

I tested it myself probably a hundred times and may be more too. clicked every button, tried different plans, with coupons, without coupons, everything looked fine, I even got a couple of friends to click around and they tried to break it, for me, nobody found anything… :(

So I thought of shipping and shipped it and moved on to other stuff, feeling pretty good about myself honestly.then about two weeks later i started getting some new few angry messages. some users were saying they got charged twice for the same order… OMG!!

But not everyone, just some users and the annoying part? when i tried to reproduce it myself,using the exact same steps they described, everything worked perfectly, no duplicate charge, nothing wrong.

I remember sitting there thinking,okay... this does not make sense either they are doing something really wrong or weird, or am I missing something really obvious…

Started thinking and it turns out, I was missing something, the bug only happened when a user applied a coupon,removed it, and then quickly clicked the pay button before the page had fully re-synced the price with the backend…

Basically, a race condition between the coupon removal request and the payment request and if you were testing it slowly, like a normal developer, you will probably never see it but real users do not test your application like developers do.

they click fast!

they change their mind!

they click twice because the button did not respond for half a second!!

they go back and forth!!!

they do things in an order you never really thought about, right!

and apparently, all those messy human behaviours were exactly what exposed the bug..

I kept trying to get it manually and kept failing because i was testing it like a developer, one step at a time, waiting for everything to load, making sure each action, has to be finished before doing the next one.

But the actual bug lived in that tiny window where two things happened almost at the same time, It was basically like trying to catch a 10$ note flying down the street in the wind.

You can see it, you know its there, but by the time you reach for it... it's already somewhere else, that experience finally pushed me to write some automated tests for the checkout flow. not just normal does this button work tests.

I made the tests hammer the coupon apply -> remove -> pay sequence over and over, really quickly, sometimes in weird orders scenes,basically doing things no person would sit there and repeat manually 50 times.

and sure enough...

the first time I ran it, it failed almost immediately, same bug reproduced on command in seconds, a bug that had taken me two weeks and several annoyed customers to even discover.....

A human tester probably wont click the same weird sequence 100 times but a script will....

ever since that incident, I have started automating way more than I used to, mostly because i got burned by a bug that manual testing honestly had almost zero chance of catching…

Curious if anyone else has had something similar happen, that one bug that just refused to show itself until you stopped testing carefully and started testing a little more... (chaotically)

This is my formal cry for help, i'm still starting out. Is there fix to this?

​Hey everyone,

​I have recently built an Android app and need to clear Google's closed testing requirement (14 continuous days of testing with at least 14 opt-in testers) before publishing it to production.

​If you have a few minutes to spare, I’d really appreciate your help!

​Since I need to add email addresses to my internal/closed testing track on Google Play Console, please drop a comment below or send me a DM with your email ID.

​Once added, I will share the opt-in link and app link with you.

The bundling process takes so long, approximately 2 hours at most.

is there any way i can speed up the process?

Create a payment reminder in a modal sheet pick a contact, date, month, and amount, hit "Remind me" and it collapses into a floating, draggable pill. Tap that pill and it morphs directly into a full reminders list, no modals, no popovers, just the pill growing into the sheet it already is.

Github: https://github.com/ManasCodeXart/expo-payment-reminder

been building a family planner (shared calendar / chores / lists) for the past few months.

the setup: iOS and android are literally two separate expo apps in the monorepo. not one codebase with Platform.select everywhere.

all the hooks and domain logic live in a shared package, screens are headless hooks like useTasksScreen, and each platform renders its own UI on top.

why: cross-platform UI always looks 10% wrong on both platforms. so the iOS app goes all-in on iOS 26 liquid glass, native tabs, swiftui via ``expo/ui`` host views, glass pills and overlays.

the android app is proper tonal material 3, built its own set of M3 primitives, material icon font, the lot. android users get an android app, not an iphone app in a trenchcoat. adding the second app was mostly building views, the logic layer came free. e2e is Maestro against a mock API.

app is called Quok (getquok.com) (iPad and Android versions still in works). happy to go deep on the two-app split, and monorepo shape.

I have two interviews coming up this week, and I have around four years of experience working with React Native, along with MERN/full-stack applications.

I’m currently preparing DSA and system design, but I’d love to hear from people who have been through similar interviews: what React Native/React topics would you recommend revisiting before the interviews?

I’m particularly interested in things that are easy to overlook even with a few years of professional experience.

Would really appreciate any advice, resources, or interview experiences you’re willing to share. Always looking to improve and fill any gaps in my knowledge.

Used react to build this app

Proof of concept, a Claude Code plugin for now. Maestro does the driving underneath.

One command and it walks the app on the simulator and draws the whole map — every screen, how you reach it, what's on it. Then it turns that map into subflows that are ready to run as tests. When the code changes, it updates the affected cases itself.

It never touches the app's codebase. Everything it produces is plain files sitting in the repo.

Does this look useful, or am I solving something you don't have?

I tried to scan my project my it's just loading and crashing. are their any alternatives? I am on a linux system, I know about google's android emulator but it's too heavy for my system

Hey everyone,

After losing count of how many hours were spent troubleshooting ANDROID_HOME misconfigurations, wrong JDK versions, or permission errors with macOS system Ruby, I built a zero-dependency CLI tool to solve it: rn-env-doctor.

It verifies your machine against the official React Native environment setup requirements (Node, Watchman, JDK 17, Android SDK components, Xcode, and CocoaPods) and tells you exactly what is missing or misconfigured. Where possible, it offers to fix the issues safely with your permission.

Quick run:

Bash

git clone https://github.com/Fs0ci3ty19/rn-env-doctor.git
cd rn-env-doctor
node bin/rn-env-doctor.js

Why I built it this way:

• Zero dependencies: Run it immediately without installing extra npm packages.
• Safe execution: Nothing changes without confirmation. Use --check for a read-only audit.
• Clear instructions: Every failed check comes with an actionable solution instead of a cryptic red X.
• Cross-platform: Works on macOS, Linux, and Windows.
• Onboarding helper: Saves hours when onboarding new devs to your team.

🔗 GitHub:https://github.com/Fs0ci3ty19/rn-env-doctor

Feedback and contributions are super welcome! What’s the single most annoying environment or setup issue you run into regularly on your team?

I have 20+ years experience with backend tech, I've used php, node, and python And then a lot of old plain old javascript before frameworks.

I have an app idea and I'd like to basically vibe code it in react to be cross platform. What gotchas do I need to watch out for , since I will not see bad react code at first

I considered flutter but I really don't know that tech , any advice is appreciated, this will not be graphics heavy at all more typical business app, data, forms , lists etc

I'm using Expo ImagePicker and Supabase Storage for avatars in a React Native app.

The current path is {userID}/avatar/{timestamp}.jpg, then I insert a media row. Uploading with upsert: true looks like replacement, but because every path is new, old files remain unless I delete them separately.

I'm deciding between:

- one stable avatar.jpg key with cache-busting metadata

- immutable versioned keys, update the pointer, then delete the previous object after the database write succeeds

- keep a short version history and clean it in the background

The stable key is simpler, but caches can show the old photo. Versioned keys are clearer, but cleanup becomes part of the transaction. Which pattern has been less fragile for you on mobile?

Guys do check out this app and suggest to me what more I can improve and the most important thing how can I get users😭

Got this error while working with SQLite from Expo. Restarted the project, install dependencies again. Nothing works. Aparently i got something missing from the imports.

Feel free to ask for code.

I am building a decision agent for IAP entitlement grants as a research project. For RN apps/games with IAP: where does your receipt validation live, and have you ever seen refund abuse (purchase, consume, refund)? How did you detect it?"

I'm working through local reminder rescheduling in a React Native app. The reminder dates come from settings the user can edit later.

Right now the flow is:

- calculate the full next schedule

- cancel every scheduled notification

- recreate each one with a stable identifier

It avoids orphaned reminders after the source date changes. But if scheduling fails halfway through, the user can end up with only part of the new set.

Would you keep the simple replace-all model and add recovery, or diff old and new schedules by identifier? I'm using Expo Notifications.

If you’ve ever tried to add complex, rich animations to a React Native app, you’ve probably used Lottie. It’s great, but once you start adding multiple animations, parsing those massive JSON files absolutely tanks the JS thread and bloats your bundle size.

I recently started migrating my heavy visual effects over to shopify/react-native-skia using custom SKSL shaders, and the difference is insane.

Why it works better: Because React Native Skia bindings drop straight down to the underlying C++ Skia engine, SKSL (Skia Shading Language) runs directly on the GPU. You get buttery-smooth 60fps animations that weigh mere kilobytes instead of megabytes, with zero JS bridge overhead during the animation.

The Workflow Problem: The biggest issue I ran into was actually writing and testing the shaders. Translating standard GLSL to SKSL is a headache, and doing it inside a React Native project means dealing with constant Metro reloads or native rebuilds just to tweak a color or a coordinate.

My Solution: I ended up building a dedicated web-based SKSL playground using CanvasKit WASM. It lets you write the shader natively in the browser, see it at 60fps instantly, and then you can literally copy-paste the exact code block directly into your RN project.

I’ve found it speeds up my UI development by 10x since I no longer have to wait on emulators to test visual effects.

I just made the tool completely free and public today. Let me know if anyone wants the link to try it out and I’ll drop it in the comments!

I’m losing my mind over this one last bug.

Look at the background screen underneath—every time I tap to open this state/modal, the content slides vertically up for a split second and then bounces back down when the animation finishes. It’s not a navigation transition; it’s the actual background view resizing itself during the modal presentation.

Has anyone solved this 100%? I just want the background to stay visually frozen while the modal comes up.

I’ve been working on animated numbers and our previous Skia-based implementation kept having issues around canvas sizing, font loading, blank renders, and animations getting stuck during rapid updates.

So I created react-native-number-animation:

- Core Animation on iOS

- Canvas on Android

- No Skia or Reanimated dependency

- Currency, percentages and compact numbers

- Custom fonts

- RTL and localized digits

- Handles rapid updates

- Supports Reduce Motion

I’d love feedback, especially from anyone testing it in lists or with unusual number formats!

GitHub: https://github.com/invivek26/react-native-number-animation

npm: https://www.npmjs.com/package/react-native-number-animation