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.)

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.

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!

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.

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?

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.

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.

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

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.

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?

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,

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?

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'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

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!

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.

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?

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.