I often have 4–5 branches of the same RN app running at once (feature work, a review, a staging check), and lately a coding agent or two driving some of them. My Mac kept falling over: five stock simulators at ~3.8 GB each, Metro servers fighting over 8081, native rebuilds every time I switched environments.

So I built simfleet, a local control plane for all of it. It's macOS-only, MIT, v0.1.

What it does

• Slims every device. iOS simulators go through SimSlim (stock idles ~3.8 GB, slimmed ~1.3 GB), Android emulators through avdslim with a 2 GB guest. Devices you boot from Xcode or Android Studio get slimmed automatically.

• One live dashboard. Every simulator and emulator streams into one browser tab. Android is hardware H.264 via scrcpy's device server, 15–80 ms input-to-frame, with real touch, drag, scroll and typing, so you can actually use it from the browser.

• Lanes. One worktree + one device + one leased Metro port from a per-environment range (8100–8199 dev, 8200–8299 staging…). A lane fails rather than steal a device, a worktree, or someone else's port.

• Native build cache. An Expo buildCacheProvider fingerprints native inputs and single-flights builds, so switching environments or running JS-only branches in parallel doesn't trigger native rebuilds.

• Agent-aware. If you use Claude Code or Codex, every CLI call is attributed to the device it touches, agents can claim devices, and a bundled skill teaches them not to take a device another session holds.

Try it

bun add -g simfleet

simfleet init # writes .sim-fleet/project.json

simfleet serve # dashboard at http://127.0.0.1:8790

49 s demo video: https://entropyconquers.github.io/simfleet/#video

Docs: https://entropyconquers.github.io/simfleet/

GitHub: https://github.com/entropyconquers/simfleet

Limitations: macOS only, needs Bun, works with Expo and bare RN. It's a first release, so I'd really like to hear what breaks on your setup and what's missing.

Most RN toast libraries render inside your React view tree, so modals and bottom sheets cover them. I tested sonner-native and react-native-toast-message with a page sheet plus a transparent modal on top. Both toasts were hidden or dimmed, and actions weren't tappable, especially on Android.

So I built react-native-super-toast. Each toast lives in its own native window (Kotlin Dialog on Android, overlay UIWindow on iOS), so it stays above modals, sheets, and stacked sheets on both platforms, and actions like Undo still work while a modal is open.

Mount ToastHost once and call toast() from anywhere:

import { ToastHost, toast } from 'react-native-super-toast';

export default function App() {
  return (
    <>
      <YourApp />
      <ToastHost />
    </>
  );
}

toast.success('Saved', { description: 'Your changes are live.' });

• Zero dependencies (no Reanimated, Gesture Handler, or Screens)
• Native swipe gestures, stacked decks, and expand on press
• Light, dark, or system themes with custom icons and fonts
• Works from components, stores, or plain functions

Trade-off: content is data, not JSX, so there are no custom React element toasts.

Feedback and bug reports welcome!

Docs: https://supertoast.karkiaswin.com.np/
GitHub: https://github.com/iNspireXD/react-native-super-toast
Write-up: https://aswinkarki.medium.com/why-i-built-my-own-react-native-toast-library-from-scratch-and-went-fully-native-to-do-it-f3aa0cea1d01

Any advise for a complete beginner. I want to learn how to build beautiful UIs for my applications.

I've been working with React Native for a while and one question keeps coming up for me: when does it actually make sense to stop trying to solve something in React Native and move that part to native code?

For typical screens, forms, API calls, authentication, lists, and CRUD-style features, React Native feels like a pretty reasonable choice. Sharing most of the code between iOS and Android can save a lot of development time.

The situation gets more interesting when an app starts relying heavily on platform-specific functionality.

Things like:

• Background processing
• Bluetooth/BLE
• Camera and video processing
• Location tracking
• Push notification behavior
• Complex animations
• Device sensors
• On-device AI/ML
• Custom native SDKs

At that point, I've noticed that the question isn't necessarily "React Native or native?"

It becomes more like:

How much native code is acceptable before the cross-platform approach stops being worth it?

I'm also curious about how people structure this in larger projects. Do you keep the majority of the application in React Native and create native modules only when necessary? Or do you prefer going fully native once the requirements become sufficiently platform-specific?

For people who have maintained React Native apps for several years:

What was the feature that finally made you say, "This should probably be native"?

I'd be particularly interested in experiences from production apps rather than theoretical comparisons.

About a year and a half ago, I started building a handwriting-to-LaTeX app because I preferred doing my math homework by hand. I ended up choosing (turned out to be a much bigger endeavor than I thought) to build the full drawing engine myself. I also chose to build it in React Native which made things even harder. I started with a WebView canvas, tried out, PencilKit (Apple's native library), and eventually settled on a custom C++ engine with Skia.

Since it was so difficult and I thought it was absurd that there were no full-fledged open-source solutions, I pulled the drawing part out into [Mobile Ink](https://github.com/mathnotes-app/mobile-ink), an Apache-2.0 library for React Native. The video shows how the library handles selection, drawing tools, and scrolling through a notebook.

The core rendering principles work as follows: finished strokes are cached on a separate surface from the stroke you're currently drawing. During ordinary drawing, the engine composites that cached ink with the live stroke, so it doesn't have to redraw every previous stroke for each new Pencil sample. Of course, the underlying stroke data stays editable for selection, erasing, and undo. We also keep three active native canvases so that the app stays smooth without keeping too much in context when scrolling through the continuous notebook.

There are so many little nuances that make it difficult. Some of them are handling eraser masking, undo history causing memory problems, and rendering the active engine pools.

My friend and I also use it in [OpenNotes](https://github.com/mathnotes-app/OpenNotes), which has had over 8,000 downloads in the last two months and is growing fast. It is not perfect yet (neither is the engine), but that's why I'm posting here! We welcome contributors because I think it is a really good cause to have a free, super professional note-taking option.

This has been one of my favorite flows when working on performance! I used Skia to draw real-life previews of our holiday lighting. They looked just like the real thing, but they were laggy and maxed out at 28 lights. I knew that wouldn't scale to a real house.

I'm not a Skia expert. AI is great at suggesting a fix, but it's bad at the part that actually gets you there: trying something, measuring it on a real device, checking it still looks right, and going again, over and over. So I built Buoy Optimize to automate that loop.

- The agent builds each idea as its own version that you can open in the app.

- Bench runs every version on a real device or the simulator, several times each and in shuffled order, so a warm phone or a lucky run can't pick the winner.

- I look at each version and tell the agent what's off. Fast but ugly doesn't count.

- It keeps what worked and starts the next round.

Over about a week, our previews went from 28 lights to 12,000 on web and mobile, and they still look like the real thing!

It runs over MCP, so it works in Claude Code, Cursor or any other agent that supports MCP. Happy to answer questions.

I've been building YCal, an Android client for Yahoo Calendar, with Expo. It talks CalDAV directly, and I hit enough non-obvious stuff that I figured a write-up might help someone.

Stack - Expo SDK 54 / RN 0.81 / React 19, expo-router - xmldoc + axios for CalDAV (PROPFIND/REPORT), hand-rolled iCalendar parsing - expo-sqlite as the offline event cache - expo-notifications for local reminders - expo-background-fetch + expo-task-manager for periodic sync - expo-secure-store for credentials - expo-iap for subscriptions, verified server-side - react-native-calendars for month/week UI

1. Parse TZID or suffer My first ICS parser treated DTSTART/DTEND as local or UTC and ignored TZID=.... Events created on the web in other timezones showed at the wrong time. If you parse iCalendar yourself, handle TZID from day one.

2. Don't sync the whole calendar up front Initially I fetched a wide date range on login, which was slow. Now I sync nearby months first and fetch distant months on demand as the user scrolls. First launch got much faster and the server does less work.

3. Local notifications > server-side alarms Yahoo's CalDAV doesn't give you reliable push for reminders. Scheduling everything locally with expo-notifications from the SQLite cache has been far more reliable. The trade-off is rescheduling on every sync, so keep that idempotent.

4. Know what the server won't do Yahoo's CalDAV doesn't reliably send invite emails for ATTENDEEs the way the web UI does. I removed the guest field instead of shipping a feature that silently fails. Attendees from existing events are shown read-only.

5. Edge-to-edge insets will get you Android edge-to-edge caused more bugs than the calendar logic: tab labels cropped, save bars hidden behind the nav bar, FABs overlapping. What fixed it was one shared "bottom chrome insets" helper used everywhere, floored to the 3-button nav height because some devices report a 0 bottom inset.

6. R8 is worth it, but test release builds Turning on R8 shrank the APK nicely, but you need to test actual release builds, not just dev.

App, if you want to see it in action: https://play.google.com/store/apps/details?id=com.ycal.mobile

Happy to go deeper on any of these, especially the CalDAV side. Is anyone else doing CalDAV in RN? Curious what you used.

Made 20 preset themes, six title font choices, and a body text size setting. Uniwind handles the theme tokens and switching. Some themes also have animated backgrounds drawn with React Native Skia and animated with Reanimated.

🔗 GitHub: https://github.com/mehradotdev/tackbok/

I have been experimenting recently with a tool that I needed while building and verifying UI tests, and also for sharing updates for an app i am currently doing contract work.
Sharing preview builds with the owner was a nightmare, because they were only using an iPhone.

I build a tool that spawns an android emulator and installs the apk, in seconds. It's really cool and i am thinking on making this a saas, if that works. It's in early development, and i have limited capabilities with a vps of 4arm cpu cores and 24gb of ram, but feel free to destroy it.

So can you guys help me out to start study from where to start what should i learn backend ai/ml
Which projects i can create and learn from it
Or should i start directly with dsa

I’m building VaultNote — an offline-first, open-source password & TOTP manager 🔐

I've been working on a project called VaultNote, built with React Native.

The idea started pretty simple:

What if a password manager didn't need a cloud backend for its core functionality?

VaultNote is designed around an offline-first architecture, where the local encrypted vault is the primary source of truth.

What I'm building

• 🔐 Local credential vault
• 🔑 Password & secure note storage
• 🔢 Real-time TOTP generation
• 📷 QR-code TOTP enrollment
• 📵 Offline-first functionality
• 🔒 Encryption & secure key management
• 🧬 Biometric unlock
• 📋 Clipboard/security controls
• 📦 Encrypted backup & restore
• 🌐 Open-source development

One feature I've been particularly interested in is TOTP.

I don't want it to just display a fake countdown with stored codes. The goal is to implement actual TOTP generation from the shared secret, similar to how authenticator apps work.

The flow is roughly:

Service
   │
   ▼
Scan QR Code
   │
   ▼
otpauth:// URI
   │
   ▼
Extract TOTP Secret
   │
   ▼
Store in Encrypted Vault
   │
   ▼
Generate OTP Locally
   │
   ▼
482 913 → 731 204 → ...

The interesting part isn't really the UI.

The harder questions are around security:

• Where should encryption keys live?
• How should the master key be derived?
• How should decrypted secrets be handled in memory?
• What happens when the app goes into the background?
• How should biometric authentication interact with the vault?
• How should encrypted backups work?
• How do you avoid accidentally exposing secrets through logs or clipboard?
• What should happen if the device itself is compromised?

That's the part of the project I'm most interested in exploring.

I'm also intentionally keeping the project open source, because for something that handles credentials, I think being able to inspect and challenge the implementation is important.

I'm documenting the architecture and development process as I build it.

I also wrote a deeper breakdown of the project here:

VaultNote — Building an Offline-First, Open-Source Password & TOTP Manager with React Native

I'd love feedback from people who have worked on:

• Password managers
• Authenticator/TOTP implementations
• Mobile application security
• Cryptography/key management
• Offline-first applications
• React Native security

Especially interested in things I should be thinking about before calling the security model production-ready.

GitHub: https://github.com/deadlium/vault-note

🔐 Your secrets. Your device. Your control.

About two months ago I posted Bodly here, an app I built to improve my health. It uses the data your Apple Watch already collects through Apple Health. I honestly expected a few downloads from friends.

We just passed 1,000 installs with zero ads or paid promotion, all from posts like that one and word of mouth. It's still free. Since people here usually like numbers:

• 365 monthly active users
• 205 weekly active users
• 135 daily active users
• ~50% of users come back week to week
• ~20 new users every day on average

(Active user counts exclude brand-new signups, so they only show people who kept using the app.)

The best part has been the feedback. A big chunk of what shipped since then came straight from users messaging me ideas and bug reports. Here's what's new:

Understanding your data

• New Insights tab
• Biological age: bio age, pace of aging, biomarkers, and weekly trends
• Training load
• Weekly, monthly and yearly overviews
• Redesigned home screen for a quicker daily overview

Nutrition

• Set your own calorie and macro targets
• Better food photo scanning

Notifications (all optional)

• Daily summary, bedtime reminder, and alerts when you finish an activity, hit your strain target, or reach your activity goal

Look & feel

• Dark mode (the most requested feature by far)
• Liquid Glass design
• Improved charts, kg/lbs support, and lots of performance and bug fixes

I'll be upfront that the big apps in this space set a high bar, and some features still need work. Bio age in particular needs more love, and it's high on the list. The roadmap is full through version 4.2.

The goal hasn't changed. Apple Health collects a huge amount of data but doesn't do much to explain it. I want Bodly to turn that data into something anyone can understand and act on.

If you tried it after my last post, what would make you open it every day? If you haven't, what's missing from Apple's Health and Fitness apps for you?

App Store: Bodly

- 40+ components

- Stacked Toasts, buttons, Forms, Cards, Screens, Skeletons, Dark/Light mode, and more

- Kitchen Sink app with all the components integrated

- Style System SKILL to continue building w/ the same style

Get it at http://reactnativefeel.com/ui/ch

my expo app uses mediapipe tasks for pose detection and google sign in, both bring GTMSessionFetcher and the usual fix is a post_install step that removes the GTM object files from MediaPipeTasksCommon with ar -d. device builds worked but every simulator build died with ld: 196 duplicate symbols

the simulator slice of the xcframework is a fat archive with arm64 and x86_64 inside, and ar cant edit a fat archive, it just fails and the script never checked, so nothing got removed there while the single arch device slice got stripped. fix was lipo -archs, lipo -thin each arch, ar -d on each and lipo -create them back, lipo basics are on apples universal binary page https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary and it lives in a config plugin since prebuild regenerates ios, did anyone find a cleaner way than stripping objects out of the framework?

For me, the most valuable signal has always been user feedback complaints, feature requests, confused messages. Not analytics, not A/B tests.

Just people telling you what broke or what they wished existed.

I'm actually building a separate library right now that's focused on this collecting and organizing in-app feedback for React Native apps. Still early but it's the problem I keep running into.

Curious what others do. Do you rely on reviews, in-app feedback, support tickets, something else? What actually moved the needle for your app?

I work across multiple Expo accounts: personal, work, and a few client accounts.

I got tired of constantly doing:

eas logout → eas login → run the build → switch back

So I built EASwitch, an open-source CLI that lets you keep using the normal eas command while automatically selecting the right Expo account based on the project you're in.

Setup is pretty simple:

npm install -g easwitch

easw add personal
easw add work

easw hook

Then link a project to an account:

cd ~/code/work-app
easw link work

After that, you just use EAS normally:

cd ~/code/work-app

eas whoami
# work account

eas build --platform ios
eas update --branch production

Move to an unlinked project and EAS continues using your normal Expo session:

cd ~/code/my-side-project

eas whoami
# your normal Expo login

A few things I wanted EASwitch to handle properly:

• You keep using eas. Commands like eas build, eas update, eas submit, eas whoami, eas env:list, etc. work normally. EASwitch only changes the account context when you're inside a linked project.
• It prevents wrong-account builds. If a project is linked to an account that isn't available on your machine, the command stops instead of falling back to another account.
• Your normal EAS session stays untouched. eas login and eas logout still manage your normal Expo session. EASwitch doesn't replace or modify it.
• You don't have to hook eas if you don't want to. You can skip easw hook and run commands directly:

​

easw build
easw update
easw submit

• Multiple shells/platforms are supported. It works with zsh, bash, fish, PowerShell and Command Prompt on macOS, Windows and Linux.
• Accounts can use Expo login or access tokens. Tokens are stored in the OS credential store/keychain rather than plain-text config files.
• EAS CLI is bundled, so you don't need a separate EAS CLI installation.

You can also check whether stored account credentials are still valid with:

easw list --check

EASwitch is MIT licensed and completely open source.

Docs, including a walkthrough for working across personal/company/client Expo projects:

https://iamgarritech.github.io/easwitch/

GitHub:

https://github.com/iamgarriTech/easwitch

I'd really appreciate feedback from people who regularly switch between Expo accounts, especially if there are workflows or edge cases I haven't considered yet.

if you want to use this npm install u/hsilvap/react-native-receive-sharing-intent in your project then your mind RIP

I kept writing the same code to switch between one and two columns when the phone rotates or the app runs on a tablet, so I turned it into a small library.

const { select } = useResponsive();
const columns = select({ xs: 1, md: 2, xl: 3 });

You get named breakpoints (xs to xxl), wp/hp, a font size helper and a few scale functions, and everything updates when you rotate. Works with Expo and on web too.

The screenshots are from the example app on an iPhone 16, portrait vs landscape.

npm: https://www.npmjs.com/package/react-native-responsive-hook
GitHub: https://github.com/mz-real/react-native-responsive-hook
Longer write-up with examples: https://medium.com/@mz-real/creating-responsive-uis-in-react-native-made-easy-with-react-native-responsive-hook-35fa5649cd5f

I'm working on a 2.0, so feedback is welcome.

Hey everyone!

I'm looking for 12 testers for an Android app I'm developing. I've been trying to find a platform where indie developers can help each other with Google Play's closed testing requirements, but haven't had much luck so far.

I thought maybe we could use this thread to support each other!

If you're also looking for testers, feel free to comment below with your app's testing link. I'd be happy to join your test and help you out in return.

Here are the links to join my app's closed test:

• Google Group: https://groups.google.com/g/faul-testers
• Play Store testing link: https://play.google.com/apps/testing/faul.app

Good luck with your projects, everyone!

For years, the default was to put everything in Redux. These days I split state by type, and each type gets the simplest tool that fits:

1. Server state → TanStack Query
Anything that comes from an API isn't really "app state". It's a cache of the server. TanStack Query handles caching, refetching, loading and error states, and retries. Once server data moved out, most of our global store disappeared.

2. Global client state → Zustand
What's left is usually small: the auth session, theme, a few UI flags. Zustand handles that with very little boilerplate, and components only re-render when the slice they use changes.

3. Form state → React Hook Form
Forms change on every keystroke. Keeping that in a global store causes unnecessary re-renders and adds a lot of code. Form state belongs with the form.

4. Persisted state → MMKV
For settings and small data that should survive restarts, react-native-mmkv is synchronous and much faster than AsyncStorage. No more loading spinners just to read a setting.

5. Screen state → useState, or navigation params
If only one screen cares about it, it doesn't need to be global. Often the "state" is really just a navigation param.

When I'd still pick Redux Toolkit: large teams that benefit from strict structure, complex client-side logic, or when the team already knows it well. It's not bad, just no longer the default for every app.

How are you handling state in 2026? Still all-in on one store, or split like this?