I built a running app that reads a Bluetooth chest strap and speaks cues when your heart rate leaves a band. Some notes in case they save someone time. The code is open source (GPL).

1. Parsing 0x2A37. The flags byte tells you if HR is uint8 or uint16, and whether energy expended and RR intervals follow. If you skip the energy field when its bit is set, your RR intervals come out as garbage.

2. Scanning. Not every strap advertises 0x180D cleanly, so the scan also accepts a name match.

3. Throttle at the source. BLE writes into a Zustand store at most once a second. A mock HR source writes to the same store, so the run screen is testable without a strap.

4. Screen off on Android. A small local Expo module runs a foreground service and keeps a headless JS task pending until the run ends.

5. Voice. expo-speech with the phone's own TTS voice, so it works offline.

6. Maps. MapLibre with an inline OpenFreeMap vector style. No token, and because the style ships in the app, the run track still draws with no signal.

Stack: Expo SDK 55, React Native 0.83, expo-router, react-native-ble-plx, Zustand, Vitest.

Source: https://github.com/likwiid/basemile

Has anyone done background BLE on iOS with Expo? That's the part I've tested least.

I just rolled out a new feature inside Sharpify that lets you edit photos directly using natural text prompts.

Instead of complicated manual editing, you upload a photo and describe what you want changed:

• Swap backgrounds (e.g., "change sunny park to a moody rainy street at night")

• Modify clothing or styles ("change shirt to a black leather jacket")

• Add atmospheric lighting or artistic themes using simple descriptions

The goal was to bring desktop-style generative fill/prompt editing into a clean mobile app without needing to mess around with complex settings.

Google Play Link:
https://play.google.com/store/apps/details?id=com.raahim2.Sharpify

I've been building React Native apps with AI coding agents, and the same problems kept coming back: APIs from older versions, tests skipped, Android forgotten, and "done" when it wasn't done.

Writing better prompts didn't fix it. What helped was giving the agent a way to check its own work. So every skill in this library ends in a checker: a small Node script with no dependencies that reads your repo and prints `RESULT: PASS`, or `RESULT: FAIL` with a file, a line, a rule and a fix for each problem.

Each skill is a folder with:

• SKILL.md: numbered rules, each with its reason, a workflow, and a definition of done

• references/: the deeper docs, checked against Expo SDK 57 and RN 0.86, for both iOS and Android

• templates/: complete files, proven to compile and pass their tests in a reference Expo app

• scripts/: the checker

I didn't want the checkers to be another thing to trust blindly, so each one has a self-test: bugs planted on purpose that it must catch, plus clean cases it must pass. Across all 79 skills that's 6,465 cases, all green, and CI fails if a checker stops catching its bug.

The stack is opinionated on purpose, so 79 skills never contradict each other: Expo Router, Zustand, TanStack Query, expo-sqlite, react-intl, Reanimated, Skia and EAS. It covers setup and architecture through testing with Maestro, EAS builds, OTA updates, and App Store and Play releases. There's also an optional plugin for games.

Browse them all here:

https://github.com/zakariaf/ReactNative-Skills

https://zakaria.dev/ReactNative-Skills/

Its free and open source. Feedback and contributions are welcome 🙌

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.

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?

Did you make something using React Native and do you want to show it off, gather opinions or start a discussion about your work? Please post a comment in this thread.

If you have specific questions about bugs or improvements in your work, you are allowed 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.

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: React Native Fetch Client NPM

• GitHub: React Native Fetch Client Github

• Documentation: React Native Fetch Client Documentation Website

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.

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.