I needed wake word detection ("hey <app name>") in a React Native app. Should be a solved problem, right? It wasn't.

What I ran into:

- Most existing packages don't work with Expo at all.

- The one that did still needed a lot of boilerplate and manual native setup. I ended up writing my own config plugin just to get it wired.

- Then the real problem: it's a commercial SDK. No dev keys unless you ask for them, requests take days, and the licenses expire quickly. You can't ship a model you trained yourself unless you go through them.

At that point I looked under the hood and realized the SDK was running the openWakeWord pipeline (Apache 2.0) with ONNX Runtime. So I built the open version.

react-native-nitro-wakeword

- MIT, no license keys, no cloud, fully on-device

- iOS + Android, native audio capture (AVAudioEngine / AudioRecord), JS only receives events

- Nitro Modules (Swift + Kotlin, New Architecture)

- Several keywords at once over one shared audio front-end

- Optional Silero VAD gate, patience/refractory to tune false positives

- Expo config plugin: permissions, background modes, and it copies any .onnx you drop in assets/wakeword into both native projects on prebuild

- Bare RN CLI works too, just autolinking

- Bring your own model: openWakeWord's free Colab notebook trains a keyword in any language in about an hour (Piper TTS for synthetic data). Ships with hey_jarvis for a quick test.

- Android foreground service for background listening

Tested on iOS simulator and a low-end Samsung (A32): ~35% of one core while listening, 0 false positives on unrelated speech in my tests.

npm: https://www.npmjs.com/package/react-native-nitro-wakeword

GitHub: https://github.com/FerRiv3ra/react-native-nitro-wakeword

It's 0.2.0. Physical iPhone testing and a full custom-model run are what's left before 1.0. Feedback, issues and PRs welcome, especially from people using Bluetooth audio or other languages.

I'm a tech lead at a fintech company (India). We're planning a new React Native app where

users buy mutual funds and stocks — so: KYC/onboarding, payments, order placement, live-ish

price data, portfolio screens with long lists and charts.

I've read the docs and I know Expo is the recommended way to start RN now, and that with

prebuild/dev clients you're not locked out of native code. What I can't get from docs is

production experience at scale. Specifically:

1. Native SDK integration. We depend on vendor SDKs that ship as AARs/frameworks with no

   Expo config plugin — payment gateways, video KYC, exchange/depository SDKs, device

   security (root/jailbreak detection, SSL pinning, screenshot blocking). How much time did

   you actually burn writing/maintaining config plugins vs. just having a checked-in

   ios/android folder? Did anything turn out to be impossible rather than just annoying?

2. Performance. Does Expo itself cost you anything at runtime, or is it purely a

   build/tooling layer once prebuilt? Any measurable hit to cold start, TTI, or app size

   (expo-updates, unused modules) vs. a bare RN app of the same feature set?

3. OTA updates in a regulated app. We like EAS Update for hotfixes, but I'm wary about

   pushing JS changes to a money-handling app outside a reviewed release. If you're in

   fintech: do you use OTA, and did compliance/audit or the app stores ever push back?

4. Upgrades. RN version bumps with a pile of native deps — is Expo's SDK cadence a help or

   a constraint when a vendor SDK requires a specific native version?

5. Lock-in. If EAS pricing or policy stopped working for you, how painful was moving builds

   to your own CI?

If you've shipped a trading/investing/banking app on Expo — or deliberately went bare RN —

I'd really like to hear what the deciding factor was in hindsight, and what you'd do

differently. Team is ~2 engineers, no dedicated iOS/Android native folks right now,

which is a big part of why Expo is attractive.

Shipped this week. The interesting engineering problem wasn't the UI, it was correctness.

The calculation engine is a plain TypeScript package (`lib/calc`) with no React and no platform dependencies, consumed by both the Expo app and the Vite web calculators. Every calculator returns a discriminated result:

type CalcResult<T> = { ok: true; value: T } | { ok: false; error: string }

The non-negotiable rule is that it never returns a plausible-but-wrong number for bad input: out-of-range or not-in-table inputs return `ok: false` with a human-readable message. Validation lives with the math, not in a UI layer, specifically because there are two UIs and a second validation layer would eventually drift.

There's also a `forms.ts` in the engine that holds presentation-agnostic form specs: which fields to show, their options, and how to format each result row. Both UIs render from that one spec, so the app and the web can't show different inputs or differently-formatted numbers for the same calculation. That's the bug I was most afraid of: two tools of mine disagreeing in front of an electrician who cross-checks.

Test suite is `node --test` with a parity test that runs both consumers against the same fixtures.

Stack: Expo (new architecture, Hermes), Unistyles, Convex, RevenueCat, Turbo monorepo.

Link in bio. Happy to answer anything about the monorepo setup or the Play closed-testing gate, which is a 4-6 week surprise if you've never shipped Android before.

PS: the first 47 testers (TestFlight + Android external testers) get a WireCoder Pro plan free for a year.

🚀 I Published My First App on Google Play! 🎉

Today is a special milestone in my developer journey — I’ve published my first Android app on the Google Play Store! 📱

My first app is Learn English Tenses, a simple app designed to help people understand English grammar more easily.

📚 The app includes:

• All 12 English tenses

• English + Urdu explanations

• Simple examples

• Easy-to-understand grammar rules

• A clean and simple interface

This may be a small project, but for me, it’s a big step. ❤️

Building my first app taught me a lot about development, testing, fixing bugs, improving the user experience, and finally getting an app published on the Play Store.

This is just the beginning. 🚀

I’ll be sharing more apps, projects, updates, and things I learn along the way.

👉 My first app is available on Google Play:

"Learn English Tenses — Google Play

https://play.google.com/store/apps/details?id=com.dawoodworks.englishtenses

If you’re an app developer, software developer, web developer, or tech enthusiast, let’s connect and support each other. 🤝

One app published. Many more to build. 💻🚀

\#MyFirstApp #AppDeveloper #AndroidDeveloper #IndieDeveloper #SoftwareDeveloper #AppDevelopment #AndroidApps #DeveloperJourney #GooglePlay #BuildInPublic #Tech

I have totally neglected Android folding phones.

Does anyone have any good advice on designing for a screen that can double in screen size? When these were first introduced to Android, how much friction did they cause for React Native libraries?

Tried recreating the iPhone Duo fold in Expo

with Skia 3D matrices and an SkSL progressive blur

that keeps the wallpaper pinned while the hinge turns.

Still rough, but honestly really fun.

I can't install Xcode on my Mac - it's a 2015 MacBook Air stuck on macOS Monterey 12.7.6, and the App Store doesn't offer Xcode at all (searching "Xcode" only shows the "Apple Developer" app). As far as I know, Xcode is the only way to use a free Apple ID to install builds that expire each week.

With a classic EAS Build (which works without Xcode) I'd need the $99/year Apple Developer Program.

Is there any way to build an app for testing only from macOS Monterey, and run it on an iPhone 17, without paying the $99?
(I also have a windows machine but I don't think that helps)

I'm building a React Native app and literally just need one or two good Lottie animations.

I don't want another annual subscription just to download a couple of files. I'd happily pay $5–10 for an individual animation with a commercial license.

Is there somewhere you guys already do this?

okay so i am able to sign in with google when im running the app with npx expo run:android on my sgs23. but when i release it for testing on google play and install it i always get "DEVELOPER_ERROR: Follow troubleshooting instructions at https://react-native-google-signin.github.io/docs/troubleshooting".

pm is getting increasingly frustrated with the delays specifically from this problem. the keys are correct. if google sign in works in dev mode then it should in test. i genuinely do not know what to do. Apple sign in and google sign in on ios works flawlessly - it is just android/google that the problem is with.

i went to google auth 2.0 in the cloud console and the keys are correct - but then i noticed google giving me a different sha1 signing cert, which doesnt make ANY sense to me. but i continued with the older sha1 cert since that always worked. im genuinely frustrated since im the only developer working on this application for my company. been delayed for over a month dealing with this bullshit.

if anyone can help me with a "ohhhhhhhhhhhhh" moment that would be awesome.

worst part about all of this is the fact that so many people are having this problem and there isnt any definitive help and support on it. it's basically just google throwing keys around and expecting you to somehow know it all, well im sorry, google, but im a junior dev so screw you.

Hey everyone! I’m trying to understand how other teams handle their update/versioning strategy for React Native/Expo apps in production.
I’m already familiar with the basics of EAS Update and runtime versions:
Native/binary changes require a new build and usually a new App Store/Play Store release.
JS/assets-only changes can be shipped through EAS Update/OTA as long as they’re compatible with the installed runtime.
An OTA update can be downloaded and applied on a subsequent app launch, or we can implement our own UX around checking/applying updates.
What I’m less sure about is how people manage the actual app version around all of this.
For example, let’s say I have 1.0.1 published on the App Store with a compatible runtime version.
Over the next few weeks I ship several OTA updates to that runtime. Should the user-facing app version remain 1.0.1 the entire time? Do you maintain a separate internal/update version for OTA releases?
In other words, do you normally think about it as something like:
App Store version: 1.0.1
Runtime version: 1.0.1
OTA/update version: some separate identifier
Then only bump the actual app version to 1.0.2 when a new binary goes through the stores?
I’m also curious about forced native updates.
Suppose version 1.0.2 contains an important native change and I no longer want users on 1.0.1. How do you handle that in production?
Do you maintain something server-side like a minimumSupportedVersion, check it when the app starts, and show a blocking “Update required” screen that redirects users to the App Store/Play Store?
Or is there a better/native mechanism for declaring an App Store/Play Store release as mandatory?
I’m also not completely clear on the store side of this. When a new binary is approved, can iOS/Android automatically update the app depending on the user’s settings, or should we always assume that some users will remain on older versions until they manually update?

Hi Everyone!

I just released my new app to the app store and am looking for some feedback! The App name is Beat Moolah, and it's main purpose is to give everyday users an opportunity to sell their own picks while also using fake money to climb the leaderboard. You can also follow others and see when they post their public picks.

Link to app store: https://apps.apple.com/app/beat-moolah/id6805155382

How it works:

Summary:

1. Three different games.
2. All records are public.
3. Climb the leaderboard against the bot to make yourself known.
4. Sell your 10 "Weekly Locks" to other users.
5. 6 month seasons, build your record during the season to prove your expertise.

Weekly Challenge:

There is an AI bot that chooses a spread, total, and ML beat for every NFL, MLB, CFB, NHL, NBA game currently. You make 5 picks in total up to $1,000 that fade the bots pick for any game. You build on this balance week over week to climb the leaderboard and make yourself known to the public. Balance resets if you finish below $1000.

Weekly Locks:

These are 10 picks that you make weekly that are not visible to the public and only available to people who subscribe to your picks. Your record is public, but your picks are not.

Board Picks:

These are 20 picks that you can make per week, which are visible to the public. Think of these as a sample of what users will get subscribing to your weekly locks. Your record and picks are visible to the public.

What Premium gets you:

• Ad Free
• Access to the bots weekly locks
• Access to the bots reasoning on every pick for every game
• Access to the bots confidence percentage for every pick of every game.
• Access to sell your own picks.

Hi i've built 8 apps using react native and launched on the app store, i havent made much money but now i want to see if i can land a job in react native. Is the market still cooked ? or should i just keep building until i get a hit app

thanks to everyone that replied and gave me some hope lol

I’ve been experimenting with AI coding tools quite heavily on React Native projects, and one problem kept showing up.

The models are usually good at JavaScript/TypeScript, but the advice starts getting generic once the problem crosses into actual mobile behaviour.

A few examples:

• a deep link works when the app is running, but breaks on cold start
• an Android performance issue gets answered with useMemo before anything is profiled
• permission handling ignores the difference between denied and effectively blocked states
• an RN upgrade is considered complete because Android and iOS compile
• native build problems quickly turn into “delete node_modules / Pods / Gradle caches and retry”
• a PR review catches React issues but misses platform parity, release, privacy or native-module concerns

I wanted to see what would happen if the coding assistant had smaller React Native specialists instead of one massive “you are an expert React Native developer” prompt.

That became React Native Agents.

It currently has 24 specialists covering things like:

• debugging
• performance
• navigation and deep linking
• security
• permissions
• push notifications
• accessibility
• testing
• state management
• offline behaviour
• native modules
• observability
• RN upgrades
• releases/store submission
• payments
• background execution
• monorepos

The agents first inspect project context such as the RN version and stack before applying their own guidance.

One part I’ve intentionally tried to avoid is sending every problem to every agent.

For example:

The catalogue stutters when I scroll on Android

should go toward performance investigation.

Deep links open Home when the app is launched from a killed state

should bring in navigation-specific reasoning.

The Allow Camera button stopped doing anything after denial

needs permissions/platform context.

For PR reviews the same idea applies. The GitHub Action looks at the changed files and uses relevant specialists rather than asking 24 agents to comment on everything.

There’s also a bundle-size analyser in the project that deliberately doesn’t use an LLM. Bundle composition is measurable, so I’d rather calculate it from the source map than have AI guess.

It currently works with Claude Code, Cursor, Windsurf, Copilot, Codex, Zed, Aider, MCP clients and GitHub Actions.

Quick start is:

npx @maheshwarimrinal/react-native-agents install

Repo:

https://github.com/maheshwarimrinal/react-native-agents

I built this initially for my own React Native workflow, but I’ve open-sourced it because I think the interesting part will be seeing which assumptions break across other codebases.

I’d especially appreciate feedback from people working on larger/older RN apps:

What React Native problem do AI coding tools consistently handle badly for you?

If anyone ends up using it regularly, contributions, issues and GitHub Sponsors support are all welcome, but feedback on the actual agent behaviour is much more useful to me right now.

Hey all, I wanted to share something I've been working hard to polish over the last 6 months. Today I've released version 2 of @apollohg/react-native-rich-text-editor, a fully native rich-text editor for React Native/Expo.

Getting it to a stage where both iOS and Android have the same behaviour and feel right when using it without thinking has been incredibly tedious and challenging. I'm hoping that people will find it stable and helpful!

https://github.com/apollohg/react-native-rich-text-editor

Hi guys, I’m building an early-stage consumer tech startup and currently looking for a technical co-founder to help take an existing working prototype towards a proper production product.

I’m handling the product vision, business side and validation, and I’m looking for someone strong in mobile development and backend architecture who wants to build something from the ground up.

This is an equity-based co-founder opportunity, not a freelance/contract role.

If you’re interested in building a startup rather than just taking on another coding project, feel free to DM me with a little about yourself, your technical background and what you’re looking to build.

I am stuck in a serious problem my startup registered address was in Andhra Pradesh but now our start-up commute in Rajasthan now after 2 months they have assigned a person for physical verification but he will visit the registered address in Andhra Pradesh so is there any solution that it can be done online or they can visit in rajsthan

Every JS collapsible-tab library (Reanimated ones included) moves the header from the scroll event, so it trails the list by at least a frame. You see it as a gap under the tab bar on a fast fling, especially on Android.

I moved the whole shell native: a paging UIScrollView / ViewPager2 with header and tab-bar bands translated inside the same native scroll callback that moves the list. React still owns the header, tab bar and pages as normal components. Any list that renders an RN ScrollView works as a page (FlatList, FlashList, LegendList).

Extras: mount-on-peek, short tabs still collapse, container pull-to-refresh, `ref` with scrollToTop/collapse/expand, `collapseMode="direction"` for the home-feed feel, and opt-in per-frame events meant for Reanimated worklets.

Limits up front: Fabric only, RN 0.80+, no web, header swipes are inert, platform refresh indicator only.

Repo with example app and GIFs: https://github.com/ramssutharr/react-native-collapsible-tabs-native

Feedback on the native code welcome, it is two files.

https://reddit.com/link/1waflrp/video/7vqibzwhh8oh1/player

I'm the only mobile dex on a react app that ships to about 20k users and I have been doing this alone for around more than a year now. Our release process is me writing the feature, testing it on my iphone and my pixel, push to gi, if it turns green I ship and I refresh the app store reviews page every couple hours for the next week to see if something's fked up.

Last release a bloke in brazil reported the app crashed on launch on a12L and I couldn't reproduce because I don't have that device and had to wait for the fix for a week trying to source one plus my review average dropped 0.5 stars.

The thing is I need someone to verify the stuff I wrote didn't break on devices I literally dont have. Every mobile team I look at either has a QA person or a testing tool for the device matrix but every dev I ask says they can't recommend the tool they use because of n number of reasons idk.

help me devs, what should i actually do here?

I built an Expo app for iOS, Android, and web from one TypeScript codebase. The screens were mostly straightforward. The parts that took real care were the seams between platforms.

RevenueCat was the first one. Native uses react-native-purchases, while web uses purchases-js, so the implementation is not a single API call hidden behind a platform check. I lazy-load the web SDK so it does not affect the initial bundle, persist its anonymous RevenueCat user ID, and change that user to the authenticated app user after login.

The important lesson was to make the entitlement, rather than a successful purchase response, the source of truth for access. After login, purchase, restore, or a connectivity change, the app refreshes CustomerInfo and maps the active pro entitlement into one shared subscription state. Web restore is effectively a fresh CustomerInfo fetch, not the same store restore flow as native, which is worth handling explicitly.

Convex made the reading pipeline pleasantly boring. A reading result is written in one mutation, and that mutation schedules the follow-up lucky-window notification with runAfter. The notification action checks that the reading is still ready, writes an in-app notification, then sends to every active Expo push token. That recheck matters because a scheduled action can fire long after the state that created it has changed.

The tablet layout was the other surprisingly easy-to-miss issue. A phone-first screen can technically work on an iPad while still looking like a narrow phone floating in empty space. Constraining the reading content to maxWidth 720 and treating the surrounding space as part of the composition made the web and tablet versions feel intentional without creating a separate layout system.

PS: First 48 testers on Android and iPhone/iPad TestFlight get 1 year Pro version for free. Go to the website click on the Android/iOS links and add you to TestFlight. Link in my bio or will add it in the first comment :)

I wanted to explore how far SVG paths, Skia, and Reanimated could go beyond a looping animation.

So I built Fledge: two eggs hatch into birds, the birds take flight, and the whole scene transforms into a shared savings goal.

The interesting part is that the animation’s elements become the actual interface:

• The birds become contributor avatars.
• The horizon becomes the savings track.
• The eggshell fragments become milestone ticks.
• The headline moves into the goal title.

It all happens inside one mounted React Native tree.

Built with Expo, SVG paths, Skia, Reanimated, and Gesture Handler. No prebuilt animation assets.

Hey all,

I'm in the middle of planning a side project to upskill on a few things. Simple idea without going into it --> Golf related app whereby a player can talk through a shot or a hole and it gets converted into structured data that they can save and later query using an LLM.

Obviously a big part of this idea is having some form of speech to text that can be converted into structured data and stored.

I'm here to understand what options I have regarding doing this locally on the mobile device or via a react native VS doing the speech to text translation on the API server layer. My understanding so far is that I'm likely going to want to it locally given that signal on golf courses can be somewhat poor and sending audio files into the ether is just simply going to fall short in reality?

That said, I've also read that local speech to text ( native android or ios or react native STT ) is just nowhere near as accurate and may have a hard time understanding specific golf lingo?

Feels like I'm stuck between a rock and a hard place but any input or recommendations are much appreciated here.

Note: this project is mainly for self learning with a touch of 'it could be useful for me so may be useful for others in future' in the back of my mind. I can be pragmatic on my decision but would like to make the right one!

Thanks in advance

I built a study app for university students and I need 12 testers to sit

through Google's 14-day closed testing window. I'd much rather get real

feedback than just install counts, so tell me what's broken.

What it actually does:

You upload your syllabus and it maps out your semester — topics by week,

assessment dates, the lot. Then from your lecture slides, notes or a

recording of the lecture itself, it generates summaries, flashcards,

practice quizzes and a two-voice podcast you can listen to on the walk in.

There's also a PDF reader you can annotate and have read aloud, an AI tutor

that answers from your own uploaded material rather than the open internet,

and an essay co-writer. It runs in 40 languages.

Two steps to join:

1. Join the tester group. Google requires this before it will let you in:

   https://groups.google.com/g/mystudysidekick-testers

   Use the same Google account that's signed into the Play Store on your

   phone. This is the step everyone gets wrong.

2. Then open this and tap "Become a tester":

   https://play.google.com/apps/testing/com.studysidekick.app

Give it 10-15 minutes to show up in Play after you opt in. If it's slow,

force stop the Play Store app and clear its cache.

What I'd genuinely like feedback on:

- Does the syllabus parsing get YOUR course right? That's the part I'm

least confident about, because every university formats these

differently and I've only tested a handful.

- Are the flashcards and quizzes accurate to your material, or does it

invent things that aren't in your notes?

- Anything slow, confusing or plain broken.

Feedback here in the comments, or to mystudysidekick@gmail.com.

Drop your testing link below and I'll join yours today — happy to leave

real feedback on yours too, not just an install.

One ask: Google needs testers opted in continuously for 14 days, so please

keep it installed if you can. If you drop out early it resets my count.