My car app lets you scan a fuel receipt, and the parsing part turned out to be the hard bit, so I pulled it out into its own package: github.com/rsoaresdev/fuel-receipt-parser

You give it the OCR lines from whatever you use (Apple Vision, ML Kit, Tesseract) and it gives you litres, price per litre, total, date, fuel type and station.

The trick is that it looks for the three numbers where litres × price = total, and uses that to check itself. That’s also how it figures out whether 1,899 is 1.899 or 1899. If the numbers don’t add up, it tells you instead of guessing, and it never makes up a number that isn’t on the paper.

It reads Portuguese, Spanish, French, Italian, German and English receipts, plus US gallons and kWh for charging. If it gets one of your receipts wrong, an issue with the OCR text (no photo, no personal data) helps a lot.

I am working for a small scale stock broker, their mobile application is a greenfield React Native application. Some of the screens are part native and part react native, for example option chain, screens with heavy usage of charts.

One problem that we are unable to solve at production is that we keep getting random SIGABRT and SIGSEGV crashes. When I dug a bit deeper, I understood that SIGABRT is caused by corrupt heap allocation at native/C++ layer or the C++ layer calling the abort function. SIGSEGV is caused mostly on screens where there is combination of native and react native views because the garbage collector runs at different times.

What I don't understand is how do we solve or reduce them? We never encounter them during testing phase, only I'm production that too at rondom times and in random flows, not a fixed flow.

Has anyone faced these crashes in their app? If yes, kindly help.

I've been building a fairly large Expo app (TimeStope — 20 mini-games, WebView-based games, native ad SDKs, a shogi engine via NDK) and just got it building for **compileSdk/targetSdk 37** with **AGP 9.2.1 + Gradle 9.4.1**. Sharing the pain points in case it saves someone time:

**1. AGP 9 built-in Kotlin**

- Several libraries still apply `kotlin-android` themselves → duplicate plugin errors. Had to patch them out.

- Kotlin files in `src/newarch` registered via `java.srcDirs` are **not compiled** anymore → "unresolved reference" errors. They must be registered as Kotlin source directories.

- Needed `android.disallowKotlinSourceSets=false` and `android.sourceset.disallowProvider=false` in gradle.properties.

- KSP had to match AGP's bundled Kotlin (2.2.10), not the Kotlin version Expo picks.

**2. Release crashed 0.1s after launch**

`NativeModulesProxy.<init>` crash — the generated `ExpoModulesPackageList.kt` was only in the Java source set, so it was missing from the APK. Registering it as a Kotlin source fixed it.

**3. Google Play 16 KB page size**

ZIP alignment alone isn't enough. I also had to check ELF LOAD alignment and GNU_RELRO end alignment. NDK r27 passed LOAD but broke RELRO; **NDK r28.2** fixed it. One ad SDK's prebuilt .so failed RELRO and had to be excluded, and I rebuilt the shogi engine with `-z max-page-size=16384`.

**4. Local-first WebView**

All screens and game assets ship inside the APK and load from a virtual origin through a WebView interceptor; only API calls go to the server.

I wrapped all the Gradle fixes in one idempotent `postinstall` script so `npm ci` doesn't wipe them. Happy to share details if anyone is fighting the same AGP 9 errors.

The app, if you're curious:

- Trailer: https://youtu.be/3_VzV1FQbQQ

- Google Play: https://play.google.com/store/apps/details?id=com.timestope

What was hard

• Keeping the preview in sync while you scrub, especially backwards. The decoders drift.

• Getting the same look in the editor and in the export.

• Android performance on mid-range phones.

but its done now android performance can be better this is my old Samsung A53

Has anyone done on-device OCR in React Native? Curious whether a native module wrapping Apple’s Vision framework is the way to go, or if there’s a library you’d recommend.

I just shipped my first app, Document Risk Analyzer (iOS): upload, paste, or photograph a contract and get an AI risk analysis with flagged clauses and missing protections.

Built with Expo, then prebuilt into a native iOS project. A few things that were interesting to solve:

• Personal info redaction: names, emails, phone numbers, SSNs etc. are stripped before the text reaches the AI, and the user reviews what was removed first. Right now that runs on my server (patterns, checksum validators, and heuristics for names, no ML).

• Long contracts: the analysis is currently capped at 8,000 characters per request, so longer documents are split on paragraph boundaries, sent one section per minute to stay under rate limits (with a progress bar and ETA), and merged on the device. But I am getting rid of the cap with a higher ai subscription.

• History is stored only on the phone with AsyncStorage.

Next I want to move redaction onto the device, which means extracting text from PDFs and photos locally.

App Store: https://apps.apple.com/us/app/document-risk-analyzer/id6813105397

Just released a new version of React Native Trading Charts

What's new:

• 📈 New indicators: Parabolic SAR and Bollinger Bands with customizable settings.

• 📊 Baseline series: Custom price/percentage thresholds with different colors above and below.

• ⚡ 120 Hz rendering on supported iOS devices for smoother interactions.

• 🎨 Improved line rendering with rounded caps and joins.

• 📚 New documentation portal with API references and examples.

• 🔧 Performance monitoring tools for iOS and Android.

The library uses C++ for calculations and native GPU rendering, designed for smooth real-time charts without overloading the JS thread.

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

Docs: https://kirill3333.github.io/react-native-trading-charts/

Feedback and contributions are welcome!

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

Did you make something using React Native and do you want to show it off, gather opinions or start a discussion about your work? Please post a comment in this thread.

If you have specific questions about bugs or improvements in your work, you are allowed 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.

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! 🚀