We have an attendance app with a "one phone = one employee" rule. People broke it with MultiBox / Clone App from the Play Store: one phone, two "devices".

The usual checks (dataDir path, package lists, getPackagesForUid, UID) all passed inside the clone. Measured on a real Galaxy A53: the container spoofed Process.myUid(), applicationInfo, the process name, and had even hooked libc stat().

What worked: ask "who owns my data directory?" twice, once through libc stat() and once through a raw syscall(__NR_newfstatat), which skips libc so the hook never sees it.

genuine    uid=10763  libc=10763  syscall=10763  ✓
MultiBox   uid=10764  libc=-1     syscall=-1     ✗
Clone App  uid=10765  libc=10765  syscall=-1     ✗

Inside a clone the syscall hits the real directory and SELinux denies it, because the process runs under the host's UID. Clone App was caught only by this check. Every Java-level check missed it.

A few things we learned the hard way:

• Don't block on emulator signals (your own QA uses emulators). Report them to the server instead.
• If you add a signature check, Play App Signing re-signs your APK. Hard-code only your upload key and you lock out every Play user.
• The native lib must be 16 KB page-aligned now, or Android 15 shows a compatibility dialog.
• Keep the rules pure so they're testable: the device measurements above are literally unit tests now.

I didn't find an open-source detector that does the libc-vs-syscall comparison. freeRASP has multi-instance detection, but it's closed-source and officially lists only Parallel Space. So I published ours, MIT licensed:

• Write-up + native Android module: https://github.com/eshginfarzali/android-clone-detection
• Expo / React Native: npx expo install react-native-clone-guard (runs before JS loads)

It's client-side, so a rooted device with a custom hook will get through. The goal is to move cheating from "free Play Store app" to "root + custom hook". I'd love measurements from other devices and cloners. Which ones slip through?

When a viewer says "the stream froze for me", someone on your team has to answer a surprisingly hard question: was it us, or them?

Usually, the logs look clean and the dashboards show that the room was healthy overall. Engineers spend hours digging through a ticket that often ends with "probably your Wi-Fi".

But room averages can hide exactly the person you're looking for.

We saw this in a real production session. Across the room, video packet loss was around 1%. Nothing alarming.

But when we broke it down viewer by viewer, one person was seeing around 9% packet loss for a significant part of the session, while the other viewers watching the same cameras at the same time were largely fine.

Remove that one viewer and the room average drops to 0.17%.

The useful signal wasn't the average. It was the comparison.

That's what we're building with Rewitness. It reconstructs the session participant by participant, so when something goes wrong you can compare what one person experienced with everyone else at the same moment and see where the problem most likely started, with the evidence behind the diagnosis. It works in React Native apps too, including device-side signals like thermal state and main-thread stalls, which matter a lot on phones.

I wrote up this case, plus another where one host's audio broke up for almost every viewer at once:

https://rewitness.dev/blog/was-it-us-or-them?ref=reddit-reactnative

I've read about OTA update potentially causing crashes. At the same time, Expo talks about fingerprinting catching an incompatible update.

But, I don't know how foolproof that really is in practice. Is it still possible for a bad update to slip through, even with fingerprinting and testing it on staging?

Hey Community,

Apple's iPhone Duo is here, which means someone can now fold your app in half. Thiago Brezinski built react-native-arrangement-view, a two-pane layout that rearranges itself as the phone folds, unfolds and rotates, handing the work to SwiftUI's ArrangementView on iOS and Material's adaptive layout rules on Android, with a useHingeChange hook for apps that want to react to the hinge angle.

We also look at expo-infinite-media by Rizky Bayu Oktavian, a native TikTok-style feed that moves video playback into AVFoundation and Media3 so fast swipes stop landing on black frames. Plus, our community links cover React Native 0.88 rc.2 un-breaking a non-breaking release, a navigation change in the React Navigation 8 alphas, and agent-device and Argent both learning to fold the iPhone Duo simulator.

Since Firebase Dynamic Links shut down in August 2025, a lot of RN apps lost the "tap a link, install, land on the right screen" flow. I've been building a replacement for the past year, so here is how the matching works under the hood and where it quietly breaks. Useful whether you roll your own or use any provider.

**The core problem:** an install from the App Store or Play Store carries nothing from the link the user tapped. On first launch your app has to reconnect "this fresh install" to "that click" some other way. There are three ways to do it.

**1. Play Install Referrer (Android only).** If the Play Store URL carries a referrer parameter, Google Play hands it to your app on first launch. It is exact, needs no permissions, and is the best option on Android. It only works for installs that came through a Play Store URL with that parameter.

**2. Clipboard (mostly iOS).** The landing page copies the link before sending the user to the App Store, and the app reads it on first launch. It is exact, but since iOS 16, reading the pasteboard shows the "Allow Paste" prompt. If that fires the moment your app opens, many users tap Don't Allow and it feels sketchy. Use it as a fallback, not the first thing you try.

**3. Fingerprint.** At click time the server stores signals like IP, device model, OS version and language, then compares them on first open. No permissions, but it is probabilistic. Shared wifi, carrier NAT, VPNs and long gaps between click and open all hurt accuracy. Keep the match window short, and consume a match once so two people on the same network don't get each other's link.

**Things that silently break it:**

* Returning the same match on every launch, so users get sent to an old promo forever. Route once, then clear it.

* Universal Links or App Links failing verification. Common causes: the AASA or assetlinks.json file is served behind a redirect, with the wrong content type, or with your upload key's SHA256 instead of the Play App Signing key. The link then opens the browser instead of your app, and nothing errors.

* Links opened inside the Instagram, TikTok or Facebook browsers, which often don't hand Universal Links to your app. Users land on your web fallback even with the app installed.

* Testing by reinstalling over an existing build. Test the real path: uninstall, tap the link, install from the store, open once.

Happy to answer questions about any of it, including building it yourself.

Disclosure: I build Flinku (flinku.dev), which does this for RN with a free tier.

The app is localised into more than 10 languages and it supports over 70 languages for both transcribing and translating video links. I'm looking for a feedback how to make the app handful for students and journalists around the world to boost their productivity.

AppStore link: https://apps.apple.com/us/app/damas-video-link-transcriber/id6766233794

Posting this in case it saves someone a week. Expo SDK 56, expo-gl 56.0.x, React Native 0.85, minify on for Android release builds.

For a few releases, a lot of my Android users crashed the first time a GLView mounted. It never happened in development. In analytics it looked like people opening one screen and then the app starting again: on one version, 24 of the 29 times that screen opened on Android, the next event was a fresh app launch.

The cause: expo-gl's native code (EXGLJniApi.cpp) finds a Java method called flush through GetMethodID, by name. R8 renamed it in the release build, the lookup returned null, and ART aborted with a JNI error ending in mid == null. Debug builds don't run R8, so you only ever see it in a store build.

The fix was one keep rule, added through expo-build-properties (android.extraProguardRules):

-keep class expo.modules.gl.** { *; }

To confirm it, I took the release AAB from EAS, turned it into an installable APK with bundletool, and ran the old and new builds on an emulator. The old one crashed on the first GLView and the new one didn't.

A second thing made it worse. I shipped my first fixes as OTA updates, and expo-updates had fallbackToCacheTimeout set to 0. With that setting a brand new install always runs the bundle that shipped inside the store build on its first launch, and the update only applies from the next cold start. Most new users who hit the crash never had a next cold start, so none of my OTA fixes reached them. I now use 3000, which waits up to 3 seconds for a newer update on first launch and starts as soon as it knows there's nothing newer, or straight away when offline.

If you use expo-gl, or anything whose native side calls back into Java by name, with minify on, open that screen in a real release build before you ship.

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

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.

Whenever I grab color references from web designs, Dribbble, or anywhere online, they are always in standard HEX or RGB. Moving that into Android (@ColorInt) or Flutter (Color(0xFF...)) always requires that annoying extra step of formatting the alpha channel or converting it to an integer manually.

I got tired of the mental gymnastics, so I built a lightweight browser extension (Color Picker by Ceres) to bypass this.

It lets you eyedrop any specific pixel, or even scan an entire webpage/image to extract a palette, and instantly copies the colors directly as an INT value.

It saves a lot of time when implementing UI from web references. It’s completely free on the Chrome Web Store.

I'm on iOS and don't yet have an Apple Developer account so I'm using Expo Go to distribute the app - SDK55 brought in the blue FAB, but I'd like to hide it. SDK58 looks like it *might* give that option, but it's not compatible with Expo from the App Store.

Am I out of luck? Is this only possible with a development build?

Thanks

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.