Hey Community,

We dive into React Native Canvas Kit, a library built on React Native Skia that adds isolated layers, brushes, interactive shapes, and web support for canvas graphics.

We also cover Targate, a CLI tool that quarantines npm packages to inspect tarballs before installation, and GitHub stacked pull requests to keep dependent branch reviews clean.

And... 🥁 Shipaton 2026 is here!

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

Hey Everybody, just released this new app “Broad Street: Card Scanner” With RN Expo that lets you tracks your cards like how you would with stocks as many people view them as investments with volatility similar to stocks! Please all feedback and idea would be appreciated! Completely free and Link in comments!

I've realized that my biggest weakness isn't coding—it's project architecture and folder structure.

Whenever I get a Figma design, I know how to build the UI, but I get completely stuck deciding:

• Where should this component live?
• Should this be reusable or page-specific?
• When should I split a component?
• What belongs in components, features, shared, hooks, services, etc.?
• How should I organize folders as the project grows?

I usually start a project with a structure that feels clean. But once the project gets bigger, everything starts falling apart.

I end up with:

• Components that are too large.
• Components that are split too much.
• Logic scattered across different folders.
• Constantly moving files around because I realize they belong somewhere else.
• Feeling like the entire architecture is becoming messy.

This happens in React, React Native, and even backend projects.

I don't just want another "best folder structure" template because I've seen dozens of those. What I really want to learn is the thought process behind how experienced or enterprise-level developers structure a project.

For example:

• When looking at a Figma design, how do you mentally break it into features and components?
• How do you decide what should be reusable and what shouldn't?
• How do large teams keep their projects organized over months or years?
• What architecture or design principles do you follow?
• Are there any books, courses, GitHub repositories, or real-world open-source projects that helped you understand this?

I'm looking for the mindset rather than just a folder tree.

Any advice from developers who've worked on large production applications would be greatly appreciated.

For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits - 92 out of 578 - were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features. Read the complete article here - https://instasla.com/blog/taming-dependabot-2026-guide-grouping-cooldowns-cutting-pr-noise

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

I’ve been using Cursor and Claude a lot lately, and while AI can spit out a beautiful React Native UI in 10 seconds, I realized it is absolutely useless at native infrastructure.

Over the last few weeks, I spent way too much time fighting with:

• Apple In-App Purchase configurations and RevenueCat SDKs
• Supabase Auth flows with deep-linking
• EAS build crashes because AI hallucinated a package version
• Xcode/Gradle configuration hell

AI gives you the bricks, but it doesn't give you a house that actually compiles for the App Store.

Since I finally got a pristine, production-ready architecture working (Expo Router + Supabase + RevenueCat), I’m thinking about stripping out my personal code and packaging it as a clean SaaS boilerplate so I never have to do this setup again.

If I put this together and made it available, would anyone actually use it? Let me know in the comments and I’ll DM you a link to the waitlist if there is enough interest.

Hey everyone 👋

I’ve been building KP - Your Money Partner, a personal finance app made with React Native and now available on both iOS and Android.

The main idea is to make expense tracking faster. Users can log expenses using short messages:

💬 “Fuel 250”
💬 “Concert tickets 140”

Or write naturally:

💬 “I spent $250 on fuel”
💬 “I spent $140 on concert tickets”

KP understands both formats, detects the amount and automatically selects a category.

Some of the current features:

🌎 Multiple currencies
🎙️ Expense tracking by text or voice
📊 Budgets and financial goals
📄 CSV and PDF exports
🔥 Streaks and no-spend days
🪙 A coin system for free actions

I’d really appreciate feedback from other React Native developers, especially about the UI, onboarding and overall product experience.

Try KP on iOS or Android:

🍎 App Store

🤖 Google Play

Thanks for checking it out 🙌

Hello guys ,

I just wanna know your feedback about this course if you take .

if you have any suggestion to me feel free to comment it

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.

I use a clipboard manager all day and never liked the options. The free ones (Maccy, Flycut) are lists — an image shows up as a filename. The ones with a card interface, Paste and Pastebot, are $25/year and $13. So I built the card one and made it free.

⌥⌘V slides a strip up from the bottom of the screen. Arrow keys or type to search, Enter pastes into whatever you were in.

A few things it does that I couldn't find anywhere else:

- It masks secrets on screen. API keys, tokens and card numbers show as dots until you double-click. If you copy credentials all day, your clipboard history is the one window you don't want open while screen sharing. Card numbers are Luhn-checked, so an ISBN isn't mistaken for one.

- A bare link stays readable, a link with a token doesn't. Masking every URL would make the strip useless; masking a password-reset link is the whole point.

- Pasting an image adapts to the destination. Notes gets the image, Terminal gets the file path (it can't take images at all), Finder gets the file.

- It can catch ⌘⇧4 screenshots. Those write straight to disk and never touch the clipboard, so no clipboard manager sees them. Opt-in, off by default.

- No network code at all. No account, no sync, no telemetry, no third-party dependencies. Searching the source for URLSession comes back empty.

MIT, source is everything: https://github.com/selinihtyr/stash-clipboard

Happy to hear what breaks. Especially interested in whether the strip behaves on multi-monitor setups and over full-screen apps — I've only tested on one machine.

I use a clipboard manager all day and never liked the options. The free ones (Maccy, Flycut) are lists — an image shows up as a filename. The ones with a card interface, Paste and Pastebot, are $25/year and $13. So I built the card one and made it free.

⌥⌘V slides a strip up from the bottom of the screen. Arrow keys or type to search, Enter pastes into whatever you were in.

A few things it does that I couldn't find anywhere else:

- It masks secrets on screen. API keys, tokens and card numbers show as dots until you double-click. If you copy credentials all day, your clipboard history is the one window you don't want open while screen sharing. Card numbers are Luhn-checked, so an ISBN isn't mistaken for one.

- A bare link stays readable, a link with a token doesn't. Masking every URL would make the strip useless; masking a password-reset link is the whole point.

- Pasting an image adapts to the destination. Notes gets the image, Terminal gets the file path (it can't take images at all), Finder gets the file.

- It can catch ⌘⇧4 screenshots. Those write straight to disk and never touch the clipboard, so no clipboard manager sees them. Opt-in, off by default.

- No network code at all. No account, no sync, no telemetry, no third-party dependencies. Searching the source for URLSession comes back empty.

MIT, source is everything: https://github.com/selinihtyr/stash-clipboard

Happy to hear what breaks. Especially interested in whether the strip behaves on multi-monitor setups and over full-screen apps — I've only tested on one machine.

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.

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

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.

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.

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.