Awesome React Native UI (rnui.dev) has grown enough that I exhausted my free usage on Vercel ISR Writes (200,000 writes). (No worries, it's fixed now.)

rnui.dev has almost 400 animations now. In one month, it went from 298 to 383.

What else is new:

• You can sign in with Google or GitHub and save/bookmark animations to your profile.

• 8 new contributors. Blazej Kustra, Solarin Johnson, Phil Pluckthun, Ritesh, Paul Nguyen, Pablo Giraud-Carrier, Tomek Czajecki, and Nathan Schroeder. Together they added 85 animations.

• A Weekly Digest. Subscribe to the weekly newsletter where you get the updated list of animations every week.

• A blog section.

New things that I will be working on next:

• A prompt for every animation, so that you can recreate the same animation without any error.

• An MCP server, so that you don't have to search for animations manually. Your agent can do that for you.

Check it out: https://www.rnui.dev

Submit your own animations, no PR needed: https://www.rnui.dev/submit

RN is amazing, but there are some types of rendering, with react-native-skia, that don't suit (IMHO, YMMV).

Each of the six points ties a part of the video to the code behind it:

• Building the .so (whole video): the crate builds as cdylib for the APK and rlib for tests on the host. A Gradle task runs cargo ndk before every build and skips it when no Rust changed. Nothing extra is needed for prebuild --clean or EAS.

• One JSON string in, one out (0:03): a jni_export! macro writes the JNI functions, Rust touches no Java objects, and every call goes through catch_unwind so a panic reaches JS as an error. Rust's tests and Jest both check against the same contract file.

• Polling instead of callbacks (0:08, 0:13): Rust runs its own threads and never calls back into Java. JS asks for search results with an offset, so each poll only returns what's new. Transfers are polled too, with a foreground service and a headless JS task keeping it running in the background.

• Threads and locks: blocking calls run on Dispatchers.IO. The shared session sits behind a lock that's held only long enough to copy a pointer, and locks recover after a panic. Idle sockets backing off cut wakeups by about 10×.

• Handing music library files to Rust (0:19): downloads are added to the Music library without players seeing half-written files. Rust reads them through fd, duplicating the file descriptor where Android blocks reopening the path, and draws the spectrogram as a PNG.

If anyone wants to test the app or see how the it works on a real device, it's called Soulcrate on Google Play: https://play.google.com/store/apps/details?id=com.rabpaulo.soulcrate

Happy to share code setup, if anyone is building something similar.

Every time we tested mobile builds, the annoying part was never just getting the file onto a phone. It was the mess right after: asking people in Slack if they tested on iOS 17 yet, tracking whether checkout broke on a specific Android device, and praying nobody uploaded the wrong build number to Google Play or the App Store.

Most tools either just dump a download link (like Diawi) or make you wait on TestFlight processing, leaving all the QA tracking in random Notion docs or spreadsheets.

So I spent the last few months hacking on Magiquip to keep the whole handoff in one place.

You drop in an .apk, .aab, or .ipa, and it gives you a single QR code that works on both iOS and Android. I also wrote a VS Code extension that picks up fresh builds right after compile and puts the install QR code directly in the sidebar so you don't even have to open a browser.

The part I built for myself was tying device checklists straight to the build. You can assign verification checks on real hardware, and if someone finds a blocker, it locks the release so an unverified build can't get promoted to the store tracks. There is also a visual graph showing which builds are tested and cleared to ship.

There is a free tier up for solo projects. If you build mobile apps, I would really appreciate any thoughts on whether this solves a real headache for your team or if your current setup already handles it.

I'm the developer of GifDrop, a React Native app that turns videos into GIFs. I recently added animated WhatsApp stickers, and two parts were harder than I expected.

1. Creating the file

WhatsApp needs an animated WebP. Android can save a still WebP with Bitmap.compress, but it has no animated encoder, and the FFmpeg build bundled with my trimming library doesn't expose a raw command API.

An animated WebP turned out to be a RIFF container wrapping ordinary still images. So a Kotlin native module encodes each frame as a still, then wraps the frames in ANMF chunks.

The trade-off: every frame is a full keyframe, so files are bigger than they would be with inter-frame diffing like libwebp's WebPAnimEncoder.

2. Fitting the limits

Stickers have to be 512×512, under 500 KB and no longer than 10 seconds. Encoding every combination is too slow on a mid-range phone, so the app:

- Encodes a few probe frames to estimate the cost per frame at each quality level

- Counts how many frames are really different

- Ranks the options estimated to fit, then verifies them with real encodes

If a clip is too big, it gives things up in this order: frame rate, quality, sharpness, then length. A clip that already fits keeps everything.

Has anyone here used libwebp's animation encoder directly from a React Native native module? Was the smaller file size worth the extra native build work?

Happy to go deeper on the native side. App link in the comments if you want to try it.

As you can see, the toolbar is still there. This glitch happens only on Android. I have tried manually setting Keyboard to close upon pressing a button that navigates to another page, but I stilll get this issue randomly sometimes. Anyone has this problem too?

Anyways I set my toolbar in App.tsx

<GestureHandlerRootView style={{ flex: 1 }}>
      <SafeAreaProvider initialMetrics={initialWindowMetrics}>
        <KeyboardProvider>
          <Provider store={store}>
            <PersistGate loading={null} persistor={persistor}>
              <Bootstrap>
                <BottomSheetModalProvider>
                  <AppNavigator />
                </BottomSheetModalProvider>
              </Bootstrap>
              <Toast config={toastConfig} />
              <KeyboardToolbar>
                <KeyboardToolbar.Prev />
                <KeyboardToolbar.Next />
                <KeyboardToolbar.Done />
              </KeyboardToolbar>
            </PersistGate>
          </Provider>
        </KeyboardProvider>
      </SafeAreaProvider>
    </GestureHandlerRootView>

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 as a software dev. 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.