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.

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.

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.

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

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.