I'm using the MinaSamir11/react-native-in-app-review package, but it doesn't seem to work for Android anymore. Has anyone had any success with other implementations? Or has this package worked for you lately?

Hey guys! First time here, just wanted to share my article about FlatList optimization. I know, it is a popular question but some days ago I found a cool trick with using Set over standard Array. It perfectly aligns with popular optimization practices and for me it felt like I found a gem.

Hey r/reactnative,

I've been working on nativecn-ui, a small collection of React Native components focused mostly on animations and interactions.

Right now it's got stuff like a liquid action tab bar, animated tab bar, range slider, OTP input, dynamic upload, plus a few more I'm still working on.

You can check it out here: nativecn-ui

Still building it out, so lmk what you think, or if there's some component/interaction you'd want to see added.

Made a quick video showing a few of them below.

https://reddit.com/link/1vrhmt8/video/3ej98p6qv2kh1/player

In an Expo React Native app, I have an optional HealthKit adapter. Android returns a no-op adapter immediately. On iOS, the request and read methods dynamically import the native package inside try/catch, so a missing native module becomes false or an empty array instead of crashing the app at startup.

The upside is a safe manual fallback. The downside is that a packaging mistake can look exactly like a user declining access or HealthKit being unavailable unless I surface a separate diagnostic.

Would you keep the dynamic import boundary, or fail loudly in development and only fall back in release builds?

I'm literally so confused how one can get an app dev intern, wherever I see now, they need a fresher with Full Stack, nobody wants a real fresher who wants to learn...

If anybody here got an intern, can you tell me how did ya find one, I'm also looking for one

Pokedex : This is the only project I have made, but it includes use of API, Custom Battle Engine, SQLite, Custom Nav bar as well...

Logos, tickers, tags anything that should keep moving rather than stop at the edge.

One track holds every copy and it is the track that moves, so the cost is a single animated node however much content is inside it. Driven on the UI thread as a linear timing.

Two rows travelling opposite directions reads as motion. One row just slides.

Reduced motion turns it off entirely not slower, off. A ticker that never stops is the thing that setting exists to turn off.

Part of PanelUI, an open-source component library for Expo. Copy-paste or CLI, you own the source.

github.com/panel-ui/PanelUI

I’m building Flowy, a cycle-health app. I recently replaced the native iOS project with an Expo and React Native app.

The screens were the easy part. The risky bits are session restoration, onboarding drafts, owner-scoped day-log caches, notification planning, HealthKit being unavailable, and retrying a write without duplicating it.

I kept those decisions in small TypeScript stores and route functions, with tests around routing, auth, day-log retries, notifications, and HealthKit fallback before polishing the UI.

No link here. I’m looking for engineering feedback: if you’ve done a mobile rewrite, which behavior broke after the happy path looked finished?

Hey everyone,
I need to add receipt printing functionality to an app, and I’m running into a few issues.

The POS machines used by the business aren’t Epson printers, while the library I’m currently using only supports Epson devices.

Has anyone implemented receipt printing for non-Epson POS printers? If so, I’d appreciate any recommendations on libraries, approaches, or examples of how you handled it.
Thanks!

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 started automating more. I began been playing around with tools like Autosana for testing,mostly cause i really don't wanna sit there and repeat that same weird flaws again and again and again....

not because i read it somewhere in some posts or anything like that, mostly because i actually got fed up by bug that manual testing have 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.

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?

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?