Hey r/reactnative 👋

For the past few months I've been building Kinetik UI, a set of animated components for React Native + Expo. It's at 136 components now (plus 5 full screen templates), so I figured it was time to share it.

It works like shadcn: the components don't live in node_modules, they get copied into your project. So if you like one, it's yours to tweak however you want.

npx kinetik-ui add vinyl-player

Every component respects reduced motion, works with screen readers, and has its frame times measured on a real Android build, listed on its page.

There's also an MCP server (npx kinetik-ui mcp), so if you use Claude or Cursor you can just ask for "a music player card" and it finds and adds the right component.

Live demos: https://kinetik-ui.dev

If you have a component you love using in your own apps, PRs are welcome. Once it's merged, anyone can install it from npm or through MCP. I'd really appreciate any feedback too!

Hi there. Just wanted to share a nice animation I created (with claude ofc).

My app calculates your daily calorie needs from your body, everyday activity and training. Tell it how your target feels, and it adjusts the number until it fits you.

https://reddit.com/link/1x8ccbz/video/d8r03sssk1wh1/player

I primarily work with React Native, but lately I’ve been exploring native macOS development with SwiftUI.

That led me to Slice, a screen recorder and editor focused on smooth zooms, cursor animations, and polished recordings.

It’s been an interesting project to work on, and I’m making the source code available for people interested in exploring it.

Website: https://slice.rit3zh.dev/
GitHub: https://github.com/rit3zh/Slice

**Setup**

- React Native 0.87.1

- Xcode 27.1

- iOS Simulator (iPhone 18 Pro, iOS 27.0)

I've hit this a lot: the app dies on iOS, the JS console is quiet, and it's not obvious where to start. Most of the time the answer is on the native side, so here's the process I use. I call it RIFT.

**R – Reproduce**

Run the app from Xcode (not just from the terminal) and trigger the crash. Add a breakpoint near where you think it happens so you can pause instead of watching the app die.

**I – Investigate**

When it stops or crashes, look at the exception message and the backtrace in the left panel. In my example, a native module method called from JS threw an uncaught NSException, and the console printed the reason. Then in LLDB:

- `bt` – print the backtrace

- `frame select <n>` – jump to a specific frame

- `po` / `p` / `expression` – inspect values at that point

**F – Fix**

Change the actual cause in the native code (in my case, the method wasn't validating its input), not just the symptom.

**T – Test**

Re-run the exact same steps and confirm the crash is gone. Skipping this step is how "fixed" bugs come back.

I recorded a ~22 min live walkthrough of this on a real crash if it's useful to anyone:

https://youtu.be/oGq0yZ3z9ks

Happy to answer questions. What's your usual first step when a crash shows no JS error?

Hey yall - I’ve been working on a board game app, for mobile gaming. This is something that I’ve put a lot of time into, both playing it & designing it. The game is called Tessellata. It’s a strategy puzzle game, you gotta finish your board before your opponent & outscore them! It’s possible to play against the computer (bots, can’t really call it “AI” anymore) or against real players online! There is also local up to 4 player game play on one device option.

There is a tutorial & all, but feel free to ask me any questions you may have - if you try it! Available on both Google Play & the Apple App Store.

https://apps.apple.com/us/app/tessellata/id6782201050

https://play.google.com/store/apps/details?id=com.tessellataproduction.tessellata

Hey everyone! 👋

I've been working on Nitro WebView, an open-source React Native WebView implementation powered by Nitro Modules.

It's been a while since the initial release, and v0.2.1 is finally out! 🚀

What's new since v0.1.0?

• JavaScript ↔ Native messaging and script evaluation
• Navigation controls and cookie management
• File upload/download support
• Expanded WebView APIs
• WebView reload and message delivery optimizations
• More documentation and tests

Performance benchmarks 📊

I also built an E2E benchmark using React Native Harness to compare Nitro WebView with react-native-webview 16.0.0.

For 64B message round-trip latency:

• Android: ~38.7x faster (0.430ms vs 16.640ms)
• iOS: ~1.38x faster (0.112ms vs 0.154ms)

Nitro WebView also showed lower round-trip latency across 1KiB and 64KiB payloads.

Links

• GitHub: https://github.com/l2hyunwoo/nitro-webview
• Benchmark methodology & results: https://github.com/l2hyunwoo/nitro-webview/pull/49
• Documentation: https://l2hyunwoo.github.io/nitro-webview/

I'd love to hear your thoughts, especially if you've worked with WebView-heavy React Native apps or Nitro Modules.

Feedback, bug reports, and contributions are always welcome! 🙌

Hi guys
I have been working on a video editor SDK for a while, and recently released a version 0.2.0
The SDK aims to reduce the friction of adding a fully functional video editor into your existing app by a lot.
I did a post on the integration process here

https://nitrakit.dev/blog/react-native-video-editor/
Would appreciate feedbacks on how the DX is, because thats what matters the most to me.

And any thing you might want to do with it in your own app (that may be my SDK does not support yet)

Cheers!

When a React Native upgrade forces a Gradle wrapper or Android Gradle Plugin bump, what's your first move?

Do you check JDK compatibility, the wrapper version, plugin versions in third-party libraries, or something else? Any gotchas that took you longer than they should have?

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.

I've seen developers struggle with issues where the app works in development but crashes in production, Gradle builds fail unexpectedly, or native errors are difficult to trace.

I wanted to build something practical that helps developers understand what went wrong, why it might have happened, and what to investigate next, without blindly relying on AI to guess the root cause.

I'm now looking for React Native and Expo developers willing to test it against real-world issues and share honest feedback.

If you've recently dealt with a frustrating build or crash issue, I'd love to hear about it. I'm especially interested in cases where the tool gets the diagnosis right, gets it wrong, or misses something important.

This is an early open-source project, and the goal is to make it genuinely useful to the community.

Thanks! 🙌

Hey everyone! 👋

Like many of you, I've been using Axios in React Native for years. But over time, I ran into a few persistent headaches in production apps:

• The 401 Token Refresh Race Condition: When a user's JWT expires, parallel requests on the screen trigger multiple simultaneous refresh calls, causing token rotation errors and unexpected logouts.
• The "3-to-4 Packages Tax": Having to stitch together axios + axios-retry + axios-cache-interceptor + custom offline logic just to get basic resilient networking.
• Legacy Bridge Overhead: Axios still relies on legacy XMLHttpRequest (XHR), whereas React Native's New Architecture (Bridgeless/TurboModules) is built natively around WHATWG fetch.

To solve this, I created react-native-fetch-client a modern, zero-dependency HTTP client designed specifically for React Native, Expo, and modern JS.

Key Features

• 0 Runtime Dependencies: Pure TypeScript, ultra-lightweight, and tree-shakeable.
• Single-Flight 401 Auth Mutex: When a token expires, all parallel requests pause behind a mutex, a single refresh call executes, and all queued requests replay automatically.
• In-Flight Request Deduplication: Prevents server thrashing when users rapid-tap filters or buttons.
• LRU Cache + Stale-While-Revalidate (SWR): Instant 0ms screen loads from cache with silent background updates. Supports persistent storage adapters like MMKV and AsyncStorage.
• Smart Retries & Circuit Breaker: Exponential backoff with full jitter to handle flaky mobile cellular connections in malls or elevators.
• Offline Request Queue: Queue actions (like "Add to Wishlist" or "Like") when offline and auto-sync when connection restores.
• 100% Familiar Axios-Like Syntax: Switching takes literally 2 minutes without rewriting your services.

Quick Code Example

import { createClient } from 'react-native-fetch-client';

export const api = createClient({
  baseUrl: 'https://api.example.com',
  timeout: 10000,

  // Instant caching with SWR
  cache: {
    enabled: true,
    ttl: 5 * 60 * 1000,
    swr: true,
  },

  // Flaky connection resilience
  retry: {
    maxRetries: 3,
    backoff: 'exponential',
    jitter: true,
  },

  // Zero-race-condition token refresh
  auth: {
    bearerToken: async () => await getAccessToken(),
    refreshToken: async () => {
      const { accessToken } = await refreshSession();
      return accessToken;
    },
  },
});

// Use it just like you always have:
const products = await api.get('/products');
await api.post('/cart', { id: 101 });

Links:

• npm: https://www.npmjs.com/package/react-native-fetch-client
• GitHub: https://github.com/arunkumarArjun/react-native-fetch-client

I've done React Native for about 7 years. This year I needed an Apple Watch app (plus iPhone and Mac), and React Native doesn't run on watchOS, so I had to go native. A few things I wish I'd known before starting:

1) SwiftUI feels familiar faster than you'd think. Views are a function of state, u/State works a lot like useState and an u/Observable class is close to a small store. The mental model from React carries over almost one to one.

2) The watch is a different world. The screen is tiny and the system suspends your app very quickly, so you can't count on it staying open. Anything that has to reach the user right away is better sent as a notification than kept alive inside the app.

3) Live Activities and the Dynamic Island are their own thing. They're SwiftUI widgets with tight limits on how often they update, and to update them from a server you need push tokens. Plan that early, it's not like updating a normal screen.

4) Signing is the real boss fight. Mac, iPhone, watch and the widget extension each need their own bundle ID, capabilities and profiles. Most of my lost hours were there, not in the code.

5) Xcode Previews replace hot reload, partly. They're good for layout, but anything that depends on real data or the watch talking to the phone has to be tested on device.

6) I used Claude Code as a tutor. I'd ask it for the Swift version of a React Native pattern I already knew and to explain the differences. That got me productive in days instead of weeks.

Would I go native again? For watch apps, widgets and Live Activities, yes. For a regular app with forms and lists I'd still pick React Native.

Happy to answer questions if anyone is thinking about doing the same.

https://reddit.com/link/1x6vwzt/video/u1v6txklsovh1/player

I'm the lead dev on Buoy. The film is inspired by my real life.

I've built with Buoy every day for years. Now I'm usually waiting on others. I have a lot of free time.

The problem was never my AI. It couldn't run my app, so it guessed.

So we built two things. Both are 100% free.

• Buoy Optimize is a skill for your coding agent. It writes 20 or more ideas. It builds each one and times it with Bench. It keeps the winners and goes again.
• The Sim Farm gives each idea its own iOS sim. A normal sim uses about 5 GB. A slim one uses about 1.5 GB. 10 slim sims used 15.4 GB.

How it stays fair:

• Looks and memory are checked on every sim at once.
• Speed is timed on one quiet sim. Sims share your Mac's CPU.
• A busy Mac marks the run unfair, and the agent runs it again.
• Each app acts like an iPhone SE, so memory hogs get caught.
• You decide what looks right. Check the winner on a real phone.

Fair notes: it needs a Mac with Xcode. It's iOS sims only. Slim sims have no push, purchases, app links, widgets or Spotlight. Your app needs Bench in a dev build. The app and numbers in the video are made up.

Try it: npx -y @buoy-gg/mcp@latest init Then ask your agent: "Use buoy optimize and the sim farm on our slow feed screen." https://buoy.gg/sim-farm

What breaks for you?

I’m building a React Native/Expo mobile platform for educational video creators.
The app is already functional, including authentication, video uploads, playback, comments, notifications, creator accounts, and a backend built with Node.js, PostgreSQL, and Prisma.

The two biggest remaining integrations are:

Stripe: Creator onboarding, tips, paid subscriptions, revenue sharing, balances, and payouts.
Google Ad Manager: Video advertising, category-based targeting, and creator ad-revenue attribution.

I’m deciding between two approaches:

1. Implement the integrations myself using AI assistance and official documentation, then hire experienced developers for a comprehensive security, architecture, and financial-integrity audit.

2. Hire experienced developers to design and implement these systems from the beginning.

I’m not trying to avoid paying professionals. I’m trying to figure out where professional involvement provides the most value and which approach would be more cost-effective without compromising security.

For developers who have built similar platforms:

- Which approach would you recommend?
- What are the biggest risks of implementing these integrations with AI?
Would you trust a professional audit of an AI-assisted implementation?
- What would you expect to pay for implementation versus an independent audit?

I’d particularly appreciate feedback from developers experienced with Stripe Connect marketplaces or mobile ad monetization.

We're a small agency and we maintain a React Native app for a retail client, last week the agent picked up a ticket for a keyboard crash on Samsung phones and fixed it by changing our shared KeyboardAvoidingView wrapper, which also sits under the checkout screen.

The PR looked clean, coderabbit / bugbot didn't have any real complaints and honestly the diff was fine, the problem was the device. On smaller iPhones the pay button ended up hidden behind the keyboard and nobody on our side noticed because we all test on Pro Max or Android.

The client found it 3 days later from a drop in orders and estimated about $4k lost. Fix took 20 minutes.

We can't own every device and the agent touches shared components way more casually than a person would. How are you catching platform specific regressions when one PR can change both sides at once?

I've been using/developing this library only for the apps that i develop but decided to publish it as MIT open source so everybody could take benefit of it.

It has support to all the authentication types mobile devs can imagine(at least the main ones) and it works with expo and react-native and the idea behind it's to keep updating as the Android/IOs ecossystem grows.

The library is fully tested and published on npm:

https://www.npmjs.com/package/react-native-oauth-essentials

Any issues, PR's or forks feel free to reach out on: https://github.com/lucaswitch/react-native-oauth-essentials

I posted here 2 months back, from my other acc which got banned, about getting too many device specific bugs every release.

I changed my setup about 1 month ago and since then I haven’t had a single device specific bug make it to production and that used to happen 2 or 3 times a month. Last week I pushed a full onboarding refactor, changed screens, renamed buttons, moved things around and everything just works.

My CTO brought it up in standup because our bug reports literally disappeared and I tired hard to explain it without sounding like I was bragging haha. Transitioning to a guy whose releases just work is a strange feeling if you ask me.

anyway just wanted to update since many people helped me out last time. Thank you so so much !!

I’m a beginner looking to build my first iOS app, with the eventual goal of publishing it to the App Store.

One thing I’m trying to avoid is downloading a bunch of development software, dependencies, and project files onto my MacBook. I’d prefer to keep my laptop as clean and uncluttered as possible. I’m a MacOS user.

I asked ChatGPT whether I could handle most or all of the development in the cloud, and it suggested the following setup:

GitHub: Store the code in a private repository.
React Native + Expo + TypeScript: Build the actual app.
Supabase: Handle the database, authentication, and user data.
ChatGPT Work / cloud development environment: Write and manage the code remotely rather than locally.
Expo EAS Build: Build the iOS app in the cloud.
TestFlight: Test the app on my iPhone before eventually publishing it.

According to ChatGPT, I could potentially avoid installing Git, Node.js, Xcode, VS Code, and other development tools on my Mac, at least initially.

The app itself is a database/-library with search, workout creation, tracking, user accounts, and eventually AI features.

I’m not against installing software if it’s genuinely necessary. I just don’t want to clutter my computer with tools and files I don’t actually need.

A few questions for people who have experience with this:

Is this actually a realistic workflow for building and eventually publishing a fully functional iOS app?
Can development, testing, debugging, and App Store deployment really be handled almost entirely in the cloud?
Would you recommend this approach for a beginner, or am I making things unnecessarily complicated by avoiding local development?
Are there any major limitations, additional costs, or headaches with this setup?
If you were starting from scratch and wanted to keep your computer as clean as possible, what setup would you recommend?

I’m open to alternative tools or workflows. My main priorities are keeping things simple, avoiding unnecessary local installations, and building something that can eventually become a legitimate App Store app.

Appreciate any advice, especially from anyone who’s tried a similar cloud-first workflow.

My Xiaomi Mi TV only came with the physical remote, and every single time I turned the TV on I'd spend the first few minutes digging through couch cushions looking for it. My phone is always in my hand anyway, so I figured it should just be the remote.

Turns out Mi TVs run a system service called MiLink on TCP port 6091. Xiaomi's own phone remote apps use it, but the protocol isn't documented anywhere. So I pulled the service APK off the TV, decompiled it, found the packet classes, and checked every field against the TV's logcat while sending test packets. The format ended up being pretty simple: a type byte, a length, then TLV-encoded Android key events.

From there I built a remote for Android and iOS with Expo, plus a SwiftUI menu bar app for macOS that uses the same protocol.

The RN side, which is probably the interesting part here:

- The protocol layer is plain TypeScript (frame encoding, TLVs, key mapping), and it's unit tested
- Raw TCP sockets don't really exist in JS, so I wrote a local Expo module: Swift with the Network framework on iOS, Kotlin on Android
- Discovery is in the same native module. Mi TVs advertise `_googlecast._tcp` with a `md=MiTV-…` TXT record, so I browse with `NWBrowser` on iOS and `NsdManager` on Android
- Hold-to-repeat on the D-pad and volume, haptics, auto-reconnect with heartbeats, and a live latency readout (the TV echoes back each key's id)
- There's no text packet in the protocol, so "type on TV" maps each character to an Android keycode plus Shift. No more typing passwords letter by letter with the D-pad

**The bug that ate a whole evening:** I was sending the device's clock in `downTime`/`eventTime`. The TV treated those events as "in the future" and its input dispatcher just stalled until that time arrived. The fix was to send 0 and let the TV stamp the events itself. Also, the TV auto-releases a key about 175ms after the last DOWN, so held buttons resend DOWN every 100ms with an increasing repeatCount.

No pairing and no ADB. The phone just needs to be on the same Wi-Fi as the TV.

GitHub Actions builds the APK, an unsigned IPA (you sideload it with your own Apple ID), and a DMG on every push, with no secrets needed.

I've tested all three (iOS, Android, macOS) on a real MiTV-AXSO0 (Android TV 9, PatchWall), and everything works. Other Mi TVs running PatchWall should work too, as long as they have the MiLink service. You can check yours with `nc -z -w 3 <tv-ip> 6091`. If you try it on a different model, I'd love to hear whether it worked.

Repo: https://github.com/EndLess728/MiTV-Remote

Happy to answer questions about the native module setup or the reverse engineering.

NOTE - The post is written by AI and i used REA to reverse Engineer it and make an working app out of it

What problems or pain points do you regularly face while building React Native apps that you wish had a better solution?

Anything repetitive, difficult, outdated, deprecated, or something you often have to build yourself?

Would love to hear what you've struggled with.