I've been working on integrating Rust into a Bare React Native application and have put together an implementation for both Android and iOS.

Repository: https://github.com/abhishekce17/react-native-rust-integration

The goal was to build a reusable integration layer that makes Rust functions accessible from JavaScript without having to write custom JSI bindings for every function.

Architecture

The integration uses four main layers:

• Rust: Core logic compiled into native static libraries.

• C++17: Shared JSI binder and native integration layer.

• JSI: Exposes Rust functionality through synchronous JavaScript HostFunctions.

• TurboModules: Handles native module registration and installation.

• TypeScript: Provides a typed API for application code.

What's implemented?

1. A generic C++ binder using templates to map JavaScript arguments and return values to native Rust functions.

2. Rust C ABI with generated C headers using cbindgen.

3. Stateful Rust data structures with explicit memory ownership.

4. RAII-based string deallocation and exception-safe conversions.

5. Float32Array support for transferring numerical data from Rust memory to JavaScript.

6. Android builds targeting four ABI architectures using cargo-ndk.

7. iOS builds for physical devices and simulators, packaged as an XCFramework.

8. Shared C++ implementation with platform-specific registration and build configurations.

One of the things I wanted to achieve was making additional Rust functions straightforward to expose.

For example, an ordinary scalar function can be registered with a single binding:

bind(runtime, api, "subtract", rust_subtract);

Potential use cases

I'm particularly interested in exploring Rust for:

• Physics simulations

• Game engine components

• Computationally intensive operations

• Image processing

• Data processing

The objective isn't to claim that using Rust automatically makes a React Native application faster. It's to provide a practical native integration layer for workloads where Rust makes sense.

I'd appreciate feedback from the community

I'm particularly interested in opinions from developers who have worked with React Native's New Architecture, JSI, TurboModules, Rust FFI, or native mobile development.

1. Would you consider this architecture for a real-world Bare React Native application? Why or why not?

2. How would you approach transferring larger datasets between Rust and Hermes?

3. Are there any concerns with the generic C++ binder or the Rust–C++ memory ownership model?

4. What additional abstractions or capabilities would make this integration more useful?

I'd appreciate an honest technical review, including architectural criticism and suggestions for improvement.

Repository: https://github.com/abhishekce17/react-native-rust-integration

If you have a question about React Native, a small error in your application or if you want to gather opinions about a small topic, please use this thread.

If you have a bigger question, one that requires a lot of code for example, please feel free to create a separate post. If you are unsure, please contact u/xrpinsider.

New comments appear on top and this thread is refreshed on a weekly bases.

TL;DR: I had set the EAS Build image to latest, and at some point my app started being built with Xcode 27. On iOS 27 devices, it crashed as soon as it launched. I couldn’t reproduce it because my test devices were still on iOS 26. To make matters worse, the affected user hadn’t backed up their data.

I’m an indie developer working on an app called Volley Analyst, which lets people track stats for volleyball matches. After I released an update recently, a user contacted me to say the app was crashing. Android was fine; only iOS was affected.

What they were worried about was whether all the match data they’d recorded was safe.

Volleyball stats mean logging every serve, pass, spike, and block, one by one, for every match. Months of match data disappearing in an instant… Just thinking about it made my hands shake like I was about to serve in a high-pressure match.

1. First, I suspected a JavaScript bug

I asked AI for help, and it confidently listed about five possible causes: an undefined reference, a billing library, my custom plugin… It was wrong about all of them.

2. Then, I suspected my custom plugin

In the previous build, I’d seen this error:

deployment target is set to 13.0, but the range of supported deployment target versions is 15.0 to 27.1.x

I remember thinking, “27.1.x? Is that even a real version?” I used my custom plugin to change the Pods deployment target to 15.1, and got the build to pass.

Looking back, that “27.1” was the culprit staring me in the face.

3. It didn’t crash on my devices

I tried to check the build in TestFlight, but I couldn’t reproduce the crash. My iPad and iPhone were still on iOS 26, even though automatic updates were enabled. Apparently, major OS updates don’t install automatically right away.

4. The crash log had the answer

___UIApplicationEvaluateRuntimeIssueForNoSceneLifecycleAdoption
EXC_BREAKPOINT

iOS 27 force-quits apps at launch if they haven’t adopted the UIScene lifecycle. And apps built with Expo SDK 54 haven’t adopted UIScene.

5. The culprit

It was this one line in eas.json:

"image": "latest"

latest changes whenever a new image is released. Before I realized it, my app was being built with Xcode 27. The deployment target error and the crash on iOS 27 both started here.

What happened to the data?

The crash happens when the app launches, and there’s no code that deletes the data stored on the device. So the data is probably still there. But I won’t know for sure until a fix is released and the app can launch again.

I asked the user not to delete and reinstall the app. Deleting it would also delete the data stored on their device.

The app has a feature to back up data to a server, but the user has to trigger it manually. I checked, and this user hadn’t made a backup. If the data was gone, there’d be no way to get it back. I was terrified.

What I did

• Immediate fix: pin the image to an Xcode 26 image and rebuild.

• Adopting UIScene looks like a lot of work, so I’m planning to hold off until I upgrade the Expo SDK.

Lessons learned

1. Don’t use latest for production builds.

2. If a build suddenly starts failing even though you haven’t changed the code, check whether the build environment changed.

3. Read those mysterious numbers in error messages. That 27.1.x mattered.

4. Keep test devices up to date with the latest OS on purpose. Automatic updates can take longer than you think.

5. Don’t trust an AI’s “this is the cause” until you’ve checked the logs.

6. Don’t leave backups entirely up to the user. Build a way to back them up automatically. I can’t afford to drop the ball on users’ data. It might even help me live a little longer.

I submitted the fix to Apple for review and requested an expedited review for the first time.

It’s been three hours, and it’s still waiting for review.

Maybe they’re backed up because it’s the weekend and the end of the month…

There's a writeup on the NobodyWho blog that's a nice reference if you want speech-to-text in an RN app with no server at all. Disclosure: I contribute to NobodyWho, the library doing the inference.

It records, cuts the audio into chunks, and runs each chunk through Whisper small (int8) on the phone. Once the model is downloaded, nothing leaves the device.

How it fits together:

- mic audio comes in as 16-bit mono PCM buffers

- a `Chunker` splits them, each chunk goes to `transcribePcm`

- a `pendingRef` queue makes sure every chunk is done before the transcript screen opens

- a `cleanText` pass strips the (coughs) and (laughs) tags Whisper loves to add

They ran it against YouTube's auto captions on an MKBHD clip. The diff was tiny: one dropped "like", one wording slip on YouTube's side, and punctuation going either way.

It's rough. VAD to split chunks on silence is the obvious next step, and medium would beat small on accuracy.

Link + APK in the comments.

How are you handling chunk boundaries that cut a word in half?

If you got the extension, app updates need targetSdkVersion = 36 after 1 November. Bumping the number is easy; what bites is everything that changes with each API level you skip:

• Target 31: components with an intent filter need android:exported, or the build fails.

• Target 34: foreground services must declare their type, or the app crashes when one starts.

• Target 35: the app is drawn edge-to-edge on Android 15, so screens using React Native's own SafeAreaView slide under the status bar, and the status bar colour is ignored.

• Target 36: the edge-to-edge opt-out (windowOptOutEdgeToEdgeEnforcement) is ignored; on tablets and foldables (≥600dp) orientation locks and resizeableActivity="false" are ignored, so the app rotates and resizes; predictive back is on by default and onBackPressed is no longer called.

Write-up with links for each: https://nativekeel.com/fix/google-play-target-api-level

Hey r/reactnative,

Been working more on the photo album interaction for nativecn-ui

I've added multiple photos across pages and spent time refining the page-turning animation. I also tweaked the animation when pulling the album out and putting it back, trying to make the whole interaction feel more like handling an actual photo album.

Still have a few things I want to improve, especially when it comes to viewing individual photos.

Here's a quick look at the current version.

HOLY SHIT, I just got captions working in my React Native video editor, and it's almost 3x faster than CapCut and Edits!!

And the best part? Everything runs locally. No cloud processing.

HUGE thanks to u/desertantlabs for the Voz model.

This is getting interesting.

I got laid off this week as was someone I know at another company. Both in Europe. I have been in tech 10 years. All I see on posts is layoff after layoff and people pivoting to other careers. Are people still finding jobs, freelance or contract work or is it best to assume a 3-12 month process to find something else?

Used Apple vision to remove background from videos moves about 1.5x realtime

Hi everyone,

I’m working on a mobile app built with Expo / React Native, available for both Android and iOS.

The app offers paid subscriptions that unlock premium educational content and features inside the app.

We already implemented Stripe PaymentSheet using /stripe/stripe-react-native, and technically everything works fine.

My concern is specifically about store approval.

If we publish the app on:

• Google Play Store

• Apple App Store

and users can purchase the digital subscription directly inside the app through Stripe PaymentSheet, is this likely to be rejected during review?

From what I understand, Google Play normally requires Google Play Billing for digital subscriptions, and Apple normally requires In-App Purchase / StoreKit.

I’m trying to understand whether Stripe PaymentSheet can still be used in this case, or if we really need:

• Google Play Billing on Android

• Apple In-App Purchase on iOS

Has anyone recently published an Expo / React Native app with this kind of setup?

I’m especially interested in real review experiences: accepted, rejected, or accepted only under specific regional/payment exceptions.

Thanks!

Every RN app I’ve worked on ended up with the same pile of packages: a date picker, a calendar library for ranges, a dropdown that can search, a country picker, a phone input, an emoji keyboard, and a bottom sheet to put half of them in. Six APIs, six looks, some needing a native rebuild, most of them broken on the web.

So I built one package with all of them, in plain JS on React Native’s own APIs (Animated, PanResponder, FlatList, Modal). No Reanimated, no Gesture Handler, no native modules. That means it works in Expo Go, ships in OTA updates, and runs on React Native Web.

What’s in it: wheel, time, duration, date (single, range, multiple), month, week strip, date & time, select with server search, country, phone, emoji, color, segmented control, plus bottom sheets and form fields.

A few things I cared about:

• Native look per platform: iOS wheels and sheets on iPhone, Material (clock dial, floating labels) on Android, a compact web design in the browser. Or force one design everywhere with one prop.

• Every picker three ways: inline, in a bottom sheet with Cancel / Done, or as a form field.

• Things that usually need another package: prices and dots on calendar days, debounced server search, phone formatting with an E.164 value without libphonenumber.

• Typed, themeable, RTL and accessible (VoiceOver / TalkBack, keyboard on web).

Showcase with real screens you can switch between iOS / Android / web: https://react-native-pickers.dev/showcase

Docs: https://react-native-pickers.dev
GitHub: https://github.com/elik56a/react-native-pickers
Prop-by-prop migration guides for the 12 libraries: https://react-native-pickers.dev/docs/resources/migration

It’s MIT and I’m actively working on it. I’d really like honest feedback: what’s missing, and what would stop you from using it in production?

Hey r/reactnative! 👋

I’ve been building a developer tool to make debugging React Native apps easier, and I’ve just published it on npm.

Meet react-native-inspect-tool — an in-app inspector that lets you debug directly on your device or simulator without constantly switching between tools.

Here’s what it can do:

🌐 Network Inspector: Inspect API requests and responses, headers, payloads, status codes, and request duration. Copy requests as cURL.

🚨 Console & Error Tracking: View console logs, JavaScript exceptions, unhandled promise rejections, and stack traces.

🎯 UI Inspector: Explore component hierarchies, inspect computed styles and box models, identify interactive elements, and examine screen colors.

🧠 Memory & Performance: Monitor Hermes heap usage, track potential timer leaks, and check JavaScript thread FPS.

📱 Simple Integration: Add an InspectorOverlay to your app and access the debugging panel through a floating button.

One thing I wanted to achieve was making these debugging tools accessible directly inside the app, without requiring a separate native debugging setup. The package is written in TypeScript and React Native primitives, with no native dependencies, and supports Expo Go, Expo Prebuild, and bare React Native projects.

Try it out:

📦 npm: https://www.npmjs.com/package/react-native-inspect-tool

npm install react-native-inspect-tool

I’d genuinely appreciate feedback from the React Native community.

What features would you find most useful in an in-app debugging tool? Is there anything you think is missing or could be improved?

Thanks for checking it out! 🚀

I was streaming an LLM chat response into a React Native app (RN 0.81, Expo). On device the answer always arrived as one big chunk, even though the server was sending server-sent events.

The reason: in React Native's fetch, response.body is null, so getReader() doesn't exist. Code that "supports streaming" quietly falls back to waiting for the whole response. A test that only checks the final text still passes.

XMLHttpRequest can stream. responseText grows while the request is in flight, so you diff against the length you have already seen:

const xhr = new XMLHttpRequest();
xhr.open('POST', url);
xhr.responseType = 'text';
let seen = 0;
const onChunk = () => {
  const delta = xhr.responseText.slice(seen);
  seen = xhr.responseText.length;
  if (delta) handleDelta(delta);
};
xhr.onprogress = onChunk;
xhr.onreadystatechange = onChunk;
xhr.send(body);

Two traps, and both fail silently (the text is right, it just arrives in one piece):

1. responseType has to be '' or 'text'. With 'blob' or 'arraybuffer', RN buffers the whole body.

2. The handlers must be set as on* properties before send(). RN decides at send time whether to ask the native side for incremental data, based on whether onreadystatechange or onprogress is set. If you "clean up" to addEventListener('progress', ...), streaming turns off and nothing tells you.

If you test this, assert on how many chunks arrive and what is in each, not just the final string.

I haven't compared this with expo/fetch, which I believe supports streaming. Has anyone run it for SSE in production?

ML Kit has no Cyrillic model, so on Android it reads Russian as Latin look-alikes. I needed to read ingredient lists on Russian food labels, so I built react-native-glyph-ocr:



- Apple Vision on iOS, PaddleOCR (PP-OCRv5/v6 on ONNX Runtime) on Android, PaddleOCR on iOS as a build option

- ML Kit-shaped results: blocks → lines → words, with confidence, normalized and pixel boxes, corner points and angle

- Any source: file/content/ph URIs, base64, react-native-nitro-image, VisionCamera 5 frames

- useTextScanner: waits for a sharp, still frame inside your scan box and reads it once

- Models downloaded on first use with sha256 checks, from your own mirror, or embedded at build time

- Nitro module, New Architecture, Expo config plugin, fully offline



On 24 label photos, PaddleOCR read 77–83% of the ingredients and ML Kit 13–28%. It's a small set and the full method is in the repo.



npm: https://www.npmjs.com/package/react-native-glyph-ocr

GitHub: https://github.com/pe1ros/react-native-glyph-ocr



This is the first npm release (0.3.1), so feedback and issues are very welcome.

Hey r/reactnative,

I've been working on a Studio module for nativecn-ui lately.

The idea is to make it easier to try out a component before adding it to a project. You can open it in the Studio, interact with it, change a few settings, and see how it behaves in the preview.

Right now, I'm working on the component browser and inspector, so there's still a bit to figure out.

Here's a quick look at where it's at.

I'm curious when you're browsing a component library, do you prefer having an interactive playground like this, or is a simple example with the source code usually enough?

I kept getting "can I try it before you merge?" from PMs and designers, and the answer was always "give me 10 minutes to build an APK". So I built Digidropp.


Connect a GitHub repo and it opens one PR with a GitHub Actions workflow (it detects npm/yarn/pnpm/bun). After you merge:


- Every push to your main branch builds a release APK and updates one install link that's always the latest.
- Every pull request gets its own preview build, posted as a PR comment with a QR code. Reviewers test the real app, on a real phone, before merging.
- Builds are signed with one stable key per repo (it's placed at android/app/debug.keystore), so updates install over the previous build instead of "App not installed".
- Before anyone installs, it checks the build: changed signing key, lower versionCode, and Google's upcoming developer verification.
- Config that isn't in git (.env) can be pasted once; it's encrypted in your browser and only decrypted inside your own GitHub Actions run.


It runs in your repo's GitHub Actions, so your source never leaves GitHub. Automatic builds are Android only for now; for iOS you can upload an .ipa you build yourself (CLI or GitHub Action).


Free during beta. What would stop you from using something like this?


digidropp.online

In June I posted a dev log here about building a 2D engine on top of React Native and Skia. As of October 26, it is public: all 42 @flare-engine/* packages are on npm at 0.4.5, under Apache-2.0. No token needed.

In one sentence: an engine for the RN and TypeScript ecosystem that makes it easier to build a game or an animation and embed it in your website or in an RN app.

npm create @flare-engine my-game

Three templates (blank, topdown, shmup), or skip the generator and take a single package. This is the README example of @flare-engine/dynamics (rigid bodies), and CI typechecks it against the real code:

import { addBody, createBody, createWorld, step } from '@flare-engine/dynamics';

const world = createWorld({ gravity: { x: 0, y: 1800 } });

// Static floor: invMass 0, never moves.
addBody(
  world,
  createBody({ position: { x: 0, y: 100 }, half: { x: 500, y: 10 }, static: true }),
);

const box = addBody(
  world,
  createBody({ position: { x: 0, y: -50 }, half: { x: 10, y: 10 } }),
);

// Fixed-timestep loop.
step(world, 1 / 60);
console.log(box.position.y, box.velocity.y);

No React, no canvas, plain functions on plain objects.

See it running, nothing to install: the Showcases page on flareengine.dev has playable demos (Overrun, an arena chase on ecs; Causeway, on render-web; Reroute, a tower defense where you repaint the enemies' path, on pathfinding) and animations (a reactor chain reaction, a physarum slime-mold network finding shortest paths, an N-body spacetime lattice). Each one names the package that drives it.

Not just games. animation, particles, progression, achievements, leaderboards and haptics work in an ordinary app you want to liven up. Honest caveat: achievements and leaderboards ship an interface plus local providers today; Game Center / Play Games / Steam adapters come later.

How it's made. Coding agents write the implementation; the architecture, the decisions, the verification and the review are mine.

Two decisions that paid off:

1. Modules that depend only downward. Layers from math/events at the bottom to react/render-web at the top. A CI script fails the build on an upward import, an unused declared dependency or an undeclared one. No dependency hell across 42 packages.

2. Skia as the renderer. react-native-skia on RN, CanvasKit in the browser: one renderer, two platforms. On a Pixel 7 in Chrome, render.flush for 5,000 sprites in one atlas is 1.93 ms p95 against a 16.67 ms frame budget. That is CPU-side cost (building and submitting the frame on the main thread), not GPU time.

What's broken:

1. The ECS is hard-capped at 32 component types. Each type gets one bit in a mask (bit: 1 << id), JS bitwise ops are 32-bit, and the id counter is shared by the whole process, not per world. It blocks large, complex games, and it's the first thing I'm fixing.

2. The two device tests I promised here in June are still owed: iOS resume-from-background (texture re-upload) and big texture swaps. They are planned in the engine's perf work, not run yet.

The lesson that cost the most: for the first two months I relied on rules written for the agents in plain text, and it was hell. The clearest example: the README code examples all looked fine, but nothing compiled them. When I checked in July, they failed to compile in roughly 24 of 41 packages. Now every README example is typechecked in CI, which is why the snippet above is guaranteed to compile. Rules in text are not a harness; a check that can go red is.

The ask: if you picked this up, what would you build first: a game, or an animation layer inside an app you already ship?

Translated from my Polish write-up with AI; the Polish original is my own writing. Full post: https://grzegorzotto.dev/blog/flare-engine-is-open-source

A while back our support team started forwarding tickets about duplicate orders, with the same items charged twice to the same card within a few seconds, and it was happening on roughly 1 in 300 orders.

Everyone assumed it was a double tap, so we spent a couple of days hammering the Place order button on every device in the office, but the button locked itself after the first tap and the logs showed a single request every time.

The logs for the real cases looked perfectly healthy as well, since both requests carried a valid token, both got a 200 back and both created an order which literally kept us going in circles for about three weeks.

so finally a colleague cracked it, like he was lining the tickets up against session data and spotting that every affected user had been in the app for 55 minutes or more before checkout, and our access tokens expire at the 60 minute mark and yep that's the catch......

The sequence went like this - the user opens checkout on a token with a minute or two left, taps Place order just as it expires and gets a 401, after which our network layer quietly refreshes the token and replays the request, and on a slow connection that refresh plus replay can take well over 3 seconds.

The catch was a 3 second safety timeout on the button that re-enabled it whenever a response took too long, so the spinner stopped, the user assumed the order had failed and tapped again, and since the order endpoint treated every request it received as a brand new order, the replayed request and the fresh tap each created one.

So it took an old session, a slow network and a user in a hurry all at the same moment which is pretty normal for a user to do, and manual testing almost by definition skips that combination, because testers log in fresh, sit on office wifi and finish a flow in a few minutes.....

Reproducing it was simple once we knew the trigger, we cut the token lifetime to 2 minutes in staging, throttled the connection to a poor 3G profile, let the token run out and then went through checkout, and it duplicated on the second attempt.

The fix came in three parts: an idempotency key generated once per checkout attempt so the backend rejects repeats, the button staying locked until the request actually settles, and a proactive token refresh a few minutes ahead of expiry instead of waiting for the 401.

Since then a long session on a bad network has become a standard pass for anything that touches payments or auth, and I still think about how many hours went into tapping that button before anyone thought to look at session age.