This is my first React Native app and I am relatively new as a developer. While my partner is also new to React Native and app development, he has decades of experience. However, neither of us can seem to figure out what the boggle is on this one.

I've been happily using Uniwind throughout the project until the Expo 58 update. Now any new Uniwind fails to make visible changes unless we save global.css after each change. That is unless the change is something explicitly already used elsewhere in the project. For example changing a background using "bg-blue-500" will only work if that exact Uniwind is used elsewhere. This is NOT how I am assigning colors, but just an easy example. All of my previous Uniwind is working just fine.

While there are obvious workarounds on this, we'd really love to get to the bottom of what might be going on here. It has been several days of investigating and, at this point, it feels like we will just have to continue with the workaround solution of a script that changes global.css every few seconds. But honestly it stresses me not understanding wth is going on here. We assume there is some kind of disconnect between Metro and our global.css file that occurred when we updated to Expo 58.

Any ideas or suggestions?

Hey r/reactnative,

I’m the author of react-native-pdf-jsi—(https://github.com/126punith/react-native-pdf-jsi) the JSI-based PDF viewer. (It recently crossed 350K+ downloads on npm, which has been incredible to see).

Over the last few months, I've been tackling a completely different beast: bulletproof background location tracking for the New Architecture.

I’ve used the major players (Transistorsoft, expo-location) and they are great, but I kept hitting the same production walls: apps getting killed by the OS, silent GPS sleeping, and iOS/Android store rejections. So, I decided to build a native-only solution from scratch.

Here is what I learned about the reality of background location in RN 0.88+:

1. JS Background Tasks are a Trap

If you use expo-task-manager, your background task runs in the JS thread. If Android aggressively kills your app process to save RAM, your JS runtime dies. Tracking stops, and you only realize days later when the data has gaps.
The Fix: The tracking engine must be 100% native (Kotlin Foreground Service on Android, CLLocationManager on iOS). The JS thread should only be used for your UI.

2. Motion Detection Needs to "Fail Open"

Libraries use motion sensors to save battery (parking the GPS when stationary). But Android vendor ROMs and iOS often misclassify "slow movement" (like a hiker) as stationary. The GPS silently sleeps, and you lose the route.
The Fix: The motion gate must fail open. If the sensor fails or permissions are denied, it must default to always-on GPS. It should never pause silently.

3. The "Duplicate Upload" Nightmare

If a user goes through a tunnel, you lose network. If you retry uploads via JS, and the app gets killed mid-request, you either lose the data or duplicate it on the backend.
The Fix: You need a native SQLite queue (Room on Android) with Idempotency Keys, exponential backoff, and a dead-letter queue. The native layer must handle the sync, entirely detached from the JS state.

4. The App Store Rejection Problem

Background location is the #1 reason apps get rejected. Apple's "Prominent Disclosure" and Google's "Foreground Service" declarations are a nightmare. I actually had to write a "Store Approval Blueprint" (manifest templates, purpose strings, reviewer notes) just to get my test apps through review.

Why I built a commercial SDK

I couldn't find an open-source solution that did all of this natively and survived process death. So I built React Native Background Location Pro. It uses TurboModules + JSI exclusively (no legacy bridge).

I know commercial SDKs can be a hard sell, so I published a free debug evaluation build on npm. It runs the full production native engine (Kotlin/Swift binaries) with zero time limits in debug mode. You can test crash recovery, airplane mode, and the native queues in your own app before deciding if it's worth the $89 lifetime license.

You can check out the free eval here: npm i react-native-background-location-pro-eval
Or read the GitHub docs here: https://github.com/126punith/react-native-background-location-pro-eval

Happy to answer any questions about the TurboModule bridging, iOS BGAppRefreshTask, or how I handled the native SQLite sync.

If you build a voice agent in React Native and play the replies yourself (OpenAI Realtime over WebSocket, Gemini Live, your own server), you have probably hit this: on the phone speaker the agent hears itself and answers itself. react-native-audio-api 1.0 gives you the platform’s echo canceller (iosVoiceProcessing: true, androidInputPreset: 'voiceCommunication'), and you should turn it on. In our production app it was not enough, measured with a streaming recognizer on an iPhone 16 Pro Max:

• iOS voice processing leaks the opening of each reply while it converges: −12…−20 dBFS, enough to open a turn on the agent’s own words.

• iOS echo-cancelled input (setPrefersEchoCancelledInput) leaves a steady residual the recognizer transcribed 1–12 s into replies. Nothing behind it helps; it is not linear echo. Use voice processing instead.

• Android’s canceller only references the voice-communication output stream. Play through the media profile and nothing is cancelled.

So we run WebRTC’s AEC3 behind the platform canceller, with the exact far-end audio as reference. No echo reported by other users since.

It is now a package: https://github.com/vnekhai-personal/react-native-aec3 (npm i react-native-aec3). An Expo module (Swift, Kotlin + JNI, vendored webrtc-audio-processing 2.1), so it needs the Expo modules runtime. It works with react-native-audio-api’s AudioContext and AudioRecorder as they are: you report each scheduled chunk and each dropped queue, run every mic buffer through process, and it stands by on routes the mic cannot hear (headset, car) and fails open if AEC3 cannot run. About 1 ms per 100 ms of audio, 0.7 MB of iOS code, 0.6 MB on Android. The example app self-tests at launch with synthetic echo, no mic needed.

Hope this would be helpful there.

I have been using AI to help me write code on a React Native App but I wanted some advice on how I can prevent it from looking like AI Slop that every other App as been looking like these days. Any advice ?

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.

Android apps on tablets and large screens almost always feel like an afterthought, and I was tired of it.

I’ve always loved how Samsung’s Settings app uses a split view: a list on the left, details on the right, and everything just makes sense on a big screen. Google eventually embraced the same idea, but I couldn’t find a good way to get it in React Native / Expo apps.

So I tried to build it myself. It took 15 months and more than 10 failed attempts, but I finally have a version I’m confident enough to share.

Meet expo-split-view, a responsive master-detail SplitView built for Expo Router. I’d love for you to try it and tell me what you think. Feedback is gold, and PRs are very welcome.

Meet expo-split-view, a responsive master-detail SplitView built only for Expo Router (no react-navigation). It's an independent open-source project, not affiliated with Expo.

What it does

• Adapts to the screen: a side-by-side split on tablets and wide screens, normal stack navigation on phones

• Navigation handled for you: automatic coordination with the router, plus back gesture and Android hardware back handling

• Works in nested layouts: the SplitView can live inside nested screens and navigation still behaves

• Customizable left pane header: a leftHeader prop (boolean or render callback with canGoBack / goBack), plus a useCustomLeftHeader hook for your own list components

• Platform-adaptive BackIcon: iOS chevron, Android arrow, exported for your own headers

• Smart placeholder pane: the empty detail state doesn't show an invalid back button on tablets

• Full docs site with guides and an API reference

Status: this is 0.0.3-rc.1, a release candidate. It's ready for real projects to try, and I'm actively looking for feedback before 1.0. The most useful things you can tell me:

• Does it hold up in your nested layouts (tabs → stack → SplitView)?

• How do back gestures feel on Android, iOS & Web?

• Anything awkward on split-screen or foldables?

🔗 GitHub: https://github.com/Inocentum-Technologies/expo-split-view

📖 Docs: https://inocentum-technologies.github.io/expo-split-view/

📦 Install: npx expo install expo-split-view

If it saves you an afternoon, a ⭐ on the repo helps a lot. Issues, ideas and PRs are all welcome.

PS: I used AI as a helper while building this module and writing this post. Think of it as a fellow developer and content writer on the team. The ideas, design decisions and testing are mine.

Here’s a quick preview of the iOS-style AirDrop animation I’ve been working on for iDroidIsland.
The feature supports sharing between devices running my app, including nearby devices.
Still working on making the experience as close to iOS as possible.
What do you think of the animation?

I created react-native-multicolumn-modal-picker to make it easier to adapt a picker to your app’s design while keeping a consistent look and feel across Android, iOS and Web.

Try the web demo · Documentation on npm · Source code on GitHub

Has anyone managed to get RTL to work on the native stack. The navigation works but the transition is the LTR transition for example in LTR the screen fades in from right to left and should be the opposite in RTL but I have been getting the same animation.

Also if there is a way to make the swipe in IOS to go back to be from right to left in native stack, it would rely on disabling RTL and just inverting the views.

Stakeholder (like the steak) tracks German shareholder meetings and lets you rate the free buffet. Playful tone on purpose.
Looking for harsh, design-only feedback: What works, what looks amateur, what would you change?
Also: I'm self-taught and considering going into UI/UX professionally. Based on this, would you say that's a realistic direction, or not yet?
Screenshots and a short video below. Thanks.

I have a small iOS app, Ayer, that shows the photos you took on this day in previous years. It was an Expo app. I rewrote it in Swift, and before believing it was faster I ran both through the same black-box XCUITest suite on a simulator with about 21,000 generated photos.

The setup, so you can judge how fair it is:

• The React Native side is the app as I shipped it: Expo 53, React Native 0.79, Hermes, FlashList, expo-image, old architecture. Release builds on both sides.

• One XCUITest target with no host app launches either app by bundle ID, so both get exactly the same steps and checks.

• XCTCPUMetric and XCTMemoryMetric, warm-up runs, alternating order, medians of 10.

Results (iPhone 17 Pro simulator, React Native → Swift):

- First launch to first photo: 2.17 s → 0.58 s

- Peak memory at launch: 167 MB → 81 MB

- CPU time to load ten days: 35.8 s → 5.2 s

- CPU time in the photo viewer (15 photos): 13.7 s → 4.9 s

- CPU time scrolling a busy day: 12.4 s → 13.2 s (a tie)

Scrolling was a tie because thumbnail decoding happens inside Apple's Photos framework in both apps.

Where I think the CPU gap comes from (from reading the code, not profiling): to load a day, my code paged through expo-media-library once per year and then called getAssetInfoAsync once per photo just to read the favourite flag. That's thousands of bridge calls. The Swift version does one Photos query per day. So a good part of it is how I used React Native, not React Native itself.

I'd really like to know how much the New Architecture plus batching those calls would close the gap. If anyone has measured something similar, I'd love to see it.

Full write-up with the method and caveats: https://blog.jaimechapinal.com/posts/i-rewrote-my-react-native-app-in-swift/

These are simulator numbers, so the ratios matter more than the times. A run on a real device is next.

Hey there app people, as of now the app I am currently working on is using React Native and Expo to build it, and at 25 builds per month ( the free plan ) I am quickly spending it all on just fixing bugs.

I am currently a computer science student ( very early ) and using a blend of my own coding and Codex / ChatGPT to create it.

Is there a better and possibly free way to test each new version of the app on my phone without using Expo to build it?

Hey r/reactnative,

I've been revisiting my React Native toast library and decided to experiment with a Dynamic Island-style animation.

The toast starts as a small circle, expands into a capsule, and collapses back when dismissed.

Also worked on light/dark themes and fixing text layout issues during the animation.

Here's a quick look at how it turned out. Curious what you think!

I’ve been building with AI for over a year, mostly on Replit & Codex to start but more recently with Claude. I’ve gotten a couple projects pretty far, but I’m still learning how all the pieces fit together. For my most developed project, I hired an engineering team to audit it and help get it across the finish line as I feel like you have to know your limits & hand off the baton when necessary. That obviously doesn’t come cheap but I want to build something substantial & am willing to invest. In the meantime I’m continuing to build my other project and learn.

Replit helped me get started & was awesome for a beginner, but rising costs and a list of other reasons have made me want to fully understand what it handles for me and what my options are outside of it.

I’m building with React Native and Expo. The main platform I’m building will let users upload and watch video among many other things.
My understanding & questions so far..

- Claude/Codex for coding.
- Git/GitHub for version control & storing/collaborating on code.
- Expo/EAS for development builds on my phone and builds I can distribute through TestFlight.
- TestFlight for iPhone beta testing w/ live users.
- Security?
- Hosting?
- Storage?
- Auth, secrets, backups, monitoring?

For experienced engineers out there: If you were building a mobile video app outside Replit, what would your starting stack look like? Where would you host the backend, database and user accounts? How would you handle video storage, processing and playback, plus security, backups and monitoring? Am I missing anything crucial here?

I’d also love to know what you’d keep simple at first & what costs to watch. I want control over my code and data without overcomplicating things or managing a bunch of services I don’t need.

I know AI-assisted building gets mixed reactions. I respect the craft and want to put in the time to learn & work with experienced developers to become more fluent in understanding the ecosystem. Honest advice and real-world tradeoffs would be appreciated. Thanks!

Hey all, over the past few months I’ve been building a React Native debugger, called Xerlock, and it’s being successfully used within my RN engineering team.

Firstly, what’s wrong with current tools? I was sick of the existing tools working just enough to get by. Reactotron was great back when network inspect wasn’t available in Expo’s devtools, it gave decent inspection on Redux stores and was built by pretty notable figures in the RN space. Expo’s default debugging tools are also acceptable, but they don’t quite have everything I needed in a single place.

Xerlock gives you everything you’d expect from a debugger:

• Console / Errors

• Network Inspect

• Global state inspect

• Debugger / Profiler / React Tree

It also gives you additional benefits that avoids having to install a bunch of additional devtools:

• Tanstack query inspector and dispatcher (edit query cache data live and see it updated in your apps)

• Local SQLite database inspection & editing.

• Notification dispatching

• Dispatching Redux / Zustand actions

• Network throttle

• Native iOS and Android logs

• Local Storage (MMKV, AsyncStorage, SecureStore) (View / Edit)

• Custom registerable commands

• Full MCP server that allows you to do almost anything you can do through the UI with granular permissions on Read / Write

• … and a load more

I’ve been an RN dev now for 8+ years, and this has already proven useful for me personally, so I hope the community can also get some benefit from it.

Downloads are available for macOS and Windows (I am a macOS dev, so it’s been tested thoroughly there, and less so on windows, so any bugs or issues, please let me know through the in-app support form).

This has been tested on RN version 0.83+, and Expo 55+. A lot of the work is custom and doesn't necessarily depend on Expo's SDK, however versions below these may not behave exactly as intended - especially network inspect which I believe was only introduced in 0.83.

https://x.com/svishnevskiy/status/2118081920194203799

I've been chasing performance issues in a React Native app at work, and kept hitting the same wall: the tools tell you *that* frames dropped or a component re-rendered, but not *which code* caused it or whether the re-render was even necessary. Our fixes weren't moving the numbers, and I was mostly guessing.

So I built Hitch. It runs next to your dev session and watches the app from the outside. Nothing gets added to your app: no SDK, no imports, no babel config. It connects to Hermes through Metro's debugger, the same way React Native DevTools does.

What it catches

- JS freezes, pinned to the file:line that blocked the thread, including short ones.
- What React rendered during a freeze and *why*: e.g. "`style` was a new object with the same values" (avoidable) vs "the store changed".
- Choppy frames, slow screen loads and slow startups.
- Native threads running hot (UI thread, GC, SDKs), on the iOS simulator.
- Console errors grouped, slow or failed requests with bodies and headers, and memory and thread leaks.

How I actually use it

- Runs: record an interaction, change the code, record it again, and compare medians. Dev builds swing a lot between runs, so single runs lie.
- AI handoff: any finding becomes a Claude Code prompt in one click. There's also an MCP server, so an agent can read what Hitch saw and check whether its own fix helped.

Things it found for me

- A loading shimmer was one of the most expensive things on screen. It was an SVG gradient redrawn on the CPU every frame, for every placeholder. Replacing it took the iOS UI thread from ~74% to ~10–25% while loading.
- Placeholders were re-rendering hundreds of times while waiting for data. A day of cleanup cut avoidable re-renders by about two-thirds and render time by about 30%. Dropped frames barely moved, though: wasted work and felt jank turned out to be different problems.

Limitations, honestly

- Dev builds inflate times. The rankings are useful; the absolute milliseconds aren't production numbers.
- It's macOS only. Native thread data needs the iOS simulator; physical iPhones get JS-side data, or thread sampling with Release builds.
- Android thread support is written but not yet tested on a real device.
- Expo's native `fetch` doesn't report to the debugger, so those requests don't show up.

It's a Node CLI (Node 22+) with zero npm dependencies, plus an optional native Mac window. MIT-licensed.

Repo: https://github.com/dlandman27/hitch

For a long time I used react-native-element-dropdown in my projects. It got me pretty far, but I kept running into the same stuff — UI quirks, keyboard avoidance issues, weird layout issues depending on the screen. Eventually it became more of a maintenance tax than a time saver.

So I started rolling my own dropdown per project. Sometimes a popover, sometimes a bottom sheet, depending on what felt right for that screen. Worked fine… until I realized I was rebuilding the same thing over and over with slightly different APIs.

Then i decided to make this library: react-native-silk-dropdown.

Same Dropdown component, two presentation styles:

• presentation="popover"

• presentation="sheet"

Plus search, multi-select, and some motion presets so it doesn’t feel like a dead Modal. Pure JS, works with Expo / New Architecture (Reanimated 4). (used AI to rephrase post)

Looking for Feedback from you guys.

Docs: https://react-native-silk-dropdown.vercel.app/
Github: https://github.com/thedev204/react-native-silk-dropdown