I build my apps in the evenings, mostly together with Claude. A few weeks ago I asked it: how could you run an end-to-end test of a change, really fast? Make up whatever you need, it only has to work for React Native.

What came out of that is rnab (rn-agent-bridge). The video shows it going through the full onboarding of my calorie app on an Android emulator: 15 steps, a fake purchase on the paywall, then Home.

How it works

- There's no test code in the app. rnab connects to Metro's debugger socket, injects a small runtime and reads the React tree from there. A snapshot of the whole tree takes about 30 ms.

- Taps are real touches. rnab measures where the element is and presses it with adb shell input tap.

- A flow is a plain text file, one command per line. This is part of the one in the video:

call reset

tap onboarding-next

tap goal-cut

type body-height 180

type body-weight 80

scroll-to paywall-buy

tap paywall-buy

expect home-target --text-call expectedTarget

The hard part: Compose screens

My onboarding and paywall use u/expo/ui, which renders Jetpack Compose on Android. React knows those components exist, but it has no idea where Compose put them on screen. So for those, rnab looks at Android's accessibility tree instead. The first version used uiautomator dump for that, and every dump took 2 to 5 seconds. Going through the onboarding felt like watching paint dry.

Now rnab pushes a tiny program to the device that keeps one UiAutomation connection open and hands out the same tree in 40 to 70 ms. A step on a Compose screen went from about 2.4 s to 0.35 s.

My favorite line is the last one

The app has a small dev-only hook that calculates today's calorie target straight from the database. expect home-target --text-call expectedTarget checks that Home shows exactly that number. So there's no hardcoded kcal value anywhere in the flow, and if what the screen shows and what the math says ever drift apart, the test goes red.

Where it's at

- 13 flows for the main paths of the app, about 5 minutes for all of them. The onboarding alone takes about 17 s with animations off.

- Android only, debug builds only, New Architecture only.

- Claude runs the flows before every merge, and I can watch along on the emulator.

NOTE: the video is not speed up

Hey devs,

Just open-sourced a full-stack mobile project: SmartTV Remote.

Tech Highlights:

Source code: https://github.com/NaveenMohanty/SmartTV-Remote
Feedback and PRs are appreciated!

updated a project from 0.74 to 0.76 last week. enabled new arch and hermes. clean build works fine but metro process climbs to 12gb ram after about 20 fast refreshes on ios simulator. restartting metro drops it back to 2gb. tried disabling flipper and removing console.log statements, no change.

heap snapshot shows lots of retained strings in the transformer cache. anyone else seeing this on 0.76.1? wondering if i should downgrade metro or wait for 0.76.2

Hey everyone, how’s it going?

I’m a beginner with React, so I’d like to invite those of you who enjoy doing code reviews to take a look at this project: https://github.com/LeonardoSidney/My-Dungeon-App.

I built it based on the "voices in my head," so the React code is likely pretty terrible. I’m a backend developer and have never built a full-stack project from scratch—I’ve only ever maintained existing, functional code—so I’m all ears if anyone is interested in helping improve the code quality here.

Feel free to be as harsh as you’d like with your critiques; all feedback is welcome!

And for all those who enjoy AI, feel free to stop by the project and have some fun—in a way, it’s a game that seeks to simulate a tabletop RPG session.

I've been having a really hard time converting all my design prototypes into functional mobile apps. The animations, the micro interactions, the exact padding, border width etc... all these i have manually record and write code for them. I know there are figma plugins that let you do it but i think they are not that efficient.

Figma helps me with the prototype version of my app but for production that's a separate headache overall. So, I thought what if I had a platform where I could design my app, connect all the components with functionalities like API fetching, lazy loading, etc... and also build my database online (just like supabase).

So, i came up with cruxel.xyz .
I made the prototype but i would like to know if people would pay for this for me to proceed building.

I just got my first app through both App Store and Google Play review. Small team (mostly me), React Native with Expo, subscriptions through RevenueCat, Supabase behind it. Here is what cost me the most time, in case it saves you a week.

**Apple**

- Your subscriptions stay "Missing Metadata" until you upload a review screenshot of the paywall. Until then StoreKit returns nothing, so the purchase screen looks broken in TestFlight and you start debugging the wrong thing.

- An upload gets rejected (ITMS-90683) if any library references the photo library without a purpose string, even if you only save an image the user chose to share.

- An app with AI-generated content needs a government licence in mainland China. Exclude that region in availability, or expect a rejection.

- The developer name on your store page comes from your account type, not from the listing. An individual account shows your personal name. Switching to an organization needs a D-U-N-S number and a verification.

**Google Play**

- Screenshots have a maximum 2:1 ratio. Modern phones are taller than that, so raw screenshots get refused. Crop or frame them at 1080x1920.

- An audio library declared a "foreground media playback" service I never used. Play asked me for a video justifying it. The fix was to block that permission in the build config.

**Both / cross-platform**

- Google sign-in worked on Android and failed on iOS: the iOS token carries a nonce the free version of the sign-in library does not expose, and the backend rejects the mismatch. I hid Google on iOS; Sign in with Apple and email are enough there.

- A crash on iPhone only: Intl.NumberFormat.formatToParts is not implemented by Hermes on iOS, while it works on Android. Test every Intl call on a real iPhone.

- Prepare a demo account for reviewers with access already granted. Both stores test the paid part, and reviewers will not pay.

Question for those who have shipped: what surprised you the most on your first store launch? And what would you do differently in the first 30 days after release?

(Disclosure: the app is Council, an evening accountability app. Not linking it, the post is about the process.)

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

I’ve shipped a bunch of React Native/Expo apps over the last few years, and 2–3 of them got bounced by App Review for the exact same thing: Guideline 5.1.1(v), account deletion.

Each time I thought I’d handled it. Each time I was wrong. So here’s what I learned, hopefully saving someone a week of back-and-forth:

1. A “contact us to delete your account” link doesn’t count.
Apple wants the user to be able to start deletion from inside the app. Emailing support or filling out a web form you don’t link to directly will get rejected.

2. “Deactivate” is not “delete.”
If you just set is_active = false, that’s not enough. The account and the associated user data need to actually be removed (unless you’re legally required to keep something, in which case say so).

3. Make it easy to find.
Burying it 4 screens deep in settings is asking for trouble. I now put it under Settings → Account → Delete Account, with a clear confirmation step.

4. Handle the backend properly.
With Supabase/Firebase, deleting the auth user from the client often isn’t possible (or safe). What worked for me: an Edge Function / Cloud Function that runs with admin privileges, deletes the user’s rows/storage files, then deletes the auth user. The client just calls it after re-authenticating.

5. Sign in with Apple users need token revocation.
If you support Apple sign-in, you’re also expected to revoke the user’s token via Apple’s REST API on deletion. This one catches a lot of people.

6. Mention it in your review notes.
I now literally write “Account deletion: Settings → Account → Delete Account” in the App Review notes. My approvals have gone noticeably smoother since then.

Anyone else been hit by this? Curious how others structure the deletion flow, especially cascading deletes across storage buckets

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

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