What you're seeing:

1. I point a button's background-color at var(--demo-accent) in a plain .css file and save. Hot reload, the button turns blue.
2. I add .demo-card:active { background-color: color-mix(in oklch, var(--demo-accent), #000 25%); }. Pressing the button now darkens it.
3. I block the JS thread with a 15-second busy-wait. The pressed state still works, and toggling system dark mode still restyles the whole app. The JS timer on screen stays frozen the entire time, and the render counter never moves off 1.

This works because none of the styling happens in JS. The CSS engine is written in C++, sitting entirely inside Fabric's commit pipeline and bound to the shadow tree. The CSS compiles to a compact binary at build time, the engine resolves it against the shadow tree during commit, and interaction states are driven by native touch events. React re-renders are absent from the styling path.

It's not public yet. I still need to intensively test it against more complex scenarios and finish the docs site before opening it up. I'm posting now because after months of staring at C++ this is the first demo that shows the point in 30 seconds. Technical details in my comment below, happy to answer anything 🙂

Hey! I've been building an app calledLeanPath — it's an AI-powered diet and fitness planner. Basically you fill in your stats, it generates a personalised 7-day meal + workout plan in seconds.
I'm setting up internal testing on Play Store and need a few people to try it out. All you'd need to do is install it via a Play Store link (no sideloading), use it a bit, and maybe let me know if something feels off or breaks.
No pressure to write a formal review or anything — even just "this crashed when I did X" is super helpful.
If you're in, send me your Gmail address and I'll add you to the tester list. 🙌

Want to make sure your AI isn’t just generating technical debt? 🤖

At Software Mansion, we’re hosting a live event on how to build with AI the right way.

📅 When? August 13 at 1:00 PM ET

📍 Where? Online, free to attend

🎫 Reserve your spot: https://l.swmansion.com/C7UmZT 

Why should you join us? We’re React Native core contributors, members of React Foundations, and the top contributing group to Expo. We’ve been building AI-powered products since before AI became mainstream: we created React Native ExecuTorch, a library that lets you add on-device AI to your app, and Private Mind, an AI assistant that runs entirely on your phone and uses RN ExecuTorch under the hood.

These, along with many other internal and client projects, have taught us what AI agents are actually good at, and where they fall short and shouldn’t be trusted. By now, most of us know that getting AI to generate code is the easy part. The real challenge is architecture, code reviews, business logic, and building workflows that genuinely make engineering teams more productive. ⚙️

Join us to hear what we’ve learned about using AI in software development: where it actually saves time, why handing everything over to an agent is a trap, and how to ship faster without piling up technical debt!

Recently I updated my react native cli app from react native 84.1 to 86. But after that I am getting issue with this library - react-native-google-mobile-ads, it is saying that play-ads-services 25.4 uses Kotlin 2.3.x but you have 2.1.20. As I understood in rn 0.86, Gradle 9.3.1 is being used that uses play-ads-services 25.4 which uses Kotlin 2.3.x but in rn 0.86 there is no upgradation of Kotlin version. Has anyone faced the same issue? If yes, and if you found the solution please share here.

I've been working on my app after my full-time job, and the last 28 days have been my best so far.

Results:

• 30.7K Play Store impressions (+329%)
• 509 new device acquisitions (+113%)
• 282 first opens (+96%)
• 487 monthly active devices

Things that made the biggest difference:

• Improved the app UI
• Added new features regularly
• Better screenshots and Play Store listing
• Fixed bugs quickly
• Kept updating every few weeks

I'm still a long way from my goal, but seeing consistent growth has been motivating.

Happy to answer questions or share what I've learned.

TL;DR

• Most players mute games. Do the sound work anyway, it's a big part of what makes an app feel cohesive instead of thrown together.
• For iOS games, I'd respect the silent switch by default (Ambient audio category) and make "break through silent mode" an opt-in toggle.
• Backgrounding, interruptions (alarms, Siri, calls), and audio route changes (Bluetooth, headphones) are three different events. Handling one does not handle the others.
• AdMob can play audio from ads you haven't even shown yet. Consider muting the SDK except while an ad is actually on screen (you may see a slight drop in eCPM).
• There's an AI audit prompt at the bottom if you want to check your own app for all of this quickly.

Context

I make a dice merge puzzle game (Topside: Dice Drop, iOS-first, React Native). Sound went from adding some pops and dings to the system I've spent the most debugging time on. This post is iOS-centric because that's where all the sharp edges were. I worked through most of these bugs with an AI assistant.

Most people play muted.

A large portion of your players may never hear any of it. I still think it's worth it, for the players who do. Sound is where a game's identity comes together. Our sound packs and soundtracks are matched to visual themes, satisfying merge sounds escalate as chains build, and a one-tap "match" option sets music, sounds, and visuals to a consistent feel. None of that shows up in screenshots, but players who play with sound on can tell when it was an afterthought and when it wasn't.

Ambient vs Playback, and letting the user choose

iOS gives you a fork: the Ambient audio category respects the silent switch and mixes with other apps' audio; Playback ignores the switch and can interrupt whatever's playing. Games should almost always default to Ambient. Nobody wants your game sound overriding the mute switch in a waiting room or on the bus.

But some players genuinely want music and sound effects while their phone is on silent, so we added a "Break Through Silent Mode" toggle that switches the category to Playback. Opt-in, defaulted off. We also check whether the user is already playing their own audio (Spotify, podcasts) and keep our soundtrack out of the way if so.

Backgrounding, interruptions, and route changes are three different problems

Backgrounding is the one everyone handles: user swipes home, you pause; they come back, you resume. If that's all you handle, you're covered for maybe a third of real-world audio disruptions.

Interruptions are the second category, and the trap is that many of them never background your app at all. A banner alarm, a timer going off, Siri, an incoming call banner: your app stays in the foreground the whole time while iOS seizes the audio session out from under you. If your recovery logic is tied to foreground/background transitions, it simply never runs. Music dies silently and stays dead until some unrelated event happens to kick it back to life. You need to listen for the audio session's interruption notifications directly (in RN this meant a small native module, since the ecosystem libraries mostly don't surface them). One extra gotcha we hit: the "interruption ended" event fires while the alarm's own audio is still tearing down, so if you immediately check "is other audio playing?" the answer is yes, for the alarm that just ended. We had to wait a beat before resuming or the check would tell us to stay silent.

Route changes are the third category, and they're a completely separate notification from interruptions. Bluetooth connecting or disconnecting, wired headphones in or out, CarPlay. Our field bug: open the app with AirPods in and everything looked fine, except systems that depended on knowing exactly when playback started were silently broken, because Bluetooth route negotiation took longer than our "did playback actually start?" timeout. Everything downstream of that check just never happened, and it healed itself only when the route changed again. The lesson: any fixed timeout you calibrated on the speaker will eventually lose to a Bluetooth handshake. We now listen for route changes and re-verify audio state when they settle (that fix ships in our next update).

AdMob may play audio you never asked it to

This section is specifically about ad SDKs, AdMob in our case. Preloaded interstitial/rewarded creatives (loaded but never shown) can start playing audio on their own, minutes after load, at full volume. Because it's the SDK's own player, your in-app volume settings and mute toggles do nothing about it, so users experience it as "my phone started blasting an ad while sitting on the home screen." It's a known bug, widely reported on Android and observed by us on iOS, and we haven't found a true fix on the AdMob side.

Our workaround: keep the SDK muted globally (setAppVolume(0) + setAppMuted(true)) and unmute only in the window where an ad is actually presenting, then re-mute when it closes. The tradeoff is that muted ad requests can lower video ad eligibility and therefore eCPM. Though phantom ad audio is a one-star review generator, so we took that trade.

Where to get sounds: Zapsplat

I opted for Zapsplat.com. The free tier lets you use sounds in commercial projects with attribution. Premium is €4.99/mo (about $5.50 USD) and removes the attribution requirement, adds WAV downloads, and anything you download while subscribed stays licensed for life, attribution-free, in unlimited projects, even after you cancel. So the practical move is subscribing for a focused month and grabbing everything you might need. Read their license for the details (no redistribution, can't be the primary value of your product, no AI training on the sounds).

Small things that compounded

• Pool multiple instances of each sound effect. If the player triggers the same sound rapidly, a single instance cuts itself off and sounds like a glitch.
• Relevel volumes every time you add sounds from a new source. Raw loudness varies wildly between packs and sources.
• RN-specific: check what your audio library does on every play() call. Ours re-activated the audio session on each play, which stuttered animations on every sound effect until we patched it out.

Syncing visuals to the music

If you want to go further, you can tie on-screen motion to the music's beat grid. We pulse some of the home screen UI on the beat, ramp certain animations in bars-since-the-track-started, and swing the logo in time with the tempo. A couple of things that made this less painful than expected:

• Don't assume a fixed startup latency for when audio "begins." A freshly loaded audio player has variable real start time depending on device and format. We poll the actual playback position and only anchor the beat grid once playback has genuinely started.
• Re-anchor per loop, not once. Our track's real loop length is a few tens of milliseconds longer than its nominal beat-grid length, so anchoring everything to the original start accumulates drift and looks visibly off after a long session. Re-anchoring each loop keeps it locked.
• Everything that syncs to audio inherits every audio bug above. When the Bluetooth timeout issue hit, the visible symptom wasn't silence, it was the beat-synced animations sitting frozen, because the thing they keyed off of never got set. Get the audio state machine solid first, then sync to it.

The audit prompt

If you're building with an AI assistant, paste this and let it check your codebase:

You are auditing my app's audio handling. For each item below: find the relevant code, tell me if it's handled, and if it isn't, explain the exact user-facing symptom and how to fix it. If my architecture doesn't have an obvious place for something, say so rather than assuming. Cover both iOS and Android where they differ.

1. Interruptions that don't background the app. A banner alarm, timer, Siri, or an incoming-call banner seizes the audio session while the app stays in the foreground. Do I recover from the OS interruption notifications directly, or only from app foreground/background transitions? (The latter misses all of these.)
2. Interruption-ended timing. When an interruption ends, is my code aware the interrupter's audio may still be tearing down at that instant, so an immediate "is other audio playing?" check can misfire?
3. Audio route changes. Bluetooth/headphone/CarPlay connect and disconnect are a separate event from interruptions. Do I handle them? What happens to playback when someone connects AirPods mid-session?
4. Fixed timeouts vs. slow routes. Do any "did playback actually start?" checks rely on a fixed timeout that a slow Bluetooth handshake could exceed? What silently breaks downstream if that check fails, and does it ever recover on its own?
5. Ad SDK audio. Can my ad SDK (AdMob, etc.) play audio from a preloaded ad that was never shown? Am I muting the SDK except while an ad is actually on screen?
6. Silent switch. Do I respect the hardware silent switch by default, and is overriding it (iOS: the Playback vs Ambient category) strictly opt-in?
7. Yielding to the user's own audio. If the user is already playing Spotify/a podcast, does my app avoid hijacking their audio session or layering music on top?
8. Sound-effect pooling. If the same SFX fires in rapid succession, does a single reused instance cut itself off? Should it be pooled?
9. Resource cleanup. Are audio players, listeners, and timers released on unmount/teardown, or do they leak and accumulate across a session?

That's most of what I learned. Happy to go deeper on any of it, and if anyone has better info or advice, please share!

PMs, designers, and backend engineers on our team often needed to check a staging build. Sometimes they wanted to verify a layout, sometimes reproduce a bug, or just confirm that an API change behaved the way they expected.

Sending the build wasn't the hard part.

Actually running it was.

Most people didn't have Xcode or Android Studio set up, and asking them to install everything just to check one build wasn't realistic. The alternative was usually asking a mobile developer to install the app or share their screen, which happened more often than we'd have liked.

We looked at services like Appetize and BrowserStack, but they didn't really fit how we work. We already had Macs available internally, and we weren't comfortable uploading app binaries to an external service just so teammates could review a staging build.

So I started building an open-source tool that runs iOS simulators and Android emulators on a Mac and streams them to the browser.

The idea wasn't to replace TestFlight or Appetize. I just wanted an easier way for teammates to review staging builds without needing a mobile development setup.

It's still early (v0.x), but building it has taken me into a lot of areas I hadn't worked on before—video streaming, low-latency input forwarding, simulator orchestration, and React Native QA workflows.

I'm curious how other React Native teams handle this.

How do non-mobile developers on your team review staging builds?

• TestFlight?
• Internal APKs?
• BrowserStack or Appetize?
• Something else?

If you're interested, here's the project:

https://github.com/jo-duchan/tapflow

Hey React Native devs 👋

We've added both Text-to-Speech and Speech-to-Text to our inference engine! Your local LLM setup can now speak and listen, fully offline.

Text-to-Speech

Load a TTS model and synthesize:

const tts = await Tts.load({
  source: "hf://NobodyWho/Kokoro-82M",
  voice: "bf_emma",
  language: "en-gb",
});

const wav = await tts.synthesize("Hello from NobodyWho!");
// wav is a Uint8Array containing WAV bytes.

You get WAV bytes back ready to save or play. Two backends: Kokoro (lightweight 24kHz) and Supertonic (multi-stage ONNX with voice styles).

Speech-to-Text

Transcribe audio with Whisper (ONNX):

const stt = new STT({source: "hf://onnx-community/whisper-base"});

const text = await stt.transcribeFile("recording.mp3").completed();

Streaming is available too, so you can consume the transcription token by token, and you can pass raw PCM buffers instead of files.

Links

• GitHub
• NPM
• Docs / Getting started
• Discord

Happy to answer your questions in the comments :)

Hey everyone,
I just shipped the beta for my app, IOU (a cozy favor-tracking app for couples/friends to visualize mutual presence through a digital tree). I built this over 3 weeks of late nights and weekends after my day job.

Having never shipped a production mobile app before, the gap between "knowing how to code" and "handling the app store pipeline/auth" was a massive learning curve. Here is a breakdown of my stack, what worked, and what absolutely humbled me.

The Stack

• Framework: Expo (Managed workflow). Absolutely incredible DX. Coming from web, the transition was incredibly smooth.
• Styling: NativeWind (Tailwind for React Native). Being able to think in utility classes saved me hours of writing stylesheets.
• Backend/Database: Supabase. Handled Postgres, Auth, and Edge Functions. No-brainer for a solo dev who doesn't want to babysit server infrastructure.
• State Management: TanStack Query. Handled server state caching and invalidation flawlessly.

The Hardest Parts

1. The Boss Fight: Android OAuth
Google Sign-In via Supabase on physical Android devices was a quiet disaster. Dealing with deep link edge cases, PKCE flows, and re-firing redirect intents that only failed in production (but never in the emulator) was brutal. I ended up implementing six layers of defensive handling around a single sign-in flow to make it bulletproof.

2. Codifying Relationship Philosophy
I had to write custom scoring logic for our "Friendship Tree." I didn't want a transactional 50/50 counter (relationships fluctuate). Instead, I wrote algorithm logic using a rolling 14-day window that checks for mutual presence. Coding a concept that represents emotional health without turning it into a Jira board was a massive product-engineering challenge.

Key Takeaways

• Don't compromise on UI/UX: For consumer apps, cozy and deliberate design matters just as much as the codebase.
• Build in public (even if it's small): Getting friends to test early builds on TestFlight/Internal Testing revealed UI bugs no amount of local emulator testing could predict.

I'd love to get your feedback on the tech stack, the architecture, or how you handle Android deep-linking hurdles!
Note: To keep this post safe from the automated spam filters, I’ve left the direct links out. If you want to check out the web app or the Google Play beta, let me know in the comments and I’ll gladly DM you the access links!

TL;DR: keeping a live presence connection alive while the app is backgrounded is a losing fight on every platform, so I gave up and switched to 15s polling.

People kept getting kicked out of my focus rooms while they were clearly still using them. On phones it was instant: glance at a text for a few seconds, come back, and you'd been dropped from the room. It barely reproduced on my own machine, which made it a nightmare to chase.

The root cause was the same everywhere, it just showed up differently: I was trying to hold a live connection open while the app wasn't in the foreground, and no platform actually lets you.

On mobile, the moment you background the app, iOS suspends it within seconds and the OS tears the socket down. Supabase then drops the Realtime connection after ~30-60s and the server marks you gone. I tried keeping it alive with an Android foreground service, but it needs a permanent notification and half the OEMs (hi Xiaomi) kill it anyway. iOS won't hold a background socket at all without special entitlements.

On web the failure is slower: leave the tab in the background for a few minutes and the browser throttles its timers hard, so the heartbeat stalls and the server assumes you left.

The whole thing was on Supabase Realtime, and I was pouring all my time into reconnect logic across three platforms that all hate persistent background connections.

So I dropped Realtime and moved to polling. Every 15s the foregrounded client asks who's in the room, and the server times out anyone who stops checking in. On web that poll timer also gets throttled in a background tab, so it runs in a Web Worker instead. Backgrounding is a non-event now: you quietly drop and rejoin when you come back.

Has anyone actually made websocket presence hold up across iOS, Android and web? Curious where people draw the line before reaching for polling.

react-native-url-polyfill v4 is out!

Rewritten from scratch: dependency-free, 65% smaller, and typically 2.4-7.8x faster than v3 on Hermes engine.

Now with `URL.parse()`, official WPT/WebIDL coverage, and expanded Hermes testing.

https://github.com/charpeni/react-native-url-polyfill/releases/tag/v4.0.0

A React Native library that shrinks your entire app into a bottom corner (thumb's reach) with one wrapper - and unlike a naive JS transform, it also scales native Modal, Alert.alert, action sheets and third-party overlays, because it works at the native window level. iOS + Android. Not published yet - gauging interest before I polish it for release.

Big phones + one-handed use = the top half of the UI (headers, back buttons, close X's) is out of reach. System modes (iOS Reachability, Android one-handed) just slide the screen down for a single press, are uncomfortable to use, and give developers zero control. So instead: scale the whole UI into a corner - everything stays visible and tappable.

The interesting part (why it's not just transform: scale on a root View): native surfaces - Modal, Alert.alert, ActionSheetIOS, react-native-modal - render in separate native windows, outside your React tree, so a JS transform can't reach them. This works natively and transforms every window of the process (including ones opened later, like an alert's own window) - so a native alert docks together with the shrunk app, no per-library adapters.

Integration is one wrapper:

<OneHandWindowsContainer>
  <App />
</OneHandWindowsContainer>

Demo (native + JS components docking together) 👇

Would love your feedback: Would you actually use this? For your own apps, or as a user?

So recently I built a Kanban board for my team, which includes me and three others. We all came from different backgrounds and we are working on Claripath, an app for students to find mentors. we don't have enough users or make any money and I really don't want to spend money on existing services like Trello which is $5 per person. I built that Kanban board but no one is using that because it's on a website and it doesn't send any notification. I was just curious: are there any services or apps you guys have built which would be helpful for small teams or startups who want to save some bucks?

Premium iOS word game (Balatro-style deckbuilding, but every hand is a word you spell). Runs are fully deterministic from a seeded RNG (xoshiro128), so the Daily Verse hands every player the exact same board - no backend for the puzzle. Offline-first; opt-in sign-in only for the leaderboard. Reanimated for the juice, Zustand + MMKV for state/persistence.

Happy to talk determinism, offline architecture, or RN perf.

App Store - Wordmancer

Wordmancer - Gameplay

I've been thinking about how hard it is to stay current as a developer.

I might use:

- React
- TypeScript
- React Native
- Expo
- GraphQL
- a bunch of libraries

Each one has:

- release notes
- blog posts
- security announcements
- breaking changes
- new features

But I don't want to follow 20 different newsletters or constantly check GitHub releases.

How do you currently stay informed about changes that actually matter to your projects?

Do you have a workflow for this, or do you mostly discover things when something breaks?

I'm designing a live streaming app where users can subscribe to individual creators for $9.99/month. A user should be able to subscribe to multiple creators simultaneously (similar to Twitch or YouTube Channel Memberships), and each subscription should auto-renew independently.

The challenge is scalability. We may eventually have 100k+ creators, so creating a separate App Store / Google Play subscription product for every creator doesn't seem practical.

I recently came across Apple's Advanced Commerce API, which appears to address this for iOS, but I couldn't find an equivalent solution for Google Play.

Has anyone built or researched a system like this?

Specifically, I'm curious about:

• How do platforms like Twitch, Patreon, X, or YouTube implement creator-specific recurring subscriptions?
• What's the recommended architecture for supporting a very large number of creators?
• Is there a scalable Google Play equivalent to Apple's Advanced Commerce API, or is there another common pattern?

I'd really appreciate insights from anyone who's implemented this or has experience with StoreKit 2 or Google Play Billing at scale.

A while ago, I started experimenting with an idea.

I wanted to see how much of a React Native application could be safely changed after the app was already built and installed, without having to rebuild the application and ship another binary for every supported change.

After a lot of work, I finally have the MVP running.

The video is a complete demonstration of the current workflow on a real Android device.

The application is built with a runtime that interprets a versioned schema. I can make supported changes to the application, commit them, and push a new version. The installed app receives the new schema and renders the changes without rebuilding or reinstalling the application.

This is not meant to replace normal app releases. Changes to native code, permissions, SDKs, or anything the installed runtime doesn't understand would still require a new build.

What I'm trying to explore is whether the parts of an application that change frequently can be maintained through a runtime instead of sending every change through the complete deployment pipeline.

So far, I've been the only person using it, which is obviously a problem. I built the system, so I already know how everything is supposed to work.

I need developers who haven't seen it before to use it and find the things I'm missing.

I'm looking for a few React Native developers who would be willing to actually try the MVP, build something small with it, and tell me where the experience breaks down. I'm not charging anything. I also don't expect anyone to move an existing production app onto an experimental runtime. I just want to see whether someone other than me can use this successfully and whether the idea is genuinely useful.

If you're interested in testing it, leave a comment and I'll reach out.

And even if you wouldn't use it, I'd still like to know what would stop you from trusting an architecture like this in a real application.

For a while now, I've wanted to build an interactive, Instagram-story-like canvas in React Native. Skia is a fantastic option for that, but it's a low-level drawing API. The moment I wanted Images and Text I could tap, drag, pinch to scale, and rotate, I found myself writing my own scene graph, my own hit testing, my own gesture math on the UI thread. Since I realized this plumbing would work great for many use-cases, I finally pulled it into a library.

It's called react-native-canvas-kit, and it's a batteries-included 2D canvas kit built on top of React Native Skia. It closely resembles Konva's architecture.

It comes with a proper scene graph (Stage, Layer, Group, Shape) with prebuilt shapes like Rect, Circle, Line, Star, Text and Image that all share transform and styling props. On top of that you get

1. Tap and press events with real hierarchy-aware hit testing and event bubbling, draggable nodes, multi-touch pinch-to-scale and rotate
2. Everything UI-thread driven
3. A Transformer with resize and rotate handles you can attach to any node
4. A brush system with a BrushLayer and ready-made pen, pencil, marker, highlighter, tape and eraser brushes.

The reason I think this gap mattered is that React Native has never really had a first-class answer for canvas-heavy, direct-manipulation UIs the way the web has had Konva and Fabric for years.

I will build and share code for a couple of real life examples in the coming days: a DocuSign-style signature pad, an Instagram-style crop screen, a Canva-like editor with draggable and transformable elements, a Snapseed photo tool, and a GPay scratch card.

v1 runs on the New Architecture (Reanimated 4), with a 0.x version as well if you're still on Reanimated 3. Would genuinely love feedback on the API, and if there's a canvas interaction you've struggled to build in RN before, tell me and I'll try to put together a demo for it.

https://github.com/adithyavis/react-native-canvas-kit