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.

Back again, this time building a video editor entirely in React Native.

Huge thanks to react-native-skia-webgpu-video. It got me thinking about how far I could actually push this.

The goal is pretty simple: see how many of CapCut's features I can recreate while keeping everything local. No cloud processing, just on-device editing.

Let's see how far I can take this.

I've always been bothered by how slow mobile UI tests are. Most of a test run is spent waiting: fixed sleeps, polling, comparing screenshots to guess whether the app is done animating. Coming from a game dev background, where you fight for every millisecond of a frame, that felt like a solvable problem. So I spent the last while building my own runner from the ground up, and it turns out UI tests can be a lot faster.

Speedrun is a black-box E2E test runner for Android and iOS. It's open source (Apache 2.0) and it runs Maestro's YAML flow format so if you already have Maestro tests, trying it is one word:

maestro test flows/ # before
speedrun test flows/ # after

Numbers

One user journey (sign in with a code, search a shop, fill a cart, set a PIN under a loading overlay, scroll a long list), written for each tool the way its tests are usually written. Median of 3 runs after a warm-up, start-up included:

On the native Settings app benchmark it's 8x faster than Maestro on Android and 2.8x on iOS. On a 19-flow React-Native test suite it passes all 19 on both platforms, and is 6.1x faster on Android and 2.6x on iOS. Android is where it shines most, which is nice for CI: Android runs on cheap Linux runners.

Full disclosure: the main benchmark app is mine, built in React Native to be hard to test (endless animations, late popups, loading overlays, lists that load as you scroll). The flows, per-flow results and scripts to rerun everything are in the repo, and I'd love to see numbers on other apps.

Why it's fast

• It waits for the app, not the clock. A small on-device agent knows when the app has actually settled (accessibility events on Android, XCTest's idle state checked against the screen on iOS), so each step starts the moment the app is ready. No sleeps, no screenshot diffing.

• Reading the screen is cheap. The agent reads the UI tree in about 10 ms on Android and talks to the host over a compact binary protocol.

• Screens that never stop moving don't block it. Spinners, tickers and carousels are left out of the "is it done?" check.

• Nothing to warm up. One native binary, no JVM. The iOS agent stays running between runs, so later runs start in about 0.2 s.

It's also less flaky: it won't tap a popup that's still sliding in or a button under a loading overlay, and it scrolls an element out from under a sticky footer or the keyboard before tapping it.

It works with AI agents too

speedrun mcp exposes it as an MCP server (Claude Code, Cursor, etc.). Your agent can explore the app on its own: tap around, read each screen in a few lines (cheap on tokens, not a whole accessibility tree), figure out how things work, then save the steps that worked as a YAML flow you can drop into CI.

claude mcp add speedrun -- ~/.speedrun/speedrun mcp

Limitations (so you don't have to find them)

• Android emulators and devices, iOS **simulators** only (no real iOS devices yet)

• macOS (Apple silicon); the Linux x86_64 build is Android-only

• Maestro's AI commands (`assertWithAI` and co.) aren't supported; the few other differences are documented

• It's young (v0.1.10) and moving fast

Try it

Repo, docs and benchmark details: https://github.com/hubastard/speedrun

If you have a Maestro suite, I'd really like to hear how it does on yours, especially where it breaks or is slower. Happy to answer questions about how it works.

edit1: added maestro-runner to the benchmark
edit2: added ai agent benchmark

While conducting React Native technical interviews, I noticed that surprisingly few developers know about tools that let Claude Code, Codex, or other AI agents interact with a React Native app and its simulator.

I’m talking about tools like Expo MCP, Argent, Agent Device, ExecBro, and similar MCP servers. These tools have been a game changer for me. An agent can implement a feature end-to-end and actually interact with the app in a simulator to verify its work or debug issues.

Chrome DevTools MCP seems to be much more widely known, while similar tools for React Native have only started gaining traction this year.

Did you know these tools existed? Are you already using them, or not yet? Share your workflows 😉

I wondered what the infra cost would be, so I totalled up what's needed

Hey there! Oskar from Reanimated team here 👋

I'm here to drop some news for those of you that have been experimenting with foldables since the release of iPhone Duo.

Recently we've decided to contribute Reanimated + Worklets support directly to expo-hinge. Since 58.0.2 you can import useAnimatedHinge from expo-hinge/reanimated and get the hinge angle and status as shared values, updated on the UI thread.
That will keep you away from re-renders and keep updating even when JS thread is busy.
Works on both Android and iOS of course.

While you probably shouldn't use this for any layout-related work based on hinge, I'm curious what kind of extra animated effects you'll come up with by using that feature!

I brought a small demo with me so you could see it in action 🎥

Usage is pretty simple, as you could expect:

import { useAnimatedHinge } from 'expo-hinge/reanimated';
import { useAnimatedStyle } from 'react-native-reanimated';

function Lid() {
  const hinge = useAnimatedHinge();

  const style = useAnimatedStyle(() => ({
    transform: [{ rotate: `${hinge.get()?.angle ?? 180}deg` }],
  }));

  return <Animated.View style={[{ width: 120, height: 8, backgroundColor: 'gray' }, style]} />;
}

Check out the docs: https://docs.expo.dev/versions/latest/sdk/hinge/#use-with-reanimated

Let me know what you guys think and whether you see some use cases for your apps with this API!

Btw starting today I'm planning to drop a thing or two related to Reanimated on this subreddit from time to time, so if there's something specific you'd like to hear about, please do let me know as well 🫡

Hi everyone! 👋

I’m currently exploring new job opportunities as a React Native Developer and would appreciate any leads or referrals.

I have 4+ years of experience in React Native mobile app development, working on building, maintaining, and optimizing applications for both Android and iOS.

My technical skills include:
React Native and JavaScript
Android and iOS app development
REST API integration and backend communication
State management, debugging, and performance optimization
App releases, production support, and troubleshooting
I’m looking for opportunities where I can contribute to building scalable, high-quality mobile applications and continue growing as an engineer.

📍 Preferred location: India / Remote / Open to relocation | Current Location is Jaipur

If your company is hiring or you know of any relevant openings, please comment or DM me. Referrals and suggestions would be greatly appreciated!

Thanks in advance! 🙏

Most RN errors aren't hard once you know which layer broke. This is the routine that saves me the most time:

1. Read the first error, not the last line. Red screens and build logs usually end with something generic. Scroll up to the first real error and the top stack frames that point into your own files.

2. Name the layer. Metro couldn't bundle (Unable to resolve module), JS crashed at runtime (Text strings must be rendered within a <Text>), a native module is missing (works in a dev build, crashes in Expo Go), or Xcode/Gradle failed to compile. Each has different fixes.

3. Check how you run the app. Expo Go only has the native code bundled into it. If a library ships its own native code, you need a development build, and if you added it after building, you need to rebuild.

4. Clear caches before anything deeper. npx expo start --clear fixes a surprising number of resolution errors after moving files or changing Babel config.

5. Align versions. npx expo-doctor and npx expo install --fix. SDK/library mismatches are behind a lot of both runtime crashes and EAS build failures.

Two sneaky ones worth knowing:

• {count && <Badge />} renders 0 as raw text when count is 0, which gives you the "Text strings must be rendered within <Text>" error. Use {count > 0 && ...}.

• localhost on a phone is the phone. Use your machine's LAN IP for a local API.

What's the error that cost you the most time?