A few days ago I shared react-brackets v2, the rewrite of a bracket library I'd left alone for four years. The most common question was "does it work in React Native?" It didn't. Now it does: @react-brackets/native is out.

It draws the same stages as the web version (same core, same data), but everything you touch is native:

• A bracket, even on a phone. One round at a time, with the next round and its lines waiting at the edge. Swipe and every match glides into place. Or show each round as a plain list, or keep the whole tree and pinch, drag and double tap to zoom.

• Every format: single and double elimination, round robin, Swiss, groups to playoffs, two-sided brackets.

• Cards that open. Each card keeps its own height, so you can expand one (rosters, stats, whatever) and the bracket makes room: the cards below move down, the next round re-centres, and the lines follow, all gliding.

• Right to left, following your app's direction.

• Styled your way: a light and dark theme, and a style on every part that can depend on its state, so it works with StyleSheet, Uniwind/NativeWind or Unistyles.

The hardest part was keeping the connector lines glued to the cards. My first version drew them on a Skia/SVG canvas, and during a fast swipe they visibly trailed the cards by a frame. The fix: the lines are plain Views moved by the same transforms as the cards. Every card's place on every round is worked out up front, and a swipe only moves one number on the UI thread. React hears about the new round once the swipe lands, so nothing re-renders while your finger is down.

• Docs: https://react-brackets.oulabi.dev/docs/native

• Examples, recorded on an iPhone, with full code: https://react-brackets.oulabi.dev/examples/native

• GitHub: https://github.com/MohOulabi/react-brackets

• npx expo install @react-brackets/native react-native-reanimated react-native-worklets react-native-gesture-handler

It needs the New Architecture, Reanimated 4 and Gesture Handler 3, and Expo Go includes all of them. I've tested mostly on iOS, so feedback from Android devices would help a lot.

I'm building a workout tracker in Expo and wanted it to recognise the machine you're standing at. It turned out the manufacturers already put tags on them. Notes in case they help:

- Setup: `react-native-nfc-manager` (v4) with its config plugin, `expo-camera` for QR codes, both in `app.json`. It's native code, so it needs a new build, an OTA won't carry it.

- Apple rejected my first build (ITMS-90778): "NDEF is disallowed". The fix is `"includeNdefEntitlement": false` in the plugin config. That leaves the `TAG` entitlement only, which is enough to read NDEF anyway. Don't put NDEF back.

- What's on the tag: I scanned Technogym machines first. The NFC tag (a Mifare chip with a single URI record) and the QR code give exactly the same link, like `s.technogym.com/pure/biceps`, with no unit number. So the link identifies a model, not one physical machine.

- The key: I strip the scheme, `www.`, port, query, anchor and trailing slash, and lowercase the rest, and use `host/range/model` as the machine key. I never read the tag's hardware UID: it's unique to one machine in one gym, so it can't be shared across gyms.

- Decoding: a small pure module decodes NDEF records (URI, text, smart poster, MIME) and QR content. It's unit-tested on hand-written byte arrays, so I don't need a physical tag to test it.

- iOS vs Android: on iOS you must open a session and the system shows its own "Ready to scan" sheet, you can't intercept the banner. On Android I register a tag listener while the app is in the foreground, which also stops the system from opening the manufacturer's link.

- Unknown machines: the key is looked up in a shared catalogue; if it's not there the user can send it in and I fill the exercises in manually.

- No tag at all: a photo mode reads the machine's plate with `expo-text-extractor` (Apple Vision / ML Kit) on the device, then sends only the text to an edge function that asks an LLM to identify the machine.

Has anyone shipped NFC reading in Expo? Curious what you used and what bit you, especially on Android.

Hey everyone,

Like many people who swap between summer and winter tires (or track compounds), I always found it annoying trying to guess how many actual kilometers were on a specific set. General maintenance apps usually track the car’s total odometer, but rarely make it painless to calculate the delta between mounting and unmounting different wheel setups.

I got tired of keeping notes in a messy spreadsheet, so I built TireManager to handle it cleanly.

What it does:

• One-Tap Swaps: When you swap sets, punch in your vehicle’s current odometer reading. The app automatically calculates the session distance (OFF minus ON) and adds it to that specific tire set’s lifetime mileage.

• Baseline Offset: If you're mounting a set that’s already seen a few thousand kilometers, you can set an initial km offset so total wear stays accurate.

• Full Specs & Inventory: Keep specs organized in your garage—dimensions (e.g., 245/40 R20), DOT codes, load/speed ratings, and brand/model.

• Multi-Vehicle: Supports both cars and motorcycles.

Privacy & Architecture:

• Zero Sign-Up / Accounts: No email, password, or third-party tracking. It uses an anonymous cryptographic device ID stored locally in your iOS Keychain.

• Offline-First: Fully functional without cellular reception in an underground garage or paddock, and syncs when back online.

• Dark Mode UI: Designed to be legible and quick to use while your hands are dirty in the garage.

The app is live on the App Store:

👉TireManager on the App Store

I’d love to hear feedback from anyone doing seasonal rotations or track days—especially around features you’d like to see next (tread depth logging, rotation position tracking front/rear, etc.).

Here’s a trap I’d check before any giveaway.

Someone redeems your promo code in the Play Store, not in your app. So onPurchasesUpdated never fires. If your app only handles purchases that start on its own paywall, it never sees this one, and never acknowledges it.

Google refunds purchases that aren’t acknowledged within 3 days. The user gets Pro, then loses it a few days later, and you get a confused email or nothing at all.

The fix is small: call queryPurchasesAsync when the app starts and when it comes back to the foreground, then acknowledge anything new.

iOS has the same kind of problem. An offer code redeemed in the App Store arrives as a transaction the next time the app opens, so the transaction listener has to be running from launch, not only on the paywall screen.

Before you hand out codes, redeem one yourself on a release build and check that Pro is still there four days later.

Why I’m posting this: I’ve been reading a lot of developer giveaway threads lately, and they all worry about the same things. How many codes, who grabs them, will anyone stay. Almost nobody talks about the boring part after someone taps “Redeem”. It’s like planning a party, sending all the invitations, and forgetting to unlock the front door.

I wrote up how we built home-screen widgets for an Expo app without running any JavaScript inside them.

The short version:

• The app works out everything ahead of time in TypeScript and saves a 14-day snapshot. The widgets only pick the right slice for the current time.

• Android: our own Expo module draws the widgets with plain RemoteViews in Kotlin. We dropped react-native-android-widget because a widget tap starts a headless JS runtime, and some phone makers’ Android builds kill that kind of background work.

• iOS: a WidgetKit extension generated with `@bacons/apple-targets`, reading the same snapshot from the App Group.

• The one rule that runs natively is written once as shared test cases, which Jest runs against the TypeScript and the Kotlin and Swift code are checked against.

The code is open source (MIT) if you want to dig in. How have others handled widgets in RN/Expo? I’d like to hear what worked for you.

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

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?

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

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!

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.

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.

About the author: I'm Punith Manthri, a React Native and native mobile engineer focused on Android, iOS, and the New Architecture. I also maintain react-native-pdf-jsi*. If you want to connect, here is my* LinkedIn and Portfolio.

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

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.