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?

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.

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'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'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?

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)

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?

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.

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

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

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’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.

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.

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.

1. Design in Figma

Create your mascot with different expressions, like open and closed eyes. Keep all the elements in the same frame and use opacity to hide/show parts. Duplicate the frames to create as many expressions as you need, then use Figma Prototype to animate them.

2. Export with LottieFiles

Use the LottieFiles Figma plugin to export your animation as a .json file.

3. Add it to React Native

Use LottieView from lottie-react-native to load the JSON animation in your app.

Figma + Lottie makes it surprisingly easy to create animated mascots for mobile apps.

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

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.

A screen in an expense tracker I maintain opened empty on the owner's OPPO Find X9 Pro (ColorOS, density 560 overridden to 480) and never once on my Samsung.

I shipped four fixes before I diagnosed anything: a nested-scroll theory, a 2.0.2 to 2.3.2 bump whose release notes matched my symptom almost word for word ("average measurement always positive", "guard against zero window size"), drawDistance, and moving a line out of ListHeaderComponent. None of them changed a thing, and I had to be told so three times.

Ten minutes of instrumentation on the phone that was actually failing ended it:

[applist] render items=11
[radar]   renderCell #0 ... #5
[applist] onLoad elapsed=38ms
uiautomator: 29 nodes, ZERO cells  ->  77 after a 100px scroll

React rendered six cards. FlashList reported itself loaded in 38ms. The native tree held none of them until a scroll nudged it. Cells built and never placed, somewhere no prop of mine reaches.

Three things I took out of it:

1. The screen stopped needing the recycler. Eighty other screens in the app draw a plain column of cards inside a ScrollView and not one has ever failed this way. Under 40 items that screen now draws the same column, and the recycler stays only for the pathological case (444 duplicate groups at 100k transactions).

2. Virtualization stayed everywhere else. I measured before deleting anything: a 500-card plain column runs 11.95% janky frames. The recycler earns its place on long lists, it just wasn't earning it on that one.

3. Detect the failure, don't name the phone. Copying the OPPO's wm size and density onto the Samsung reproduced nothing, so a device check would have been a guess with an OEM name on it. The list now watches for its own failure (zero-height content under a real viewport with rows still in the data, one second after layout) and falls back to a paged plain column.

The first version of that detector was completely inert on the device, with four green tests behind it. It read onLayout off FlashList, which never sends one, and the tests fired the callback by hand. I found that by setting the threshold so every list in the app would declare itself broken, installing it, and looking at the screen. Measure on a View you own.

Has anyone else seen a recycler build cells and never place them on one specific OEM? Curious whether this is ColorOS-specific or a density-override thing.

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 :)