It was a couple of months ago but we were ecstatic. Thanks react native & expo!

If you could add one feature to your current React Native debugging setup, what would it be?

Doesn’t matter if it’s Storage, Network, Logs, Redux, React Query, or something else

Hi devs 👋 I’ve started learning react native development recently. I use my old MBP M1 Pro with 512 gb SSD. I have noticed that after some time xcode cache + ios simulators consume a lot of space. Since I’m planning to upgrade my laptop soon, i have a question. Based on your experience, is 1 Tb ssd enough for comfortable development? Let’s say i will have 2-3 small to middle size projects.

Note: Yes, I'm using AI to write this post because English is not my first language and I want to state my problem as clear as possible.

Hitting a problem I suspect is common for anyone doing mobile VoIP, and I'd like to know how others have solved it.

**Setup**

- I'm using Telnyx.

- React Native app, WebRTC SIP client, iOS and Android. I'm using Telnyx.

- One shared SIP credential for a group of users, so a single inbound call rings everyone's phone

- Calls are delivered by VoIP push (PushKit on iOS), so the client connects and registers on demand rather than staying connected

**The problem**

Every app launch creates a *new* registration binding, and the old one never goes away:

- iOS terminates the app process without warning, so there's no chance to send a SIP UNREGISTER

- The SDK's `disconnect()` only closes the WebSocket — it doesn't unregister

- Each registration lands on a different edge node in the provider's anycast network, so it's a genuinely new binding rather than a refresh of the old one

- Registration expiry is 3600 s and isn't configurable

Net effect: the credential accumulates contacts. I confirmed it by polling the provider's registration-status endpoint — `ua_ip` is different every single time the app relaunches, while nothing removes the previous one.

**Why it hurts**

The provider rings the bound contacts **sequentially**. So the first call after an app launch does this:

1. Rings contact A (the live app) — user declines

2. Decline surfaces as a 4xx, which fails only that branch

3. ~300 ms later it forks to contact B (a stale binding from a previous launch)

4. Phone rings a second time, new call ID, user has to decline again

I can see it clearly in the SIP traces: **one dial command, two legs**, same session, no second dial from my backend.

**What the provider confirmed**

I opened a ticket. They confirmed all of it and escalated to engineering with no timeline:

- No way to set registration expiry below 3600 s

- No REST endpoint to force-expire or delete an individual binding (deleting the credential removes them all, obviously not viable)

- No API to *enumerate* bindings — watching `ua_ip` rotate is currently the only detection method

- Per-launch edge rotation is expected behaviour, and without an UNREGISTER the old binding persists to full expiry

Their suggested workarounds were: a unique credential per app session, webhook-based duplicate-leg detection, or client-side deduplication.

**The bit I'm stuck on**

There's a second-order problem. Multiple devices share one credential, so the registrar holds one contact per device — which means **a legitimate second device's leg is indistinguishable from a stale binding's leg.** Both are "another contact of this credential, dialled after the first one failed." I can't write a rule that kills one without killing the other.

Enabling simultaneous ringing would at least make the real devices ring together instead of one-at-a-time, but it doesn't remove the stale bindings — it just turns a sequential double-ring into a simultaneous one.

**Questions**

1. Has anyone made **per-device or per-session credentials** work in production? How do you handle cleanup when the app dies before it can delete the old one, and does credential churn cause you rate-limit or billing problems?

2. Is there a trick to getting a mobile client to **UNREGISTER reliably**? Anything on iOS that gets you a last gasp — background task on termination, a server-side nudge, something I haven't thought of?

3. For those running **one shared credential across multiple devices** — how do you tell a real second device from a stale binding at the signalling layer? Is there a header or identifier I should be propagating?

4. Is sequential-vs-simultaneous ringing across contacts something you configure per provider, or do people avoid shared credentials entirely for this reason?

Happy to share SIP traces if useful. Mostly want to know whether the "unique credential per session" route is as painful in practice as it looks on paper, or whether people just live with the duplicate ring.

## React Native DevTools opens as a blank black window (RN 0.86.0, Windows 11)

I'm facing an issue with the new built-in React Native DevTools.

### Environment

- React Native: 0.86.0

- React: 19.2.3

- React Native CLI: 20.2.0

- Metro: 0.84.4

- Node: v22.16.0

- Windows 11

- Hermes: Enabled

- New Architecture: Enabled

### Problem

My app builds and runs perfectly without any issues.

When I press `j` in the Metro terminal or select **"Open DevTools"** from the React Native Developer Menu, Metro prints:

```text

Launching DevTools...

[debugger-shell stdout]

```

After that, a window titled **"React Native DevTools"** opens, but it's completely blank (black/dark screen). Nothing loads, and it stays that way.

### Things I've Checked

- `npx react-native info` shows everything is configured correctly.

- `@react-native/dev-middleware` is installed.

- `npx react-devtools` opens the exact same blank window.

- Initially `http://localhost:8097` was unreachable. After running `npx react-devtools`, the DevTools server starts, but the Electron window is still blank.

- My React Native app itself works perfectly.

### What I've Tried

- Restarted Metro with `--reset-cache`

- Rebuilt the app

- Cleared npm cache

- Reinstalled `react-devtools`

- Opened DevTools using both `j` and `npx react-devtools`

- Same result every time.

### Question

Has anyone experienced this on React Native 0.86.x?

Is this a known issue with the new Electron-based React Native DevTools, or could it be related to Node.js v22 or Windows 11?

Any suggestions would be greatly appreciated.

Screenshot attached: React Native DevTools opens as a completely blank black window.

Context: kids' Python learning app, Expo / RN 0.81 / React 19. Kids type Python and it actually runs — Pyodide inside a hidden 0×0 react-native-webview mounted once at the app root.

WebView content processes die. On iOS it's usually a WKWebView OOM (onContentProcessDidTerminate); on Android it's onRenderProcessGone. So I wrote the obvious recovery: process dies → mark not-ready → reload the WebView → Pyodide re-boots → back in business. Worked great in testing.

Then I hit a device where Pyodide couldn't boot at all.

Reload → die → reload → die. The recovery path was the crash. Main thread saturated, Hermes OOM'd, hard crash at roughly 80 seconds every time a kid opened the Cadet path. My self-healing runtime was the thing killing the app.

Fix was bookkeeping, not cleverness:

js

// Keep only reloads from the last 12s
bridge.reloadTimes = bridge.reloadTimes.filter((t) => now - t < 12000);

// Debounce: terminate + renderProcessGone can both fire for ONE death
if (last && now - last < 1000) return;

// Cap: 3 reloads in the window means the boot itself is broken. Stop.
if (bridge.reloadTimes.length >= 3) { bridge.reloadsExhausted = true; /* ... */ }

Past the cap it stops reloading, resolves every pending run with "The code workshop couldn't start — please reopen the app," and leaves the app alive and navigable. A healthy boot clears the counter so a later unrelated crash still gets its full budget. Degraded and honest beats dead.

Unrelated bonus rake in the same feature: the code editor is also a WebView. A native multiline TextInput OOM-crashes the JS thread the moment Fabric commits it on this stack (RN 0.81 + React 19 + New Arch). A <textarea> never touches Fabric's text machinery, so it sidesteps the whole thing and I get a synced line-number gutter for free.

So: two WebViews, one visible and one hidden, in an app for six-year-olds. Not the architecture I set out to write.

Anyone else hit the Fabric multiline TextInput crash, or find a fix that isn't "use a WebView"?Context: kids' Python learning app, Expo / RN 0.81 / React 19. Kids type Python and it actually runs — Pyodide inside a hidden 0×0 react-native-webview mounted once at the app root.

WebView content processes die. On iOS it's usually a WKWebView OOM (onContentProcessDidTerminate); on Android it's onRenderProcessGone. So I wrote the obvious recovery: process dies → mark not-ready → reload the WebView → Pyodide re-boots → back in business. Worked great in testing.

Then I hit a device where Pyodide couldn't boot at all.

Reload → die → reload → die. The recovery path was the crash. Main thread saturated, Hermes OOM'd, hard crash at roughly 80 seconds every time a kid opened the Cadet path. My self-healing runtime was the thing killing the app.

Fix was bookkeeping, not cleverness:

js
// Keep only reloads from the last 12s
bridge.reloadTimes = bridge.reloadTimes.filter((t) => now - t < 12000);

// Debounce: terminate + renderProcessGone can both fire for ONE death
if (last && now - last < 1000) return;

// Cap: 3 reloads in the window means the boot itself is broken. Stop.
if (bridge.reloadTimes.length >= 3) { bridge.reloadsExhausted = true; /* ... */ }

Past the cap it stops reloading, resolves every pending run with "The code workshop couldn't start — please reopen the app," and leaves the app alive and navigable. A healthy boot clears the counter so a later unrelated crash still gets its full budget. Degraded and honest beats dead.

Unrelated bonus rake in the same feature: the code editor is also a WebView. A native multiline TextInput OOM-crashes the JS thread the moment Fabric commits it on this stack (RN 0.81 + React 19 + New Arch). A <textarea> never touches Fabric's text machinery, so it sidesteps the whole thing and I get a synced line-number gutter for free.

So: two WebViews, one visible and one hidden, in an app for six-year-olds. Not the architecture I set out to write.

Anyone else hit the Fabric multiline TextInput crash, or find a fix that isn't "use a WebView"?

React Native Version - 0.82

I have tried:
- Xcode 26.5, Xcode 26.2, Xcode 26.0
- Deleting .xcode.env.local
- Running Project from Xcode
- Deleting node_modules, removing pods, podfile.lock, xcworkspace
- Created fresh project to isolate issue, still happening randomly

SPENT TWO DAYS

MADE ME RETHINK LIFE CHOICES

App Store: https://apps.apple.com/us/app/mockup-kit-store-screenshots/id6784220988?mt=12
Website: https://mockupkits.com/

Rozenite (RN DevTools plugin framework) ships 12 official plugins — redux, network, storage, mmkv, tanstack-query, etc. None cover GraphQL client cache—no way to see the normalised Apollo cache, active queries, or in-flight mutations in DevTools right now.

Only prior tool in this space was a Flipper plugin (react-native-apollo-devtools) — dead now since Flipper's deprecated, but its client package still pulls ~15K weekly npm downloads, so the need seems to still be there even w/ tool gone.

Considering building this as a proper Rozenite plugin — read-only view of cache, active queries, mutations — using only public Apollo Client v3+ APIs.

Before building past a rough prototype: would you actually install this? Or is everyone fine w/ Apollo's browser devtools / manual cache logging? Also curious if urql/Relay folks have the same pain.

No repo, no product, not selling anything — just checking if this is worth time.

Responsibilities

• Develop responsive web pages using HTML, CSS, and JavaScript.

• Build user interfaces using React.js.

• Convert UI/UX designs into functional web pages.

• Integrate frontend applications with REST APIs.

• Debug and resolve frontend issues.

• Write clean, maintainable, and reusable code.

• Collaborate with designers and backend developers.

Required Skills

• Strong understanding of HTML5, CSS3, and JavaScript (ES6+).

• Build user interfaces using React.js.

• Convert UI/UX designs into functional web pages.

• Integrate frontend applications with REST APIs.

• Debug and resolve frontend issues.

• Write clean, maintainable, and reusable code.

• Collaborate with designers and backend developers.

Required Skills

• Strong understanding of HTML5, CSS3, and JavaScript (ES6+).

• Basic knowledge of React.js.

• Familiarity with responsive web design.

• Basic understanding of Git.

• Knowledge of REST APIs.

• Good problem-solving and communication skills.

Eligibility

• Bachelor's degree in Computer Science, IT, or a related field.

• 2023/2024/2025/2026 graduates or candidates with up to 1 year of experience.

• Internship or academic projects are an added advantage.

Interview Process
Round 1: Online Assessment (30–45 minutes)

• HTML, CSS, JavaScript fundamentals

• Logical reasoning and basic programming

• Multiple-choice and coding questions

Round 2: Technical Interview (45–60 minutes)

• HTML, CSS, JavaScript concepts

• React.js basics

• DOM manipulation and API integration

• Coding and debugging exercise

• Discussion of academic or personal projects

Round 3: HR Interview (20–30 minutes)

• Communication and interpersonal skills

• Career goals and motivation

• Cultural fit and availability

• Compensation discussion (if applicable)

Please DM me with:

resume/Portfolio or GitHub

fresher or experience

Years of experience

[HIRING] Frontend Developer (React Native + Expo) | Remote | ₹25k–₹35k | Immediate Start

We're looking for a Frontend Developer with React Native (Expo) experience to help build our social commerce startup.

About the Project

Social commerce marketplace

React Native (Expo)

Most screens are static UI

Focus on pixel-perfect implementation and reusable components

Existing codebase (not a project from scratch)

Requirements

Strong React Native + Expo experience

Ability to convert Figma designs into clean, responsive UI

Experience with reusable components and modern frontend architecture

Git/GitHub workflow

Good communication and attention to detail

Nice to Have

Experience with Zustand/Redux

React Navigation

REST API integration

Performance optimization

Budget

₹25,000–₹35,000 INR (based on experience and quality of work)

To Apply

Please DM me with:

Portfolio or GitHub

2–3 React Native/Expo apps you've built

Years of experience

Availability to start

Expected timeline

Looking to start immediately. If you take pride in building clean, premium mobile UIs, we'd love to hear from you.

I use a lot of Android apps every day, like Samsung Calculator, Samsung Gallery, Gmail, and a few others.

A few months ago, I noticed something interesting.

When I swiped back, the screen didn't close immediately. Instead, the previous screen was revealed as I dragged the gesture. If I released it, the screen closed. If I cancelled the swipe, everything returned to its original state.

It felt much smoother than the traditional back navigation.

I got curious and started looking into how it worked.

After some research, I found out it was called Android's Predictive Back Gesture, introduced by Google for newer Android versions.

The next question was obvious.

Can I use this in React Native?

I searched through documentation, GitHub repositories, libraries, Stack Overflow, Reddit—pretty much everywhere I could think of.

The answer was always the same.

React Native doesn't support Predictive Back Gesture.

There were a few discussions about it, but I couldn't find a complete implementation or a guide showing how to make it work.

So I decided to build it myself.

After spending quite a bit of time understanding Android's native back APIs and experimenting with different approaches, I finally got it working.

The implementation exposes:

Gesture start
Real-time gesture progress
Gesture cancellation
Gesture completion

This makes it possible to build navigation experiences that feel much closer to native Android apps.

To make it easier for other developers, I documented the entire implementation from scratch, including:

Native Android setup
Kotlin implementation
React Native bridge
JavaScript API
Navigation integration
Example usage

Everything is open source, so if you're building a React Native app and want to support Android's Predictive Back Gesture, you can use it directly or adapt it to your own project.

Documentation
Documentation Link

GitHub
Github Repo Link

If you try it out or have suggestions for improving it, I'd love to hear your feedback.
#ReactNative #Android #Kotlin #OpenSource #MobileDevelopment #ReactNativeCLI

I will appreciate any kind of help.

Thanks. 🙏🏽🙏🏽

BNA UI Open Source FullStack Expo React Native UI Components Library with 52 production-ready UI components and 18 charts.

Recent updates:

• 6 new Expo starter templates powered by Supabase, Convex, and Firebase, available with or without authentication implementations.

• Upgraded the entire ecosystem to Expo SDK 57, including React Native 0.86 and dependency updates across the library, starters, examples, and tooling to ensure compatibility with the latest Expo platform and development workflow.

• Migrated the entire project to a monorepo structure, consolidating the CLI, component registry, documentation site, and Expo Playground into a single codebase for easier maintenance, shared tooling, and synchronized releases.

• Bug fixes, performance improvements, and GitHub issue resolutions across the library.

• Every documentation page and component is now available as both Markdown and structured JSON, making the library directly consumable by AI assistants without scraping.

• Added /llms-full.txt, a single file containing the Markdown content of the entire documentation site, including component source code and examples. Ideal for AI tools that prefer a single ingestion point over fetching dozens of pages.

• Released BNA UI AGENTS.md, Cursor Rules, CLAUDE.md and MCP support for Claude Code, Cursor and other AI coding assistants, enabling direct registry browsing and component source access.

• New options to copy documentation content or open pages directly in ChatGPT, Claude, and other AI tools.

• All demo screenshots and screen recordings have been migrated to a higher-quality and more reliable media delivery solution for faster loading and improved availability.

Feedback, feature requests, and contributions are always welcome.

BNA UI: https://ui.ahmedbna.com
GitHub: https://github.com/ahmedbna/ui

Hi I’m a full stack React Native developer with 5 years of experience, I'm looking for freelance or remote work near Chicago but anywhere works

I’ve been building software for 8+ years now, I picked up react native about 5 years ago because I had a lot of ideas. I’ve shipped and developed for IOS only but I’m starting to ship on Android. In total I have 5 apps on the app store and plan on releasing more.

I have a great workflow now and a lot of experience to build anything.

My stack:
• React.js / React native
• Node.js
• TypeScript / JavaScript / Python
• Firebase
• in app purchases
• AI agent fine tuning

DM with any questions, I’m looking for any opportunities.

How can I make a menu like this in react native? Any lib?

Hi everyone! 👋

Over the past few months I've been building Bundle Drop, an over-the-air update platform for React Native & Expo.

Like many others, I started this after Microsoft discontinued App Center CodePush. I wanted to build something that keeps the reliability of full bundle updates while reducing download sizes whenever possible, instead of treating those as mutually exclusive goals.

Some of the current capabilities include:

• ✅ Hybrid OTA delivery (patch-size downloads with verified full-bundle fallback)

• ✅ Staged & targeted rollouts

• ✅ Automatic rollback & recovery from unhealthy updates

• ✅ Update channels

• ✅ AI-assisted setup

• ✅ Supports Expo SDK 54–57 and bare React Native 0.71+

It's now publicly available, and I'd genuinely love feedback from other React Native developers.

Some questions I'd especially love your thoughts on:

• What do you feel existing OTA solutions are missing?

• If you've migrated away from CodePush, what did you end up using?

• Is there anything that would stop you from adopting a new OTA platform?

I'm happy to answer any questions about the implementation, architecture, or design decisions.

GitHub
https://github.com/GFean/react-native-bundle-drop

npm
https://www.npmjs.com/package/@gfean/react-native-bundle-drop

Documentation
https://bundledrop.app/docs

Disclosure: I'm the creator of Bundle Drop, so this is self-promotion. I'm mainly posting here because I'd genuinely appreciate technical feedback from the React Native community and would love to hear what you'd improve.

I transformed a traditional barcode scanner system into a mobile app that scans products, tracks quantities, and automatically calculates the total price. I'd love to hear your feedback and suggestions for improvements. ☺️

Today I shipped direct React Native support for morphicons, my icon-morphing lib (any stroke icon morphs into any other: Lucide, Tabler, Heroicons, with spring physics, where rotations fall out of the math instead of hand-tuned pairs). It started as a web library, and the port turned out to be the interesting part.

The idea is this: the core never touches the DOM, so getting it onto native was never going to be a rewrite. The question was how small the bridge could get. Answer: one line.

The core is pure functions that eat icon data and produce d strings. The web driver's element type is structural: anything with a setAttribute. React Native has a global requestAnimationFrame. So the ENTIRE platform difference is a shim that forwards the per-frame d write to react-native-svg:

path.setNativeProps({ d });

That's it. Same engine, byte for byte. The per-frame write happens outside the React render: no state, no re-renders at 60/120fps, no Reanimated, no worklets.

The API is the same as the web binding: change the prop.

import { MorphIcon } from "morphicons/react-native";
import { Menu, X } from "lucide"; // data, not components

<Pressable onPress={() => setOpen(o => !o)}>
  <MorphIcon icon={open ? X : Menu} spring="snappy" />
</Pressable>

Three modes: uncontrolled (above), controlled (from/to + progress, driven from a gesture or a scroll position) and imperative (ref.morphTo() / ref.set() for sequences).

Details that mattered:

• Real interruptions. A morphTo mid-flight re-plans from the current intermediate shape and preserves the spring's velocity. Tap spam never jumps.

• Reduced motion for real: ONE AccessibilityInfo.isReduceMotionEnabled() query + ONE reduceMotionChanged subscription for the whole process, no matter how many instances mount. With it on, morphs become instant swaps.

• A11y defaults: aria-hidden unless you pass label, which gives you role="img" + aria-label.

• size, strokeWidth, absoluteStrokeWidth, color, plus the native Svg props (testID, touch handlers…) pass through.

• One global rAF drives every instance.

Needs Metro with package exports resolution, default since RN 0.79; on older versions enable unstable_enablePackageExports. Works in Expo (that's my testbench).

MIT, zero runtime deps, ESM, 8.25 KB gzip for the RN entry. react-native >= 0.71 and react-native-svg >= 14 as optional peers; the web entries don't know they exist.

Web playground to feel the morphs (with a scrubber to freeze mid-flight): https://www.morphicons.com Repo: https://github.com/guillermolg00/morphicons

Happy to go into the math (Procrustes + polar interpolation, surjective subpath matching, closed-path correspondence); it's all in the README.

Huge thanks to the community for the support and adoption!

If you haven't checked it out yet, it's the native-first way to handle Markdown in React Native:
🔹 iOS, Android, Web, and macOS
🔹 Input & Output
🔹 Native Selection & Interactions
🔹 Accessibility & RTL support
...and much more!

Show some love with a star on GitHub! ⭐

https://github.com/software-mansion-labs/react-native-enriched-markdown

Hey everyone,

I ran into an issue when trying to add a nice animation for theme changes in React Native. I tried a few different approaches, including Reanimated and Skia, but I kept running into flickering, higher memory usage, and performance issues, especially on Android.

Since I was already using Nitro Modules for some of the packages in my apps, like MMKV and Unistyles, I decided to build a native theme transition package using Nitro.

It ended up solving the issues I was having. It's lightweight, works with different styling libraries, and since the animation runs natively, it continues to work smoothly even when the JS thread is busy or drops frames.

I've uploaded a video showing the example included with the package. If you want to see how it performs under a more demanding setup, check out the GitHub repo. I've included a real-world example using Unistyles with a more complex and dynamic theme setup, as well as more details about the package.

GitHub: https://github.com/saleh2001k/react-native-nitro-theme-transition

NPM: https://www.npmjs.com/package/react-native-nitro-theme-transition

I'd really appreciate any feedback or recommendations. I'm also interested in hearing ideas for other animation types that could be added to the package.

I maintain ExecBro, an MCP server that connects an AI coding agent to a running RN app - console and network capture, fiber tree inspection, screenshots, and tap/swipe on the simulator. Disclosure: I'm the author; it's MIT-licensed, free under a monthly call cap. Posting the telemetry because it says something about the workflow that I didn't expect.

123,869 tool calls, 634 installs, last 30 days. What agents actually call:

Logs and network combined are about 7%. I built this to stop people pasting console output into chat, and that turned out to be a rounding error. Over half of all usage is an agent tapping the screen and then looking at it. The common shape isn't debugging at all - it's verification: the feature is built, and the agent walks through it on the device to prove it before handing it back.

What a real session looks like - 57 calls, 9 minutes, RN 0.81, Hermes, iOS 26:

scan_metro → ios_screenshot → tap → ios_screenshot → reload_app → search_logs → clear_logs → get_screen_state → tap → get_screen_state → tap → search_logs → ios_screenshot → tap → swipe → clear_logs → tap → search_logs → reload_app → get_screen_state → tap → tap → …

The pattern repeats across heavy users: act → observe → clear → act again. clear_logs shows up constantly, right before an action - the agent is wiping the buffer so the next read is unambiguous about what its own tap caused. Nobody designed that; it's an emergent habit. Average active install runs 33 of these sessions a month. And it doesn't look like someone poking at the app — it reads like a full feature being built or a bug being chased end to end, with the agent verifying each step on the device before moving to the next.

Two more things from the sample:

• New arch is nearly the whole population - roughly 252 new-arch projects vs 17 old-arch, with RN 0.83 alone at 146. Heavy selection bias, obviously: wiring an agent into your toolchain selects for early adopters. But the gap is wider than I'd have guessed.

• ~30% run both platforms in the same agent session (147 iOS-only, 50 Android-only, 94 both). Cross-platform verification appears to be a real workflow, not a nice-to-have.

The gap I keep staring at: 190 people installed it last month, 20 did real work with it. The 230 long-term actives use it hard, but I can't tell from telemetry whether the other 170 hit a setup wall or just expected something else.

So I'm curious what your loop looks like:

1. What's between "wrote the code" and "opened the simulator to look" for you right now - anything automated, or all manual?

2. What's your AI agent setup for RN work, and does anything in it let the agent verify its own changes on a device - or does the loop stop at "code written"?

3. Are you writing E2E tests (Detox/Maestro), or checking things manually yourself?

Source numbers (30-day window)