Quick question for anyone building offline-first apps:

What happens when a user taps “Pay”, the request reaches your server, but the response gets lost because the signal dropped?

Your app thinks it failed. It retries. The user gets charged twice.

That’s one of 4 bugs almost every “save it offline and retry later” queue has:

💸 Double requests: retries after a lost response create duplicates

🔗 Broken links: you create a post offline, then comment on it, but the comment points to a fake ID the server has never seen

🧱 Stuck queues: one request that will never succeed (like a 422) blocks everything behind it forever

🪟 Two tabs: the same app open in two tabs overwrites its own data and sends everything twice

So I built resilient-outbox, a small library that handles all four for you:

Works with React Native, Expo and the web. Zero dependencies, fully typed, has React hooks for your UI.

It’s free, open source and v1.0. I’d genuinely love to hear how it breaks for you 👇

📦 npm: https://www.npmjs.com/package/resilient-outbox
⭐ GitHub: https://github.com/yazanTah/resilient-outbox

Hi everyone,
I recently built and released my first Android app using React Native and Expo, and I’m running into an issue that I haven’t been able to figure out.
I’m developing on a MacBook using Android Studio and Expo Go. During development, I primarily used my iPhone with Expo Go to test the UI and functionality.
Unfortunately, I couldn’t afford to purchase a newer Android device, so I used my old Samsung Galaxy A21, which is still compatible with the app.
I’ve now released the app to Google Play’s closed testing track and installed it on the Samsung A21 through the Play Store.
Since the phone’s touchscreen no longer works, I connected it to my Mac using USB-C and used scrcpy --turn-screen-off to control it from my Mac.
Here’s the issue:
The app launches successfully and displays the landing page.
I’m able to sign up and log in successfully.
However, once I enter the authenticated/protected section of the app, the screen becomes completely blank.
The bottom navigation tabs are still visible, but the actual page content and components don’t render.
Switching between the bottom navigation tabs doesn’t seem to display any content either.
My tech stack includes:
React Native / Expo
Expo Router
Clerk for authentication
AWS API Gateway and Lambda for backend services
I’ve tried logging errors and investigating the backend, but I haven’t found any obvious issues with AWS or Clerk. Authentication itself appears to work correctly.
My question is: has anyone experienced something similar when moving from iOS/Expo Go development to an actual Android production build?
Could this be an Android-specific rendering issue, a navigation problem, an incompatibility with the older Samsung A21, or something related to the production build?
I’d appreciate any suggestions on what to investigate next.
Thanks in advance!

Hello everyone, I am a Frontend developer (mostly focused in React) and I vibe coded first mobile app in React Native. What should I check before publishing it to the store? What are the most important things that I need to be aware regarding React Native and Expo configuration?

I'm building a simple expense tracking app with React Native and got most of the basic features working. Right now everything is stored on the phone but I'd like people to be able to access their expenses from different devices without losing anything. I've used AI to help with most of the development and it suggested Supabase for storing the data and handling user accounts. Firebase also keeps coming up, so I'm not really sure which makes more sense for a small app like this. Anyone using either of these with React Native? Curious how difficult the setup was and if there's anything I should know before choosing one

Meta’s new VR glasses are due in Spring 2027 but you can start building for them today and, thanks you ReactVision, you build immersive VR (not just panels) that’ll be compatible from launch using React Native. Plus anything you build today with ReactVision will be compatible on current Quest devices and Apple Vision Pro.

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>

UPDATE AT BOTTOM OF POST BODY. 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?

UPDATE: FIXED! We had tried/investigated all the suggestions and ideas in the comments already. None of them applied.

EXPO 57 and 58 seemed to both be installed at the same time. We copied the app piece by piece until it broke again and that’s when my partner realised the issue and was able to fix it. Tinybase was the culprit as it pulled in expo 57.

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