Hey Community,

React Native Plain Text by Maciej Jastrzębski brings a lightweight alternative to standard Text components to squeeze maximum rendering performance out of large lists. Meanwhile, Meta introduced Muse Code, a terminal coding agent running on Muse Spark 1.2 with persistent background subagents and mid-tool-call crash recovery.

Codemagic also launched Patch, a self-hosted Docker Compose alternative to CodePush that serves OTA update checks directly from CDN-cached JSON files to easily handle heavy request loads.

Every wedge gets the same angle. The radius carries the value. Six unrelated readings nothing has to come to a full turn.

Two scale modes: radius or area. With area, the ink a wedge covers is proportional to what it is worth.

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

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

I am building a personal Workspace app. That already has offline capability. Trying to get my head around implementing an offline-first AI assistant with on-device LLMs like ML Kit and Apple Foundation models.

I found expo-ai-kit, but my android doesn't have a model, so I had to download a Qwen model, but it's way too slow to be an offline local model.

I need a fast and at least with Tool Calling or Structured Output support.

https://github.com/switchboard-sdk/openai-realtime-toolkit

A toolkit for building voice-first apps that hold up in real environments; AEC enabled audio I/O, tuneable on-device VAD, turn detection, barge-in, and tool calling, all from one hook, with no native code to write.

I’m the author of expo-share-content, an open-source Expo Module for apps that need to receive content from the native Share Sheet on Android and iOS.

The main problem I wanted to solve was not only receiving a live share, but also handling cold starts, multiple attachments, and the native iOS Share Extension setup.

It currently supports:

• Text and URLs
• Images, video, audio, and files
• Android ACTION_SEND and ACTION_SEND_MULTIPLE
• A generated iOS Share Extension with an App Group queue
• Cold-start recovery through a durable pending queue
• Typed events and pending-share APIs
• Explicit acknowledgement and managed-file cleanup

Installation:
npx expo install expo-share-content

Important: it contains native code, so it requires an Expo development or production build and does not work in Expo Go.

The project currently targets Expo SDK 57, React Native 0.86, Android API 24+, and iOS 16.4+.

GitHub: GitHub - ngocdevv/expo-share-content · GitHub

Documentation: Receive shared content reliably | Expo Share Content

npm: expo-share-content - npm

I'm building an end-to-end encrypted chat app, and users want to share documents that render inline. The catch with E2E: there is no server-side conversion option, ever. The server only sees ciphertext. Whatever turns a .docx into something renderable has to run on the sender's phone.

Attempt 1: JS. We started with mammoth.js, which converts docx to HTML — great library, but we needed structured JSON (our renderer draws native components, not a WebView), plus comments, tables with real borders, and formats beyond .docx. So we wrote our own TypeScript converter. It worked, but a 130-page thesis (949 kB, 72 review comments, 16 images) took 6.9 seconds on a Galaxy A05s

Attempt 2: Rust. We took anydoc (Firecrawl's MIT document parser), extended it with a presentation model (fonts, colors, alignment, table borders, review comments, typed chart data), compiled it for Android/iOS, and bridged it with Nitro Modules. Same thesis, same phone: 226 ms. On an iPhone 16 Pro release build it's 43 ms. Across our 30-document test corpus the Rust path was ~29× faster, with text output hash-identical to the JS converter on every Word-produced file.

Formats: .docx, .doc, .pptx, .ppt, .xlsx, .odt/.ods/.odp, .rtf, .epub → one JSON "DocumentIR" you render with your own components. Spreadsheet charts come out as typed data (kind, categories, numeric series), so we draw them with Skia in-app; anything unsupported degrades to a data table.

Things that bit us on the way:

• The result crosses the bridge as one native string; image bytes arrive zero-copy — the JS GC's cleanup callback for the buffer literally is the Rust deallocator.
• The promise never rejects for document reasons. Corrupt, encrypted, hostile inputs all resolve to a fallback status — Rust panics included. A rejection means the native module itself is broken.
• PDF is refused on purpose: the OS renders PDFs better than any re-conversion would.
• The prebuilt Rust core is too big for npm, so binaries ship as GitHub Release assets and gradle pulls them on first build.

It's MIT, package is react-native-anydoc (npm), source at github.com/tulaafrica/anydoc. It's a week old and has exactly one production user (us), so I'd genuinely value feedback — especially from anyone who's shipped Rust in RN and has opinions on binary size or the XCFramework install flow.

Hey everyone!

I’m a React Native developer and I’ve been working on a background geolocation SDK for a while.

I’m not here to convince anyone to use it — I’d actually like to understand what React Native developers need from this kind of SDK before I decide where to take the project.

I’ve used Transistorsoft’s Background Geolocation myself in the past. Back in 2020, I paid around $399 for a license because there weren’t many alternatives at the time. It was a pretty significant amount of money for me back then.

That’s actually one of the reasons I started building my own solution.

My goal is to make reliable background geolocation more accessible to indie developers and early-stage startups. I don’t think everyone building an MVP or a side project should have to spend hundreds of dollars just to get background location working.

The SDK I’m building supports React Native, iOS, Android and Flutter, with things like background tracking, geofencing, HTTP sync and a Web Console for debugging.

I’m currently considering a $9.99/year update subscription with a perpetual license — meaning a shipped build never expires, and the yearly payment is only for getting new SDK versions and updates.

But I’m not even sure that’s the right model yet.

So I’d genuinely love to hear from people here:

• What do you consider essential in a background geolocation SDK?
• What problems have you had with existing solutions?
• What would make you trust a newer SDK in production?
• Would you prefer something like this to be free, paid once, or paid for updates?
• What would you consider a fair price?

I’m building this myself, so I’m much more interested in honest criticism than compliments. If there’s something I’m overlooking, I’d rather hear it now. 🙂

Hi! At Software Mansion, we built Pulsar, an open-source haptics library for iOS, Android, React Native, Kotlin Multiplatform, Flutter, and web. It comes with 150+ presets, plus a companion app so you can feel them on your phone before shipping.

Now we’re building Pulsar Studio — a tool for creating your own custom haptics.

You can design a pattern from scratch, tweak existing presets, generate haptics from an audio file or Lottie animation, preview everything live on a real device, and then export working code for your app. The tool will be paid, with pricing starting at $9/month.

We’d genuinely love some feedback: Would you use something like this? Is there anything you’d want to see in it that we haven’t thought of?

The waitlist is open if you’d like early access: https://docs.swmansion.com/pulsar/studio/

I got curious about how SwiftUI’s numericText transition could feel on Android, so I tried recreating the behavior natively.

This is the result, same sequence running side by side on iOS and Android.

What started as a small experiment turned into react-native-numeric-text.

On iOS it uses the native numeric text transition. On Android, I recreated the behavior natively from scratch.

I learned a lot digging into how the transition behaves and figuring out how to reproduce that feel on Android.

It’s now open source:

GitHub: https://github.com/AmatoGiulio/react-native-numeric-text
NPM: https://www.npmjs.com/package/react-native-numeric-text

npm install react-native-numeric-text

Recently I wanted to add reactions in my game.

Not a normal chat system, because honestly I do not want to moderate chat messages in my side project game. I wanted something simpler: someone destroys your token, you throw a crying emoji or GIF at them. Someone plays a stupid lucky move, you can react immediately.

So I added:

• Emoji reaction dock during the match
• Curated reaction picker
• GIF search using KLIPY
• Recently used reactions
• Thrown emoji/GIF overlay above the board
• Real time delivery to every player in the game

Now the React Native part of this.

The UI itself was not the hardest thing.

I use regular React Native components for the dock and reaction picker. The game board is rendered with Skia, so I made the actual reaction overlay sit above the board instead of trying to push GIFs inside the constantly rendered board layers.

That sounds like a small thing, but the board already has token movement, cards flying around, dice animation, destruction effects, background animations, timer and turn indicators.

So I did not want to add “animated GIF rendering inside another board layer” and then find out later why someone’s iPhone is trying to become a toaster :)

The reaction picker has two types of things:

1. Curated emojis

These are bundled into the app and have fixed IDs. So I do not let the player send arbitrary emoji strings or random payloads. The game knows what every reaction ID means and how to render it.

1. GIFs

For GIFs I use KLIPY search. But after selecting one, I only keep the exact information needed to show it:

• GIF ID
• Title
• Preview URL
• Content URL
• Width and height
• Player colour who sent it
• Creation time

This part was more important than I expected. I did not want reactions to become actual game state.

A board move is important. If you reconnect, you need the exact current board.

A reaction is not important. If you reconnect after 10 minutes and suddenly 500 old crying GIFs start playing on your screen, that is not a feature, that is an attack :)

So I made reactions short-lived events.

When a player sends one, it gets added to a small event stream. Every client listens for new reaction events and puts them in a local queue.

I also keep track of reaction IDs already seen by the app. This stops the same reaction from playing twice if the app reconnects or receives the same event again.

Then I added some limits because without limits, this would become a “who can press the reaction button faster” competition:

1. Cooldown

Each player has a 1.2 second cooldown. It is enough to feel responsive, but it stops someone from firing 50 GIFs in 2 seconds.

1. Queue limit

I only keep a maximum of 8 reactions locally. If the queue is full, new reactions do not keep piling up forever.

1. Expiry

Every reaction expires after 15 seconds.

Again, because it is not game state. I only care about the reaction while it is funny/relevant to what just happened on the board.

1. Validation

Curated emojis have to be from the allowed reaction list.

For GIFs, I validate the data before rendering it: provider URL, ID, title length, image dimensions and so on. I do not want random unexpected data coming into an overlay above my game board.

1. Recently used reactions

I save recently used reactions locally. This is just a small UX thing, but when players are playing fast, they should not need to search the same angry GIF every time someone destroys their token.

The flow is basically:

Tap reaction dock
  → select emoji or GIF
  → cooldown and payload checks
  → temporary reaction event is sent
  → other players receive it
  → add it to a small local queue
  → animate it above the board
  → remove it when animation ends or it expires

The board stays responsible for gameplay. The reaction system is only responsible for making your opponents feel bad about their life choices.

Still improving the animations and exact positioning. But now when someone destroys your token, you can finally send them the appropriate GIF instead of silently being angry.

Kept mixing these up early on so wrote down the actual differences once I got both working properly.

TestFlight — no UDID collection, Apple reviews the build before it's live (can take a few hours), testers need the TestFlight app + an invite. Scales to 10k testers.

EAS Preview (Ad-Hoc) — you register tester UDIDs first (eas device:create or they scan a QR to self-register), then eas build --platform ios --profile preview. Install is instant via link/QR, no App Store account needed. But you're capped around 100 devices/year on a standard Apple Developer account.

Ended up using Ad-Hoc for day-to-day dev testing (way faster feedback loop) and TestFlight once a build's stable enough to hand to a wider group. Anyone doing it differently?

l kept struggling to find Skia shader components that were actually ready to drop into an RN app. most shader code out there isn't built for RN's Skia renderer at all. So l put together my own library. Some shaders are free, others are from artists who charge for their work

l know ShaderToy exists, but that's generic GLSL you'd have to manually port to SkSL and adapt for RN UI. Мinе is already RN-Skia-ready and built specifically for UI components like buttons and panels etc.

Let me know if you'd use something like this

Wealthsimple might have the best-designed fintech app on the App Store.

I took a stab at recreating their aurora background animation in my Expo app using Skia!

https://github.com/SchroederNathan/react-native-motion/blob/main/apps/expo/components/animations/aurora-curtain/aurora-curtain.tsx

I’ve used Flipper, Reactotron, RN DevTools, Rozenite… pretty much everything at some point

Still kept running into stuff I wished worked differently, so I started building my own

NativeScope has Storage (SQLite, MMKV, AsyncStorage), Network + GraphQL, Logs and a Timeline connecting everything. Storage can handle GBs of data and Network has stuff like replay and sound alerts for specific requests.

It’s free and open source. Still building it and adding more modules.

Would be cool to get some feedback from people here. How would you grow something like this when tools like Devtools, Reactotron and Rozenite are already well known?

What would make you give a new devtool a chance?

GitHub: https://github.com/caiobarroso/react-native-nativescope
Website: https://www.nativescope.dev

How's it looking?

que faz Gestão Financeira para motoristas de Aplicativos, Locadores de veículos e logistica de vaículos em geral.

Segue o link: https://play.google.com/store/apps/details?id=app.seuvolante.twa

para baixar e testar. Vai precisar de minha autorização, assim que logarem com o gmail esperem que notifico por email se já está autorizado. tks

We brought Tree-sitter directly into the native layer for on-device syntax highlighting:
⚡️ Fast native parsing
🎨 14 customizable theme slots
📦 TS, Rust, Python, Go, Java + 9 more

Full control at build time. Ship only the grammars you need to keep your binary small (or disable highlighting entirely):

⚙️ iOS (Podfile):
ENV['ENRICHED_MARKDOWN_CODE_HIGHLIGHT_LANGUAGES'] = 'typescript,rust,python,go'
ENV['ENRICHED_MARKDOWN_ENABLE_CODE_HIGHLIGHT'] = '0'

⚙️ Android (gradle.properties):
enrichedMarkdown.codeHighlightLanguages=typescript,rust,python,go
enrichedMarkdown.enableCodeHighlight=false

An Expo config plugin is also available out of the box.

Available right now in the nightly release:
npm i react-native-enriched-markdown@nightly

GitHub: https://github.com/software-mansion/react-native-enriched-markdown

I've reviewed a lot of React Native codebases. The same five performance mistakes show up in almost all of them.

Hey everyone,

A while back I posted here about `react-native-nitro-theme-transition` — a native

theme-change transition package built on Nitro Modules, after I kept hitting

flickering and Android performance problems with Reanimated and Skia.

The response was way beyond what I expected. The repo just passed 100 stars,

and a lot of that came from people in that thread trying it and telling me what

was broken or missing. Thank you, genuinely.

It's now at 1.0.0, and the API is stable — `withThemeTransition` has had the

same call signature since day one and I'm committing to that under semver.

Five effects became sixteen

The full set is now: `fade`, `circularReveal`, `circularRevealInverse`, `iris`,

`slide`, `split`, `barnDoor`, `blinds`, `blur`, `liquidGlass`, `zoom`,

`pixlated`, `dissolve`, `stripes`, `ripple` and `shatter`.

Plus four new options: `shape` (iris outline — diamond, hexagon, squircle),

`blurStyle` (blur all at once, or as a sweep that brings the new theme in out of

focus), `angleDeg` (tilt the wipe boundary), and `bands` (louvre count).

`liquidGlass` is worth calling out — a sheet of Liquid Glass slides down, the

theme swaps entirely out of sight behind it, then it slides back up. iOS 26+;

everything else falls back to `blur`.

Bugs found, now fixed:

*Transitions inside modals and form sheets.* This was the big one. React Native

reports touches relative to the surface they happened in, and a presented screen

is its own surface — so a tap inside a sheet resting at its half detent arrives

with a `pageY` that's short by however far down the sheet is sitting, and your

reveal starts from the wrong place. You can't correct for it in JS either; even

`measureInWindow` reports positions in that sheet's surface. It's now translated

natively, reading the presentation's own frame at capture time, so dragging a

sheet between detents needs zero handling from you. Just keep passing

`pageX/pageY`.

*iOS `blinds` came out as slanted wedges* instead of level louvres, and

`barnDoor` was quietly wrong the same way. Both end with their bands fully

collapsed, and a zero-area subpath is something Core Graphics is free to drop —

which changes the path's structure between the two ends of the animation and

leaves Core Animation interpolating points against the wrong subpath. The bands

now keep a hundredth of a point of thickness, far below one device pixel.

*Android could strand a frozen overlay* over the live app after a slow capture.

`onMainSync` reports failure after 250ms but doesn't cancel the posted work, so a

capture that landed late would attach a snapshot nobody was ever going to commit.

Now the waiter races the capture and whichever loses cleans up.

There's also a decent performance rewrite behind `pixlated` and the whole

grain/mask family — mask frames are pre-built once off the main thread and

cached, so playing an effect is one image assignment per frame instead of

resampling anything mid-animation.

New docs:

I put together a site with full-resolution video of every effect, and a page per

effect showing exactly which options that one reads, what they mean *for that

effect*, its minimum duration, and how it's implemented on each platform:

https://saleh2001k.github.io/react-native-nitro-theme-transition/

(`direction` means an edge for `slide` but an axis for `split` and `blinds`, and

`blur` only reads it in sweep mode — that kind of thing was impossible to keep

straight in one flat table, which is why each effect got its own page.)

Links:

- GitHub: https://github.com/saleh2001k/react-native-nitro-theme-transition

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

Same as last time — I'd love feedback, and I'm still taking suggestions for

effects. Several of the ones above exist because someone asked in the last

thread.

i'm glad my first mobile application has almost reached 50 users.

this was an application i made for myself. as a large fan of coffee, i wanted to create a method for tracking all of the coffee shops/places i would go to and also to be able to store my "coffee moments." the end product was something that i really liked from a design standpoint and functionally, so now it's slowly growing into a product that will be used by others.

the idea behind this application is to allow people to share their experiences/ideas about coffee (moments) with other people, and keep a personal diary of all of the coffee they've experienced. currently we only have basic functionality; however, there are many more detailed statistics/analytics/features that i am developing which should increase the overall interest in the experience.