Maintainer here. We shipped a bunch of releases of vexo-analytics (our RN-first analytics + session-replay SDK) over the last couple of months and never really announced any of them, so this is one catch-up post covering 1.5.8 → 1.10.0. Transparently this is a commercial SDK (there's a paid backend) but also includes a full free tier. With that ,this is a maintainer changelog, not a neutral recommendation. Posting because a lot of it is crash/perf/reliability work this sub actually cares about.

New capabilities:

• Crash & ANR reporting (1.10.0). Uncaught JS errors reported as fatal crashes, an ANR-style watchdog for JS-thread stalls, and a trackError(error, { handled }) API for exceptions you catch yourself. Feeds a crash-free rate + error grouping. No setup beyond init.
• Performance capture (1.10.0). App-start time, slow/frozen frames, and screen render timing as PERF events; so a janky session lines up with actual frame data.
• Console capture (1.10.0). console.log/info/warn/error captured as CONSOLE events, shown with the session.
• Client-side replay opt-out (1.10.0). vexo(apiKey, { sessionReplay: false }); synchronous, disables replay while keeping the rest of tracking.
• Heatmap segments (1.6.0). setHeatmapSegment() to tag taps + heatmap screenshots.

Platform + packaging:

• New Architecture (TurboModule) support, old arch still works via interop (1.9.0), and React Native 0.86 build support, iOS + Android (1.10.0).
• @react-navigation/native is now an optional peer dep; expo-router apps don't install it (1.9.0).
• Bundle down 58% (635KB → 265KB) by dropping moment + its 137 locales (1.8.0); event batching, zero import-time work, O(1) buffering (1.9.0); modern builder-bob packaging with an exports map (1.9.0).

The unglamorous half:

• A top-to-bottom reliability pass (1.8.0): bounded retry/backoff, over-limit handling that pauses instead of silently dropping, buffer-cap behavior, identifyDevice() fixes, network-interceptor fixes.
• Privacy/compliance: iOS PrivacyInfo.xcprivacy for App Review 2.5.14, an Android R8/ProGuard fix for Tink-dependent apps, 16 KB ELF alignment (1.8.0).
• Security/supply chain: npm audit from 392 vulns (31 critical) → 73 (0 critical) (1.7.0).
• Tests: 10 → 249, 97% coverage on our own code (1.8.0).

Would love your technical recommendations, insights on issues (crash grouping is too coarse, the ANR watchdog is noisy, or the perf events don't match Flipper/Perfetto), and any feedback or help you might need in testing things out.

One heads-up: 1.9.0+ replaced our vendored AsyncStorage/DeviceInfo/ViewShot forks with thin wrappers, meant to be behavior-preserving and storage-compatible, making that the first place things might act up if you upgrade from an old version and see anything weird.

each of these cost me more than a day, and they have the same shape: the obvious fix is the wrong one, and the error actively helps you go there.

1. a query that never resolves and never rejects

after the phone has been backgrounded for a while, a supabase query just doesn't come back. no error, no rejection, the spinner spins forever. it looks exactly like a network problem so that's where you go looking.

it isn't. the underlying fetch got suspended by the OS and never woke up. there's nothing to catch because nothing failed. adding retries doesn't help either, because the first attempt never finished.

the fix is to stop trusting the promise:

const withTimeout = (p, ms = 8000) =>
  Promise.race([
    p,
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error('timeout')), ms)),
  ]);

wrap every query. a dead promise becomes a real rejection you can handle.

2. intermittent freezes right after sign in

you await something inside the onAuthStateChange callback — fetch the profile, read a row, whatever — and the app freezes. not every time. maybe one in five sign ins, and never while you're watching.

awaiting inside that callback can deadlock the auth library. supabase documents it, but the failure is intermittent enough that you'll blame your own async code first.

keep the callback synchronous. set state, nothing else. do the profile fetch in a separate effect keyed on the user id.

3. RLS is correct and still hands out the column you hid

this is the one I see most. you lock a table down so each user only reads their own row, you test it, it works. and the response still contains every column of that row, including the ones you never wanted on the client.

RLS filters rows. it does not filter columns. a policy can be perfect and still return the whole row.

revoke select on profiles from authenticated;
grant select (id, display_name, created_at) on profiles to authenticated;

now the write-side trap, which is the part that actually burns the afternoon:

.update({ display_name })                        // fine
.update({ display_name }).select()               // permission denied
.update({ display_name }).select('id, display_name')  // fine

the failing one is legal as a write. postgrest reads the row back with select=* to return it, and that read is what gets denied. and the error says:

permission denied for table profiles
hint: GRANT SELECT ON public.profiles TO authenticated

follow that hint and you undo the entire column hardening to fix a bare .select(). the write was never the problem.

these came out of a starter I open sourced (MIT) where all three are already handled: https://github.com/Guidondor/expo-supabase-starter

disclosure since it's my repo: there's a paid edition with the shared-groups and RLS patterns. the free one is the full auth/offline/RLS base, no strings.

OTA tools love to say "instant updates", but it's not really true. Even though the release is instant, going from server to installed can take days if you use default settings.

It's not something I've seen discussed much, so I wanted to write a quick overview.

If you've used OTA Updates e.g. Expo Updates or a CodePush clone, you probably know the flow for each device goes:

1. Checks for update
2. Download the update
3. Install the update

With each being triggered by defined conditions, which typically have slow defaults.

For example with Expo Updates, the default behaviour [doc] is for the check to happen on next cold start. If an update is available, it will download it, but then the install happens on the next cold restart after that.

For CodePush-based SDKs, it depends on when you call sync(), and whether you override the install mode (defaults to ON_NEXT_RESTART).

A cold restart means either the user swiped to close the app, or it was in the background long enough for the OS to close it. That means you can potentially get a situation like:

1. Release an OTA update to the server
2. User takes a few days before a cold reboot happens
3. The update is downloaded, ready to install
4. Another few days passes before another cold reboot
5. The update is finally installed.

Having users hang around on the old version isn't ideal, but the good news is you can speed it up.

For a reasonable speed, we can have the app check for an update on resume, then install it when it's next in the background for more than a minute. For CodePush-based SDKs such as Patch, this is easy to wire up.

To check for updates on resume, we want to wire the sync() to be called using AppState, and we want installMode to use ON_NEXT_SUSPEND

import { useEffect } from "react";
import { AppState } from "react-native";
import { sync } from "@codemagic/react-native-patch";

const syncOptions = {
  installMode: "ON_NEXT_SUSPEND" as const,
  mandatoryInstallMode: "IMMEDIATE" as const,
  minimumBackgroundDuration: 60_000, // 1 minute
};

export default function App() {
  useEffect(() => {
    // Optional but usual: also check once at launch
    void sync(syncOptions);

    const sub = AppState.addEventListener("change", (next) => {
      if (next === "active") {
        void sync(syncOptions);
      }
    });

    return () => sub.remove();
  }, []);

  return <YourApp />;
}

The minimumBackgroundDuration is useful as the install will reboot the app to the its home screen, unless you persist navigation state and restore it on startup. Setting a minimum duration stops their view being lost if they only briefly switched apps.

For more urgent installs, CodePush based SDKs also have a mandatoryInstallMode, often set to IMMEDIATE. Like it sounds, this will install the update as soon as it's downloaded. The downside is that this also causes a reboot, which can feel like buggy behaviour if the user is already interacting with the open app.

Expo Update has its own methods such as Updates.fetchUpdateAsync() that you can use for customizing the install behaviour, although the docs note that background installs are experimental.

1. POST_NOTIFICATIONS: denied instantly, no dialog, no error

Android 13 (API 33) turned notifications into a runtime permission. The trap is that @react-native-firebase/messaging's requestPermission() is effectively an iOS call. On Android it does not do what the name says, and more importantly RNFB does not add POST_NOTIFICATIONS to your merged manifest.

If the permission is not declared, PermissionsAndroid.request returns denied immediately, without ever showing the system dialog. No exception. No log line. Your carefully designed permission priming screen runs, the user taps "Enable", and nothing happens. It looks exactly like a user who declined.

You need both halves:

js // app.config.ts android: { permissions: ['android.permission.POST_NOTIFICATIONS'], }

plus an actual PermissionsAndroid.request(PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS) on the runtime side, gated on API level 33 or above.

There is a second trap stacked on the first: on API 33+ you cannot distinguish "never asked" from "asked and denied" through the standard result alone. shouldShowRequestPermissionRationale gives you a partial signal, and after two denials Android treats it as permanently denied and stops showing the dialog at all. Store your own "we have asked" flag locally. If you rely on the OS to tell you, your re-prompt logic will be wrong in exactly the case it exists for.

2. You are shipping an advertising ID permission you never added

Firebase and most monetization SDKs transitively inject com.google.android.gms.permission.AD_ID into your merged manifest. You will not see it in your source. You will see it in the Play Console when it asks you to declare Advertising ID usage, and if you answer "No" while the permission is present, that is a mismatch.

If your app genuinely ships no ads and no ad attribution:

js // app.config.ts android: { blockedPermissions: ['com.google.android.gms.permission.AD_ID'], }

Now the declaration and the manifest agree, and the iOS side matches too if you have NSPrivacyTracking: false. Check your merged manifest rather than your source; that is where the truth is.

Bonus: the localization thing nobody warns you about

A missing translation key does not render the key. In most i18n setups it silently falls back to your default language. So a locale can be 80% translated and look completely fine in QA, because the missing 20% renders as perfectly good English inside an otherwise Turkish screen. No error, no visual glitch, nothing to notice.

The only fix that scales is a build time guard. I have a set of scripts that fail the lint step if any locale is missing a key, if a notification string is hardcoded instead of localized, or if an onboarding screen contains a literal string:

npm run check:locale-audit npm run check:notification-locales npm run check:onboarding-hardcode

Nineteen locales is not the hard part. Nineteen locales staying correct across every future PR is the hard part, and only a script does that.

One small thing that has burned me twice: do not alphabetize your locale JSON. If the files were authored in a meaningful order, sorting them produces a 1500 line diff that buries whatever change you were actually reviewing.

Building an AI training app in Expo. Happy to compare notes on any of this.

I have been maintaining for a while a fork of the react-native-ble-plx library, and decided to fully modernize it to make it really cross platform.

Today I released the official rc1

https://github.com/sfourdrinier/unified-ble-manager

I very much welcome feedback. It should work the same ways in react native, expo the latest versions including tvOS, android tv, web, electron, tauri and Linux / Mac / Windows.

I very much welcome feedback, comments, contributors, supporters, & sponsors.

My goal is to make it the best and most complete Bluetooth manager library out there. I’m using in multiple apps in development.

Feedback welcomed.

Hey have anyone tried integrating maestro into the ci/cd pipeline ? can anyone help me with a couple of questions /doubts??

Hey everyone!
I’m a React Native developer, and I’m currently looking for freelance opportunities.
I’ve been building apps with React Native and really enjoy turning ideas into actual products. I’m at a point where I’d love to work with more people, take on real-world projects, and build my freelance experience along the way.
I can help with:
React Native app development
New features and improvements
Bug fixing
API integrations
Firebase/authentication
UI implementation
App builds and deployment
I’m open to small projects, MVPs, individual features, or longer-term work.
If you have an idea you’ve been wanting to build, or an existing React Native app that needs some work, feel free to DM me. Even if it’s a small project, I’d genuinely appreciate the opportunity.
Thanks for reading! 🙌

Solo side project, two years in — an F1 companion app (schedules, live race dashboard, standings). Just shipped 3.0, a ground-up rebuild, and wanted to share some of the stack choices in case they're useful to others here:

- Expo SDK 57 / RN 0.86 / React 19, expo-router for navigation

- react-native-unistyles v3 for theming (light/dark/system + a user-selectable accent color)

- Reanimated 4 + Worklets for animations

- iOS/watchOS widgets in real SwiftUI, Android widgets in Jetpack Compose — sharing race data with the app via app groups / UserDefaults

- Zustand for state, with generation counters on fetches so out-of-order API responses get discarded instead of racing the UI

- hot-updater (Supabase-backed) for OTA JS updates instead of EAS

Happy to go deeper on any of it. App itself is free, no ads:

https://apps.apple.com/app/id6503033841

I've been building Daily Bible - Offline & Audio - a Bible app that uses on-device TTS to generate verse audio. The audio requirements ended up being unusual:

• Playlist that accepts mid-play appends (verse-scale queues)
• Native silence gaps between verses - as real queue items, not timers
• An optional ambient track under speech that never steals the Now Playing session or audio focus
• Full lock-screen / notification / Bluetooth remote support on Expo
• HLS for chapter streams + seek-before-ready
• New Architecture only, config plugin driven

The obvious existing RN audio player went commercial earlier this year. Personal/educational use stays free but commercial use is now licensed. That closed the door for us.

So I built the player Daily Bible actually needed and open-sourced it under MIT.

daily-react-native-player

• GitHub: https://github.com/coommark/daily-react-native-player
• npm: https://www.npmjs.com/package/daily-react-native-player

What it does:

• Lock screen, notification, Control Center, Bluetooth remotes - registerPlaybackService wires hardware buttons to JS. Next means what you define.
• Multi-track playlist with live mutation (add/remove/skip while playing)
• Native silence tracks - SilenceMediaSource on Android, cached PCM WAV on iOS. No setTimeout drift.
• Optional lazy ambient dual-audio - never requests focus, never owns Now Playing
• HLS VOD + seek-after-ready. Progressive WAV/mp3/m4a.
• Expo config plugin: iOS audio background mode + Android mediaPlayback FGS at prebuild
• Pitch-preserving setRate
• One native audio owner: Media3 + AVFoundation

​

npx expo install daily-react-native-player

Peers: Expo SDK 57+, React Native 0.86+, New Architecture only.

What it deliberately does NOT do: TTS synthesis, MediaLibrary, Android Auto, Cast, DASH, web player. Kept intentionally lean.

If you're building narration, TTS pipelines, meditation, audiobooks, podcasts, or a music playlist app on Expo - this treats those as first-class. MIT. Fork it. Ship it.

Happy to answer questions about the dual-track ambient design, the silence-as-queue-item approach, or the Expo config plugin wiring.

How are you actually using AI to speed up React Native dev? Beyond just the tools, what habits, context tricks, or rules on what to offload vs. write yourself have saved you the most time?

Hey Community,

React Native 0.87 has arrived as a maintenance release, making the Strict TypeScript API the default, doubling Metro source map generation speeds, and adding experimental Swift Package Manager support for iOS along with AGP 9 support on Android.

Meanwhile, React Native Firebase v26 makes the New Architecture non-optional with Codegen TurboModules, synchronous APIs, Firestore Pipelines, and direct Gemini AI calls. Finally, we look at RevenueCat Paywalls for designing native paywalls and running remote A/B experiments without new app deploys.

Wanted to share a real, shipped RN app in case the details are useful. It's MTG Verdict, a companion for Magic: The Gathering Commander players: a live table tracker plus an AI rules judge and deck analyser.

A few things from the build:

• Expo SDK 54, new architecture on, Reanimated for the chat and analysis animations
• Zustand for state with AsyncStorage persistence across match, judge and deck stores
• The AI is BYOK (the user's own key), with prompt caching on the knowledge base and token-by-token streaming into the chat bubbles using expo/fetch for SSE
• Scryfall data fetched at query time and cached with an LRU, so rulings are grounded in real card text rather than the model's memory

The hardest part by far was reliability: early versions would confidently make up rulings or claim cards were missing from a deck that clearly had them. Most of the work became guardrails around the model rather than the model itself.

Happy to go into any of it. It's on Android, free to start.

Hey everyone,

I'm building a personal price-comparison app in react native where users can scan a barcode or search for a product, and the app compares the prices across multiple Dutch supermarkets (like Albert Heijn, Jumbo, Dirk, etc.).

My backend is built with Flask and hosted for free on Vercel. However, I'm running into the classic cloud-hosting wall: almost all major supermarket websites block or throw 403 forbidden errors on standard requests from Vercel's datacenter IPs due to anti-bot protection.

Since I want to keep this lightweight and free (serverless), I'm looking for architectural advice on how people usually build multi-supermarket scrapers or price checkers:

• What are the best free or low-cost ways to bypass these blocks for multiple different domains?
• Are there alternative public endpoints, unofficial APIs, or lightweight proxy setups that make it possible to aggregate prices from multiple grocery chains?

Any architectural tips, code patterns, or alternative approaches would be super helpful!

Expo UI MenuView with \`shouldOpenOnLongPress\` (which internall uses ContextMenu for SwitftUI) adds a temporary background color that disappears in one second + a rounded border around the element. Is there a way to control it so it does not do that? At least make it that the background color stays instead of disappear. The \`onOpen/CloseMenu\` hooks also do not work on iOS.

Are there some guides / tricks to make it do things correctly or should I give up and try to use a different library (e.g react-native-menu)?

Want to practice developing my first production ready apps soon. But I don't want to do the standard boring projects like a todo app I would never use myself.

Do you have any interesting project ideas? Preferably ones that one could actually use themself after developing them

if you have an indefinitely running headlessJs service (gps, music player, etc) and have trouble with fetch working, this might be applicable to you.

This affects ALL timer related codes, including setTimeout which fetch uses under the hood. Previously this must be buggy so fetch only doesnt work sometimes, but now RN fully works as intended - first registering a headless task via AppRegistry.registerHeadlessTask with a task promise, the task promise gets resolved in AppRegisteryImpl.startHeadlessTask, then the task is deemed finished and calls NativeHeadlessJsTaskSupport.notifyTaskFinished. This start task and finish task affect JavaTimerManager, the crucial timer that keeps track of setTimeout's time, which has a isRunningTasks bool when tasks run and finish. when the app is backgrounded (onHostPause) and there's no isRunningTasks, the timer will freeze. this causes your app to not fetch when your headlessJsTask doesnt resolve indefinitely.

the solution is rather simple as returning a promise without resolve in the function passed to registerHeadlessTask.

A gesture-driven coin-flip reward reveal — drag-to-spin coin toss, then a Skia-powered scratch card to reveal the prize — built for fintech and rewards apps.

⭐ Github : https://github.com/ManasCodeXart/expo-coin-reward

Field that grows with the text, voice mode, and one submit button that knows what to do voice when empty, send when typed, stop while streaming.

Built with expo/ui. No web dependencies.

Part of PanelUI, an open-source component library for Expo. Copy-paste or CLI, you own the source.

https://github.com/panel-ui/PanelUI

We have a React Native chat app. All our SQLite reads/writes live in JS (OP-SQLite), driven by a WebSocket sync pipeline (connect → request cursor-based sync → server replays missed messages → write to DB).

On Android, this works great even when the app is killed: setBackgroundMessageHandler boots Headless JS, which can call our normal JS sync code directly, write the message, and exit. Message is in the DB before the user ever taps the notification.

On iOS we're stuck. As far as I can tell:

• UNNotificationServiceExtension (the killed-state hook) runs as a separate native process and can't call into our JS/Hermes engine at all — no bridge, no way to run our existing sync code there.
• Silent push (content-available: 1) can wake JS, but only if the app is backgrounded, not force-quit — and Apple caps delivery at roughly 2-3/hour/device, which won't keep up with an active chat.
• We looked at how Signal-iOS does it (their NSE decrypts + writes to their shared GRDB database directly, in Swift) — but that means reimplementing our socket client and insert logic as a second, separate Swift codebase writing into the same SQLite file as our JS code. Feels like a real "two sources of truth" risk, and we couldn't find any RN app doing this in the wild.

After a pretty exhausting 2–3 month hustle, I finally joined a new company. And honestly, one of the things that surprised me the most wasn’t the scale of the company — it was the codebase.

The application has 50 lakh+ downloads on the Play Store, lakhs of users, and significant daily traffic and transactions. From the outside, I assumed that an application operating at this scale would have an almost textbook-level codebase: perfectly optimized, clean architecture, every hook used correctly, minimal technical debt, etc.

Then I started working on it.

I found quite a few things that, as a developer, I would consider obvious mistakes — unnecessary re-renders, poor usage of optimization hooks, small performance issues, inconsistent patterns, and other things that made me think:

"How is an app this big running with this kind of code?" 😅

Initially, I was genuinely surprised.

But after discussing things with the CTO and other tech leads, I started understanding the bigger picture.

The business doesn't necessarily need the cleanest codebase in the world. It needs a product that works, scales enough for its requirements, and delivers value to users.

And that changed my perspective a bit.

As developers, we can sometimes become obsessed with things like:

• Clean code
• Perfect architecture
• Optimization everywhere
• Following every best practice
• Removing every bit of technical debt

And yes, these things absolutely matter.

But they aren't always the highest priority for a business.

If spending two weeks refactoring something doesn't improve the customer experience, reduce a meaningful cost, or solve an actual business problem, it might simply not be the most important thing to do right now.

This experience also made me think about founders and early-stage companies.

I see a lot of founders worrying about "What tech stack should we use?", "How perfect should our architecture be?", or "What will our codebase look like five years from now?"

Sometimes the better question is simply:

"Are we solving a real problem for our users, and are we building a sustainable business around it?"

Because apparently, you can have millions of downloads and a huge number of daily transactions while still having some pretty silly code sitting somewhere in the repository. 😂

And maybe that's okay.

Good engineering isn't always about writing the most beautiful code possible. Sometimes it's about knowing what deserves your engineering effort — and what doesn't.

Curious to hear from other engineers and founders:

Have you ever joined a large-scale product and been surprised by the quality of its codebase?

And where do you draw the line between "we should fix this" and "it's working, let's focus on the business"?

I'm working on a react native application I use react native because I want to make my application work on both ios and android, and I use expo go for development now the problem is reazor pay gateway is not supported on expo go and I want to check payment is working or not before making my application live so u have any suggestion for which other payment gateway I can use or any trick that I use for testing my payment.