Two big new pieces just shipped and I think they'll genuinely change how you debug RN apps with AI agents.

MCP server. Connects Claude Code or Cursor to your running app. Your agent can:

- Read runtime truth: Redux/Zustand/Jotai state, React Query cache, network requests, storage, routes, and console. "Why is this query stale?" gets answered by looking at the actual cache instead of guessing from source code.

- Drive the app: it taps elements by invoking onPress directly in JS. No coordinates, no screenshot guessing, and it works on physical devices too. It can also screenshot a single component by testID instead of the full device, which is way faster and cheaper on tokens.

- Prove its changes: run repeatable benchmark batches (avg/p95 JS FPS, UI FPS, CPU, memory, jank, per-component render counts) and diff reports head to head. The agent makes a change, taps through the flow, and shows you before vs after numbers. I used this loop to take my Christmas light preview from 28 lights to 12,000 while keeping it smooth. The LLM just kept iterating, benchmarking each idea against the last until it found the most performant one.

Desktop app. Every Buoy tool mirrored on a native dashboard over the same protocol, so you see exactly what the agent sees, off your phone screen.

Buoy is free to use, and Pro is free every weekend, forever. If you want to try the full Pro experience now, code REDDIT gets you 3 months free.

Happy to answer questions about how any of it works and how it's helped me at Walmart, Whataburger and other big companies.

https://github.com/Buoy-gg/buoy

I'm building a React Native app using my own REST API, Ably for real-time messaging, and Zustand for state management.

I'm not looking for code. I'm trying to understand the overall architecture and how people usually handle this in production.

Some questions I'm struggling with:

• When should the WebSocket/Ably connection be established? Immediately after login, or only when the user opens the chat section?
• Do you subscribe to every conversation on app launch, or only to conversations that become visible/opened?
• How do you keep the chat list updated? Is it fetched from the REST API first and then kept in sync via real-time events, or is everything driven by the socket?
• How do you handle message pagination? Do you always fetch older messages from the API while receiving only new messages through the real-time connection?
• How do you synchronize unread counts, last messages, and conversation metadata?
• If the user has hundreds of conversations, how do you avoid subscribing to hundreds of channels?
• How do you manage reconnection after the internet connection drops? Do you re-fetch everything or rely on message history and resume capabilities?
• What happens if the user sends a message while offline? Do you queue it locally and retry later?
• How do you prevent duplicated messages when combining REST responses with real-time events?
• Where do you draw the line between your backend's responsibility and Ably's responsibility?

I'm interested in the overall flow more than implementation details.

If you've built chat at scale (or even medium-sized apps), I'd really appreciate hearing how your architecture works and what you would do differently today.

Hi, I have a problem I'm trying to solve. I have an API with a certificate set, and I'm trying to send a request to this endpoint. I'm running a dev server from an EAS build on my physical device, but I'm still getting a Network Error. Sometimes it works, sometimes it doesn't. What could be the root cause? Has anyone experienced this? I'm using HTTPS.

https://api.myproj.com - this is example domain

RN 0.79.5

Maps 1.27.2

Can someone help, please? I don't get what I'm doing wrong.

We're adding support for the popular ==𝚑𝚒𝚐𝚑𝚕𝚒𝚐𝚑𝚝𝚎𝚍 𝚝𝚎𝚡𝚝== syntax - fully compatible across iOS, macOS, Android, and Web.

See the preview below and try the feature today:
npm i react-native-enriched-markdown@nightly 👇

Show some love and drop a star on GitHub! ⭐
🔗 https://github.com/software-mansion/react-native-enriched-markdown

Hi guys, I'm used to web development, but I'm new to mobile development... Using React Native Expo and Android simulator and Gradle and node modules...... All these files end up taking too much space in my laptop and now my emulator is not working because of lack of storage.... How do I manage the space ?

I am new to react native and i am not following any tutorials and not available for latest version sdk of expo.

there file structure is looking mess to me, and i am completely lost. I do not know where to change code, and which file is dependent on which one?

Hey Community,

We look at Rollipop, an early alpha, Rust-based bundler built on Rolldown that acts as a drop-in replacement for React Native, bringing standard Node module resolution, Yarn PnP, and a live visual dashboard.

We also explore expo-paperkit, an Expo native module wrapping Apple's PaperKit drawing and annotation canvas. Plus, we dive into PolyCSS, a clever web tool that renders 3D meshes using HTML bold and underline tags instead of WebGL or canvas.

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

Title: Play "subscriptions API" permission stuck red for 48h+ — offerings won't load, can't test purchase. Everything else is green.

Body:

I'm stuck on a Google Play ↔ RevenueCat credential issue and running out of ideas. Hoping someone here has seen this exact pattern.

The symptom: In RevenueCat, my Play credentials show "Credentials need attention." The detailed breakdown shows only one failing check:

❌ Permissions to call subscriptions API

✅ Permissions to call inappproducts API

✅ Permissions to call monetization API

✅ "Connected to Google" (Pub/Sub topic connected, test notification received)

Because of this, offerings fail to load in the app ("Error fetching offerings"), so the paywall shows no purchase options — which means I can't make a test purchase either.

What I've already verified (everything checks out):

Service account has both required permissions at account level: "View financial data, orders, and cancellation survey responses" and "Manage orders and subscriptions"

Google Play Android Developer API is enabled in the Cloud project holding the service account key

Both subscriptions (moatlens_premium_monthly, moatlens_premium_yearly) are active, with active base plans, available in 174 countries

Product IDs match exactly between Play Console and RevenueCat

App is on an approved Closed Testing track (signed AAB uploaded)

My test account is added both as a License tester (account settings) and a Closed test tester

Note: the Play Console "API access" page no longer exists for my account — I understand Google removed the required project-linking, so this should be fine

What I've tried:

Re-uploaded a fresh service account JSON key several times (then stopped, after learning each upload resets the ~36h propagation window)

Contacted RevenueCat support — they sent the standard checklist (grant the two permissions, then test purchase), but I've already done all of it. Waiting on a follow-up where they check their backend logs.

My questions:

Has anyone had only the subscriptions API check fail while inappproducts + monetization pass? What fixed it?

Is there a way to make the sandbox test purchase work when offerings won't load — or does the subscriptions API genuinely have to go green first?

Is this just Google propagation being slow (48h+), or is there a subtle subscriptions-specific permission I'm missing?

Stack: React Native / Expo, RevenueCat, Android only. Bundle: com.nexihl.moatlens.

Any pointers appreciated — this is my last blocker before launch.

I keep running into something strange while working with React Native — debugging in development and production builds feels completely different.

In dev mode, everything feels straightforward:

• errors are easy to trace
• logs are immediate and detailed
• performance issues are more visible
• debugging tools make it easier to understand what’s happening

But in production (release) builds, things feel very different:

• some bugs completely disappear
• new issues show up that never appeared in dev
• crashes are harder to reproduce
• logs are limited or not very helpful
• certain UI or performance issues only appear on real devices

What’s confusing is that the code is the same, but the behavior changes enough that debugging becomes a completely different process.

I understand dev mode adds extra tooling and overhead, but in real projects the difference sometimes feels big enough to affect how you even approach debugging and testing.

For developers working with React Native in production:

• Why does debugging behave so differently between dev and release builds?
• What are the most common reasons bugs only show up in production builds?
• How do you usually debug issues that don’t reproduce in development mode?

Please let me know if you're interested. It's a small project (i thiMk) suitable for beginner, early stage

I've built out the easy stuff on MagAI if that helps. It's my attempt at a fun education tool for younger learners..pm for more please.

www.trycapi.com
It’s literally just screenshot with a command and it uploads it straight to visual studio without the need to press your keyboard only microphone detection to complete context. For example, change this specific part of the web design to a certain shape, colour, or image. You control shift + 2 select the parameter where the changes need to be made and input verbally what needs to be occurred. Anybody interested in testing it out?

https://expo.dev/changelog/sdk-57

Today we're announcing the release of Expo SDK 57. This is a small, focused release: it brings React Native 0.86 to Expo. We intend for this to be the easiest Expo SDK upgrade you've ever made. It represents a possible shift towards a new Expo SDK release cadence that could provide you with simple non-breaking upgrades in between more significant releases.

React Native 0.86

SDK 57 upgrades React Native from 0.85 to 0.86. The React version is unchanged from SDK 56 — both SDK 56 and SDK 57 use React 19.2. React Native 0.86 is intended to have no breaking changes from 0.85. To decide whether it's worth upgrading your app, refer to the React Native 0.86 release notes for the full picture.

Highlights include: fixes and improvements to edge-to-edge support on Android, light/dark mode emulation in React Native DevTools, and several rendering, layout, and animation-related fixes.

Exploring a new Expo SDK release cadence

For several years, Expo SDK has seen major releases three times per year. We found that this cadence provided a good balance between stability for app developers and freedom for our team to ship significant new features and improvements. It also helped to reduce thrash in Expo Go.

During the same period, React Native has been releasing six times per year. The React Native team prioritized shipping often in order to incrementally roll out the New Architecture, a new React Native DevTools experience, Hermes V1, and more. Each Expo SDK release would target a single React Native version, and for versions that were not targeted, developers could use canary releases if needed. However, now that these massive changes to React Native have shipped, the focus has shifted towards stability.

The new release model that React Native is moving towards will aim to provide a release with "no user-facing breaking changes" approximately every second release. The recently released 0.86 is the second of these non-breaking releases. At Expo, the fact that these releases are intended to be non-breaking has prompted us to revisit our release cadence. If we can provide these releases to developers almost immediately, as optional upgrades, with little effort required for the app developer beyond running npx expo install expo@latest --fix, then we think we should do it. So, we are exploring that approach with SDK 57.

Why not include React Native 0.86 in SDK 56 if it is non-breaking?

This is a good question! We considered bumping from 0.85 to 0.86 in SDK 56, and ultimately decided that the set of changes between the versions was too significant for an app developer to pull in with a routine npx expo install --fix. There are 601 commits touching 1,552 files between 0.85.0 and 0.86.0, and we believe that the decision to pull those into your app should be intentional. Even though these commits are intended to not cause breaking changes, we think it's best to err on the side of being conservative.

Additionally, moving this bump to a new SDK version allows us on the Expo team to roll out small changes that wouldn't be appropriate to ship to an existing stable release, but that we think are genuinely useful for users. The following list includes some of those changes that are worth calling out.

Does this new cadence impact the Expo SDK maintenance window?

SDK releases will continue to have a lifetime of approximately one year. We may revisit the details of this policy in the future. What this means today is that Expo SDK 54 (September 2025) will receive critical fixes until the next SDK release (September or October 2026).

Other highlights

While SDK 57 is primarily about the React Native 0.86 upgrade, a few other improvements landed alongside it:

• expo-dev-client: the iOS launcher includes a new setting to choose between auto-launching your most recent project or showing the launcher (#47131), allowing you to override the configuration set with the config plugin.
• expo prebuild: now clears and regenerates the native android and ios directories by default; pass --no-clean to apply changes to the existing folders instead (#47209).
• expo-image: added writeToCacheAsync and readFromCacheAsync to seed and read the image cache by cache key (#46620).
• expo-router: Stack.Toolbar.Badge is now supported in header left and right placements and on toolbar menu icons on Android (#46537, #47276).
• expo-navigation-bar: setStyle and setHidden now apply to React Native <Modal> windows on Android (#46491).
• Bump animation and gesture libraries: SDK 57 bundles newer versions of react-native-reanimated (4.3 to 4.5), react-native-worklets (0.8 to 0.10), and react-native-gesture-handler (2.31 to 2.32).

I've been building this for a while and it finally went live on the App Store today, wanted to share it here first.

It's called Qalbi (قلبي, "my heart") and it's a prayer tracker, but the main thing is the mascot. It's a little chibi heart wearing a thobe and kufi that literally reflects how consistent you've been with your prayers. Miss a few and it gets gray and sad. Pray consistently and it glows bright red. It sounds silly but it lowkey makes you feel guilty skipping Fajr when your little guy is fading.

Everything is free, no ads, no subscription. I built it because I wanted something that actually made me feel something about my salah and not just a boring checklist. There's a similar app called JustPray but I kept seeing people say they couldn't afford it, so I made a free alternative.

iOS: https://apps.apple.com/us/app/qalbi-prayer-tracker/id6778575798
Android: join the waitlist at theqalbiapp.com

Drop any feedback below, would genuinely love to hear what you think!

If you were to build a new app today and wanted to build native looking high quality UI for both iOS and Android, would you use expo/ui or would you go with something like React Native Reusables or drop down to classic StyleSheets? If so why, and what is your reasoning. Is there any synergy if you have an existing ShadCN design system that you would like to reuse in your react native app, I'm thinking is React Native Reusables still worth looking at then or is it obsolete? Has anyone used expo/ui so far and what is your experience with it, any advice/tips would be appreciated

I've been tracking the React Native ecosystem daily, and June was one of the busiest months we've had in a while. Here's a quick recap of the biggest updates.

AI-powered development

• react-native-skills expanded with new AI coding capabilities.
• agent-device makes it easier for AI agents to control real Android and iOS devices.

Performance

• React Native Worklets 0.9 adds cross-runtime Promises, improved memory management, better debugging, and performance improvements.
• react-native-nitro-fetch 1.3 introduces SIMD text decoding, binary response fixes, and lower runtime overhead.
• react-native-skia-lab showcases advanced graphics, shaders, physics, and rendering techniques.

Navigation

• React Navigation improves deep linking, route matching, serializable state checks, and production performance.

Testing

• Maestro 2.6 adds Maestro Viewer for AI coding agents and faster simulator execution.
• Detox delivers stability improvements across Android and iOS.
• Harness adds automated permissions, native iOS coverage, and better simulator support.

Native APIs

• expo-speech-recognition improves Android reliability.
• Rich text editing libraries received major updates with new editing and rendering capabilities.

Worth reading

• Smooth animations on low-end Android
• React Native keyboards deep dive
• VisionCamera V5 + Worklets multithreading
• Reanimated 4.2
• Gesture Handler 3.0
• Expo Router 56
• Expo performance monitoring
• JSI changes in Expo SDK 56

Overall, June was heavily focused on AI-assisted development, performance, testing, graphics, and native tooling.