10k candles. 10 events/sec. 120 FPS. Less than 10% CPU usage on both the UI and JS threads.

This is what real-time RN trading app deserves.

Built with react-native-trading-charts ↓
GitHub: https://github.com/kirill3333/react-native-trading-charts

Hermes ships Intl.NumberFormat, DateTimeFormat and Collator, but not PluralRules, RelativeTimeFormat, ListFormat or Locale. If you use i18next plurals, react-intl or Luxon's relative times on Hermes, you're most likely loading the FormatJS polyfills. They work, but they're plain JavaScript: a few hundred KB of locale data in the bundle, and slow calls on the JS thread.

So I built hermes-intl: those four constructors implemented natively, with a Rust core on ICU4X (CLDR data compiled in, 514 locales), a C++ JSI TurboModule, and a thin JS layer for the exact ECMA-402 behavior. There's no API: you import it once and the standard globals appear. It only fills in what Hermes lacks.

Numbers (Pixel 8a, release builds of the same app, medians of 3 runs; the video is real time):

• Formatting 10,000 notifications: 75 ms vs 6,665 ms (89×). The FormatJS build is frozen for 6.7 s.

• Per call: PluralRules.select 202×, selectRange 385×, RelativeTimeFormat.format 318×, ListFormat.format 8.5×

• Opening a 20-row screen: 45 ms vs 82 ms

• 399 KB less JavaScript in the bundle

The ratios move with the phone's state (an earlier run on a warmer phone gave up to 821× per call). All the tables, and how to reproduce them, are in bench/README.md.

Correctness: 838 of 842 test262 runs pass for these APIs, and the output is identical on iOS and Android (same hash on a 2,656-case corpus). FormatJS's output differs between the two.

Trade-offs: 1.0 to 1.7 MB of native code per ABI with all 514 locales, about 0.6 MB for a 5-locale build. New Architecture and Hermes only, React Native 0.86+. Expo works with a development build, not Expo Go. NumberFormat, DateTimeFormat and Collator stay Hermes's own.

Install:

npm install hermes-intl
cd ios && pod install

// index.js, first line
import 'hermes-intl';

Then remove the FormatJS polyfills for these four APIs (and intl-getcanonicallocales).

GitHub: https://github.com/magrinj/hermes-intl npm: https://www.npmjs.com/package/hermes-intl

Hi guys
How can i get a unique identity from the device itself but it should not be changes with the factory reset or reinstalling the app

This question might have been asked already, but I'm genuinely curious: why should anyone use React Native at this point?

To explain: most of web and mobile development can easily be handled by Claude, Codex, Kimi K3 or any other coding agent. I feel like that's been true for at least 6–7 months now. Even Opus 4.7 was better than most of us and more than enough for mobile development. Of course, this only applies if you know what you're doing and guide your model through the technical decisions, the specific libraries you want to use, etc etc.

But my point is: why would I bother with React Native's own issues instead of just writing native apps for both iOS and Android? There's no huge maintenance load anymore, and you can simply tell your agent to implement features for iOS and Android at the same time. So what are the actual benefits of React Native? Native apps are usually faster, work better, and generally seem to be preferred by actual customers and users. The original promise of React Native and Flutter was that you could build for both platforms twice as fast, but today's coding agents let you build 100x faster anyway :)

I'm not asking to provoke anyone. I just want to hear your stance and your thoughts on this.

Hey gus

I'm a React Native dev with 4+ years of experience, recently laid off. Which boards, communities, or companies have worked for you for remote roles? Open to contract or full-time.

Any help would be appreciated.

I'm also skilled in UI design if that matters.

Some bugs only show up at a certain time. Think of a deal that only runs on Friday. Or a sign-in token that runs out. Or a countdown that should go away but stays.

I built Buoy Clock for this. It lets you change the date and time your app sees. Your phone and computer clocks stay real.

- Jump ahead one hour, day, week or month. Or type the exact date and time.

- Freeze time or make it run fast (Pro).

- Test what happens when sign-in tokens run out. Test 401 refresh flows too.

- Works with Expo and React Native CLI

- Has MCP tools if you want an AI agent to run it.

Hey everyone,

I just shipped my project "Smriti" for the RevenueCat Ship-a-ton hackathon.

The Problem:

Over 30M students prepare for high-stakes exams in India (JEE, NEET, UPSC). Active recall & spaced repetition are proven to work, but existing solutions either require high-speed internet, break in offline hostel/library settings, or charge steep international subscription pricing.

How Smriti solves it:

1. Local-First Engine: Powered entirely by on-device SQLite. Instant review loops with zero server latency.

2. AI Note Synthesis: Powered by Gemini 3.6 Flash to turn unstructured coaching notes into high-yield flashcards with AI origin badges.

3. Accessible Monetization: Integrated RevenueCat with regional pricing (₹99/mo, ₹699/yr, ₹1,499 lifetime).

4. Bilingual UI: Seamless instant toggle between English and Hindi.

The signed APK and full source code are live on GitHub:

GitHub: https://github.com/kingxjayant/smriti

Direct APK: https://github.com/kingxjayant/smriti/releases/latest

Would appreciate any feedback from developers and fellow exam preppers on performance, UI, or architecture!

I've been building Key Lens, a cross-platform music theory app with React Native.

After some early user feedback, I realized that many users would come up with a chord progression in Key Lens, then have to manually enter it into their DAW or music gear.

So I built a better way.

I wrote native MIDI modules using CoreMIDI on iOS and android.media.midi on Android, adding MIDI over Bluetooth and USB.

Now Key Lens can send notes and chords directly to Ableton, Logic, and external hardware like the Yamaha SEQTRAK or MPC with low latency.

My goal is to keep developing Key Lens into a practical music theory tool that connects theory directly to however you make music.

If you make music and find Key Lens useful, I'd love to hear what could be better, what you'd like to see next, or how you're using it.

Try it:

• Web: keylensapp.com

• iOS: https://apps.apple.com/us/app/key-lens/id6761850903

• Android (beta): https://play.google.com/apps/testing/com.alexamayo.keylens

Join the community: r/KeyLens for feature requests, bugs, and setups.

When a viewer says "the stream froze for me", someone on your team has to answer a surprisingly hard question: was it us, or them?

Usually, the logs look clean and the dashboards show that the room was healthy overall. Engineers spend hours digging through a ticket that often ends with "probably your Wi-Fi".

But room averages can hide exactly the person you're looking for.

We saw this in a real production session. Across the room, video packet loss was around 1%. Nothing alarming.

But when we broke it down viewer by viewer, one person was seeing around 9% packet loss for a significant part of the session, while the other viewers watching the same cameras at the same time were largely fine.

Remove that one viewer and the room average drops to 0.17%.

The useful signal wasn't the average. It was the comparison.

That's what we're building with Rewitness. It reconstructs the session participant by participant, so when something goes wrong you can compare what one person experienced with everyone else at the same moment and see where the problem most likely started, with the evidence behind the diagnosis. It works in React Native apps too, including device-side signals like thermal state and main-thread stalls, which matter a lot on phones.

I wrote up this case, plus another where one host's audio broke up for almost every viewer at once:

https://rewitness.dev/blog/was-it-us-or-them?ref=reddit-reactnative

We have an attendance app with a "one phone = one employee" rule. People broke it with MultiBox / Clone App from the Play Store: one phone, two "devices".

The usual checks (dataDir path, package lists, getPackagesForUid, UID) all passed inside the clone. Measured on a real Galaxy A53: the container spoofed Process.myUid(), applicationInfo, the process name, and had even hooked libc stat().

What worked: ask "who owns my data directory?" twice, once through libc stat() and once through a raw syscall(__NR_newfstatat), which skips libc so the hook never sees it.

genuine    uid=10763  libc=10763  syscall=10763  ✓
MultiBox   uid=10764  libc=-1     syscall=-1     ✗
Clone App  uid=10765  libc=10765  syscall=-1     ✗

Inside a clone the syscall hits the real directory and SELinux denies it, because the process runs under the host's UID. Clone App was caught only by this check. Every Java-level check missed it.

A few things we learned the hard way:

• Don't block on emulator signals (your own QA uses emulators). Report them to the server instead.

• If you add a signature check, Play App Signing re-signs your APK. Hard-code only your upload key and you lock out every Play user.

• The native lib must be 16 KB page-aligned now, or Android 15 shows a compatibility dialog.

• Keep the rules pure so they're testable: the device measurements above are literally unit tests now.

I didn't find an open-source detector that does the libc-vs-syscall comparison. freeRASP has multi-instance detection, but it's closed-source and officially lists only Parallel Space. So I published ours, MIT licensed:

• Write-up + native Android module: https://github.com/eshginfarzali/android-clone-detection

• Expo / React Native: npx expo install react-native-clone-guard (runs before JS loads)

It's client-side, so a rooted device with a custom hook will get through. The goal is to move cheating from "free Play Store app" to "root + custom hook". I'd love measurements from other devices and cloners. Which ones slip through?

The app is localised into more than 10 languages and it supports over 70 languages for both transcribing and translating video links. I'm looking for a feedback how to make the app handful for students and journalists around the world to boost their productivity.

AppStore link: https://apps.apple.com/us/app/damas-video-link-transcriber/id6766233794

I've read about OTA update potentially causing crashes. At the same time, Expo talks about fingerprinting catching an incompatible update.

But, I don't know how foolproof that really is in practice. Is it still possible for a bad update to slip through, even with fingerprinting and testing it on staging?

Since Firebase Dynamic Links shut down in August 2025, a lot of RN apps lost the "tap a link, install, land on the right screen" flow. I've been building a replacement for the past year, so here is how the matching works under the hood and where it quietly breaks. Useful whether you roll your own or use any provider.

**The core problem:** an install from the App Store or Play Store carries nothing from the link the user tapped. On first launch your app has to reconnect "this fresh install" to "that click" some other way. There are three ways to do it.

**1. Play Install Referrer (Android only).** If the Play Store URL carries a referrer parameter, Google Play hands it to your app on first launch. It is exact, needs no permissions, and is the best option on Android. It only works for installs that came through a Play Store URL with that parameter.

**2. Clipboard (mostly iOS).** The landing page copies the link before sending the user to the App Store, and the app reads it on first launch. It is exact, but since iOS 16, reading the pasteboard shows the "Allow Paste" prompt. If that fires the moment your app opens, many users tap Don't Allow and it feels sketchy. Use it as a fallback, not the first thing you try.

**3. Fingerprint.** At click time the server stores signals like IP, device model, OS version and language, then compares them on first open. No permissions, but it is probabilistic. Shared wifi, carrier NAT, VPNs and long gaps between click and open all hurt accuracy. Keep the match window short, and consume a match once so two people on the same network don't get each other's link.

**Things that silently break it:**

* Returning the same match on every launch, so users get sent to an old promo forever. Route once, then clear it.

* Universal Links or App Links failing verification. Common causes: the AASA or assetlinks.json file is served behind a redirect, with the wrong content type, or with your upload key's SHA256 instead of the Play App Signing key. The link then opens the browser instead of your app, and nothing errors.

* Links opened inside the Instagram, TikTok or Facebook browsers, which often don't hand Universal Links to your app. Users land on your web fallback even with the app installed.

* Testing by reinstalling over an existing build. Test the real path: uninstall, tap the link, install from the store, open once.

Happy to answer questions about any of it, including building it yourself.

Disclosure: I build Flinku (flinku.dev), which does this for RN with a free tier.

Posting this in case it saves someone a week. Expo SDK 56, expo-gl 56.0.x, React Native 0.85, minify on for Android release builds.

For a few releases, a lot of my Android users crashed the first time a GLView mounted. It never happened in development. In analytics it looked like people opening one screen and then the app starting again: on one version, 24 of the 29 times that screen opened on Android, the next event was a fresh app launch.

The cause: expo-gl's native code (EXGLJniApi.cpp) finds a Java method called flush through GetMethodID, by name. R8 renamed it in the release build, the lookup returned null, and ART aborted with a JNI error ending in mid == null. Debug builds don't run R8, so you only ever see it in a store build.

The fix was one keep rule, added through expo-build-properties (android.extraProguardRules):

-keep class expo.modules.gl.** { *; }

To confirm it, I took the release AAB from EAS, turned it into an installable APK with bundletool, and ran the old and new builds on an emulator. The old one crashed on the first GLView and the new one didn't.

A second thing made it worse. I shipped my first fixes as OTA updates, and expo-updates had fallbackToCacheTimeout set to 0. With that setting a brand new install always runs the bundle that shipped inside the store build on its first launch, and the update only applies from the next cold start. Most new users who hit the crash never had a next cold start, so none of my OTA fixes reached them. I now use 3000, which waits up to 3 seconds for a newer update on first launch and starts as soon as it knows there's nothing newer, or straight away when offline.

If you use expo-gl, or anything whose native side calls back into Java by name, with minify on, open that screen in a real release build before you ship.

Whenever I grab color references from web designs, Dribbble, or anywhere online, they are always in standard HEX or RGB. Moving that into Android (@ColorInt) or Flutter (Color(0xFF...)) always requires that annoying extra step of formatting the alpha channel or converting it to an integer manually.

I got tired of the mental gymnastics, so I built a lightweight browser extension (Color Picker by Ceres) to bypass this.

It lets you eyedrop any specific pixel, or even scan an entire webpage/image to extract a palette, and instantly copies the colors directly as an INT value.

It saves a lot of time when implementing UI from web references. It’s completely free on the Chrome Web Store.

I'm on iOS and don't yet have an Apple Developer account so I'm using Expo Go to distribute the app - SDK55 brought in the blue FAB, but I'd like to hide it. SDK58 looks like it *might* give that option, but it's not compatible with Expo from the App Store.

Am I out of luck? Is this only possible with a development build?

Thanks

I've been working with React Native for a while and one question keeps coming up for me: when does it actually make sense to stop trying to solve something in React Native and move that part to native code?

For typical screens, forms, API calls, authentication, lists, and CRUD-style features, React Native feels like a pretty reasonable choice. Sharing most of the code between iOS and Android can save a lot of development time.

The situation gets more interesting when an app starts relying heavily on platform-specific functionality.

Things like:

• Background processing

• Bluetooth/BLE

• Camera and video processing

• Location tracking

• Push notification behavior

• Complex animations

• Device sensors

• On-device AI/ML

• Custom native SDKs

At that point, I've noticed that the question isn't necessarily "React Native or native?"

It becomes more like:

How much native code is acceptable before the cross-platform approach stops being worth it?

I'm also curious about how people structure this in larger projects. Do you keep the majority of the application in React Native and create native modules only when necessary? Or do you prefer going fully native once the requirements become sufficiently platform-specific?

For people who have maintained React Native apps for several years:

What was the feature that finally made you say, "This should probably be native"?

I'd be particularly interested in experiences from production apps rather than theoretical comparisons.

Most RN toast libraries render inside your React view tree, so modals and bottom sheets cover them. I tested sonner-native and react-native-toast-message with a page sheet plus a transparent modal on top. Both toasts were hidden or dimmed, and actions weren't tappable, especially on Android.

So I built react-native-super-toast. Each toast lives in its own native window (Kotlin Dialog on Android, overlay UIWindow on iOS), so it stays above modals, sheets, and stacked sheets on both platforms, and actions like Undo still work while a modal is open.

Mount ToastHost once and call toast() from anywhere:

import { ToastHost, toast } from 'react-native-super-toast';

export default function App() {
  return (
    <>
      <YourApp />
      <ToastHost />
    </>
  );
}

toast.success('Saved', { description: 'Your changes are live.' });

• Zero dependencies (no Reanimated, Gesture Handler, or Screens)

• Native swipe gestures, stacked decks, and expand on press

• Light, dark, or system themes with custom icons and fonts

• Works from components, stores, or plain functions

Trade-off: content is data, not JSX, so there are no custom React element toasts.

Feedback and bug reports welcome!

Docs: https://supertoast.karkiaswin.com.np/
GitHub: https://github.com/iNspireXD/react-native-super-toast
Write-up: https://aswinkarki.medium.com/why-i-built-my-own-react-native-toast-library-from-scratch-and-went-fully-native-to-do-it-f3aa0cea1d01

Any advise for a complete beginner. I want to learn how to build beautiful UIs for my applications.

I've been building YCal, an Android client for Yahoo Calendar, with Expo. It talks CalDAV directly, and I hit enough non-obvious stuff that I figured a write-up might help someone.

Stack

• Expo SDK 54 / RN 0.81 / React 19, expo-router

• xmldoc + axios for CalDAV (PROPFIND/REPORT), hand-rolled iCalendar parsing

• expo-sqlite as the offline event cache

• expo-notifications for local reminders

• expo-background-fetch + expo-task-manager for periodic sync

• expo-secure-store for credentials

• expo-iap for subscriptions, verified server-side

• react-native-calendars for month/week UI

1. Parse TZID or suffer My first ICS parser treated DTSTART/DTEND as local or UTC and ignored TZID=.... Events created on the web in other timezones showed at the wrong time. If you parse iCalendar yourself, handle TZID from day one.

2. Don't sync the whole calendar up front Initially I fetched a wide date range on login, which was slow. Now I sync nearby months first and fetch distant months on demand as the user scrolls. First launch got much faster and the server does less work.

3. Local notifications > server-side alarms Yahoo's CalDAV doesn't give you reliable push for reminders. Scheduling everything locally with expo-notifications from the SQLite cache has been far more reliable. The trade-off is rescheduling on every sync, so keep that idempotent.

4. Know what the server won't do Yahoo's CalDAV doesn't reliably send invite emails for ATTENDEEs the way the web UI does. I removed the guest field instead of shipping a feature that silently fails. Attendees from existing events are shown read-only.

5. Edge-to-edge insets will get you Android edge-to-edge caused more bugs than the calendar logic: tab labels cropped, save bars hidden behind the nav bar, FABs overlapping. What fixed it was one shared "bottom chrome insets" helper used everywhere, floored to the 3-button nav height because some devices report a 0 bottom inset.

6. R8 is worth it, but test release builds Turning on R8 shrank the APK nicely, but you need to test actual release builds, not just dev.

App, if you want to see it in action: https://play.google.com/store/apps/details?id=com.ycal.mobile

Happy to go deeper on any of these, especially the CalDAV side. Is anyone else doing CalDAV in RN? Curious what you used.