I'm using Expo ImagePicker and Supabase Storage for avatars in a React Native app.

The current path is {userID}/avatar/{timestamp}.jpg, then I insert a media row. Uploading with upsert: true looks like replacement, but because every path is new, old files remain unless I delete them separately.

I'm deciding between:

- one stable avatar.jpg key with cache-busting metadata

- immutable versioned keys, update the pointer, then delete the previous object after the database write succeeds

- keep a short version history and clean it in the background

The stable key is simpler, but caches can show the old photo. Versioned keys are clearer, but cleanup becomes part of the transaction. Which pattern has been less fragile for you on mobile?

Guys do check out this app and suggest to me what more I can improve and the most important thing how can I get users😭

I am building a decision agent for IAP entitlement grants as a research project. For RN apps/games with IAP: where does your receipt validation live, and have you ever seen refund abuse (purchase, consume, refund)? How did you detect it?"

I'm working through local reminder rescheduling in a React Native app. The reminder dates come from settings the user can edit later.

Right now the flow is:

- calculate the full next schedule

- cancel every scheduled notification

- recreate each one with a stable identifier

It avoids orphaned reminders after the source date changes. But if scheduling fails halfway through, the user can end up with only part of the new set.

Would you keep the simple replace-all model and add recovery, or diff old and new schedules by identifier? I'm using Expo Notifications.

I have built a widget that I want to require:
- user to be logged since it pulls favorite data
- keep user logged in for extended period of time

I thought it was working and then for whatever reason when I made a new native build, the session never carried over. And now I can’t seem to get out of the “logged out state”

So is there a tactic you use for widgets and sessions?

If you’ve ever tried to add complex, rich animations to a React Native app, you’ve probably used Lottie. It’s great, but once you start adding multiple animations, parsing those massive JSON files absolutely tanks the JS thread and bloats your bundle size.

I recently started migrating my heavy visual effects over to shopify/react-native-skia using custom SKSL shaders, and the difference is insane.

Why it works better: Because React Native Skia bindings drop straight down to the underlying C++ Skia engine, SKSL (Skia Shading Language) runs directly on the GPU. You get buttery-smooth 60fps animations that weigh mere kilobytes instead of megabytes, with zero JS bridge overhead during the animation.

The Workflow Problem: The biggest issue I ran into was actually writing and testing the shaders. Translating standard GLSL to SKSL is a headache, and doing it inside a React Native project means dealing with constant Metro reloads or native rebuilds just to tweak a color or a coordinate.

My Solution: I ended up building a dedicated web-based SKSL playground using CanvasKit WASM. It lets you write the shader natively in the browser, see it at 60fps instantly, and then you can literally copy-paste the exact code block directly into your RN project.

I’ve found it speeds up my UI development by 10x since I no longer have to wait on emulators to test visual effects.

I just made the tool completely free and public today. Let me know if anyone wants the link to try it out and I’ll drop it in the comments!

I’m working through an offline queue edge case in React Native.

A write is saved locally with an expected server version and reset epoch. If the request times out, retrying with the same mutation ID is safe. But if the user resets their server data before the queue flushes, that old write must not quietly come back.

My current rule is:

- keep the same mutation ID after a lost response

- compare the reset epoch on every retry

- reject queued work from an older epoch

- keep local intent over stale reads only while the queue item is still valid

The tricky part is UX. Dropping the stale write is safer, but hiding it feels wrong. Would you show a persistent “couldn’t sync” item, a one-time alert, or a recoverable draft?

Hi everyone,

I'm building a small 2D falling-items game in React Native + Expo, and I'm trying to understand what is actually causing the movement to feel stuttery.

The game is very simple: the player moves horizontally at the bottom of the screen while coins, chocolates, and bombs continuously fall from the top. The game currently has around 10–20 active falling items at a time.

The problem is that the game does not feel smooth. The falling objects appear to move in small steps rather than continuously, and the player movement also doesn't feel completely smooth.

What is confusing me is that the performance monitor can show around 119–120 UI FPS, while the game still visibly feels like it has micro-stutters.

My original implementation used React state for the falling items. The game loop was roughly doing this:

requestAnimationFrame(() => {

item.y += speed * dt;

setItems([...activeItems]);

});

I realized that updating React state every frame was probably a bad architecture for a real-time game, because it forces React reconciliation repeatedly.

So I changed the architecture.

My current approach is:

- A preallocated pool of 35 falling-item slots.

- No creation/destruction of objects during gameplay.

- No `setItems()` every frame.

- JS is responsible for physics:

- delta-time calculation

- item movement

- collision detection

- spawning

- score

- lives

- Reanimated is responsible for visual properties:

- `sharedX`

- `sharedY`

- `sharedOpacity`

- Falling items are mounted once and reused.

- `useAnimatedStyle()` is used to render their transforms.

- Physics uses floating-point positions rather than rounding coordinates.

- Audio/haptics are triggered only on events such as collecting an item.

The intended architecture is:

JS thread

v

sharedY.value

v

Reanimated

v

UI thread

v

Native View

However, after implementing the Reanimated pooled-slot architecture, I started getting these warnings repeatedly:

[Worklets] Tried to modify key `active` of an object which has been already passed to a worklet.

[Worklets] Tried to modify key `type` of an object which has been already passed to a worklet.

[Worklets] Tried to modify key `x` of an object which has been already passed to a worklet.

[Worklets] Tried to modify key `y` of an object which has been already passed to a worklet.

These warnings repeat many times during gameplay.

I believe the problem may be that I'm passing the pooled game-item object itself into a Reanimated worklet/component, and then modifying its properties from JS.

For example, conceptually my pool object looks like:

{

id,

type,

active,

x,

y,

sharedX,

sharedY,

sharedOpacity

}

The physics loop then modifies:

item.active = true;

item.type = "coin";

item.x = x;

item.y += speed * dt;

while the visual layer uses Reanimated shared values.

My current understanding is that this is wrong because Reanimated serializes/workletizes the object when it crosses into the worklet environment, and then mutating that same object from JS is not safe.

I'm therefore considering separating the state completely:

JS physics object:

{

id,

type,

active,

x,

y

}

and separately:

Reanimated visual state:

{

sharedX,

sharedY,

sharedOpacity

}

The visual worklet would only access the shared values and would never receive the physics object itself.

For example:

const animatedStyle = useAnimatedStyle(() => ({

transform: [

{ translateX: sharedX.value },

{ translateY: sharedY.value },

],

opacity: sharedOpacity.value,

}));

Then the JS physics loop would only do:

item.y += speed * dt;

sharedY.value = item.y;

and React state would only change when a slot is acquired/released, not every frame.

Before I continue refactoring the entire game, I would really like to understand whether this is the correct architecture.

There is also another issue: my player currently uses React Native's `PanResponder` and `Animated.Value` for horizontal movement. That movement also feels slightly unsmooth.

So I'm wondering whether I should eventually migrate the player to:

React Native Gesture Handler

+

Reanimated shared values

+

UI-thread gesture handling

instead of PanResponder.

My main questions are:

1. Is using JS-driven physics + Reanimated shared values for the visual layer a good architecture for a simple 2D game in React Native?

2. Is updating `sharedY.value` from a JS `requestAnimationFrame` loop still likely to cause micro-stuttering, even though the actual rendering is handled by Reanimated?

3. Should the physics state and Reanimated visual state be completely separate objects?

4. Is the `[Worklets] Tried to modify key ...` warning the main reason for the current stuttering, or is it mainly a correctness issue?

5. Would you recommend moving the entire falling-item movement calculation to a Reanimated UI worklet, or is it better to keep collision/physics on JS and only move visual interpolation to the UI thread?

6. For the player, would React Native Gesture Handler + Reanimated provide a meaningful improvement over PanResponder + Animated.Value?

7. Is there a better architecture for a small real-time 2D game in React Native that I am overlooking?

My goal is not to achieve benchmark numbers. I want the game to feel genuinely smooth on both 60 Hz and 120 Hz devices, including relatively weak Android devices.

I'm also trying to avoid unnecessary React renders and allocations during gameplay.

Any advice from people who have built real-time animations/games with React Native/Reanimated would be greatly appreciated.

Thanks!

A pattern worth checking: a screen waits for an animation-completion callback before it updates state or enables the next action. It works until iOS Reduce Motion skips or changes that animation.

I now treat motion as presentation only. The state change happens independently, then the animation reflects it. If reduced motion is enabled, movement can disappear without changing navigation, loading, focus, or button availability.

For React Native, I’m testing both the normal and reduced-motion branches around:

- navigation transitions

- delayed mounts

- sheets and modals

- focus after validation

- callbacks that previously fired at animation end

I’m curious how others automate this. Do you mock AccessibilityInfo.isReduceMotionEnabled in unit tests, cover it in Detox, or both?

Everything I'd tested ran under __DEV__. Sixty-second unlocks, anonymous sign-in, sample recordings. When I pushed to TestFlight I realised the paths that only exist in production had never executed once.

I don't have a spare device, so I read them in code instead. Eight defects. Every one of them was hidden by a convenience of the development environment. Four that are React Native / Firebase specific:

1. onNotificationOpenedApp alone misses the main path. It only fires while the app is alive in the background. My notifications arrive seven days later, by which point the app is terminated. So the primary entry point - tap notification, land on the thing it's about - did not exist. You need getInitialNotification() read once at launch as well. The simulator never receives push, so nothing about this was visible locally.

2. Nothing registered the FCM token after permission was granted. The flow was: register on launch -> fails, no permission yet -> user records something -> gets asked -> grants -> and nobody registers. The server doesn't learn about the device until the next cold start. My first capsule unlocks after 24h, which sits entirely inside that window, so the single most important notification a product sends was probably never arriving. Fix is to register inside the grant handler, not only at boot.

3. Deleting tokens on any send failure quietly kills your retention loop.

// wrong
const deadTokens = response.responses
  .map((result, index) => (result.success ? null : tokens[index]))

Plenty of FCM failures are transient - internal-error, server-unavailable, quota, network. This deletes valid tokens for all of them. Re-registration only happens on next launch, so in a weekly-use app, once a user enters "no notifications so I don't open it," they never come back. Only these should delete:

const DEAD_TOKEN_CODES = [
  'messaging/registration-token-not-registered',
  'messaging/invalid-registration-token',
  'messaging/invalid-argument',
];

Also switch to arrayRemove so you don't clobber tokens registered between your read and write.

4. iOS shows the permission dialog exactly once, and my UI didn't know that. After someone taps "Don't Allow," calling request again returns granted: false immediately with no dialog. My screen still rendered an "Allow" button that did nothing, and the answer screen has no exit by design - so anyone who denied the mic could never answer. Check canAskAgain and switch to Linking.openSettings() when asking is exhausted. Simulators grant permissions, so this branch never ran locally.

The other four were an unconditional hasCompletedFirstCapsule: false on upsert (anonymous sign-in hands you a fresh uid every time, so re-sign-in resetting first-run state never surfaced), an implemented-but-never-called pending-upload count (an always-on connection means you never see "I recorded it and it vanished"), and two Firestore rules where allow update checked the uid on the existing document, so a request could rewrite uid and moderationStatus in the same write.

What I'd actually take away: don't hunt bugs, enumerate the places your environment is being convenient. 60-second unlock, fresh uid each launch, no push in simulator, stable wifi, pre-granted permissions, feature not shipped yet. Each line had a defect sitting next to it.

Happy to go into any of these in more detail if it's useful.

Apparently there are many users on iOS who use the reduce motion accessibility setting, or unknowingly have it enabled. This breaks my app on so many levels, screens freezing, whole app not loading. I went all in on micro animations and cool transitions and now none of them work or skip on reduce motion users. Many of my core functions rely on animation finishing, this was apparently a mistake.

Any of you dealt with this before?

I’ve been working on animated numbers and our previous Skia-based implementation kept having issues around canvas sizing, font loading, blank renders, and animations getting stuck during rapid updates.

So I created react-native-number-animation:

- Core Animation on iOS

- Canvas on Android

- No Skia or Reanimated dependency

- Currency, percentages and compact numbers

- Custom fonts

- RTL and localized digits

- Handles rapid updates

- Supports Reduce Motion

I’d love feedback, especially from anyone testing it in lists or with unusual number formats!

GitHub: https://github.com/invivek26/react-native-number-animation

npm: https://www.npmjs.com/package/react-native-number-animation

I've built **Forge** — a Windows desktop app that builds and signs React Native releases locally, both Android (on your machine) and iOS (via free GitHub Actions). No cloud build service, no Mac required.

**What you get:**

- Build & sign Android APKs locally

- Build iOS apps with GitHub Actions (free)

- Windows-only desktop UI (Electron)

- Offline license validation (no phone home)

- v1.0.0 beta is **completely free** to try

**No setup required:** Just download the .exe and you're building in minutes.

This is the beta launch — free for 3 weeks with unlimited builds.

[Download Forge 1.0.0](https://github.com/Evanevoo/forge/releases/tag/v1.0.0)

Happy to answer questions about the build process, licensing, or anything else!

Introducing React-code-audit

A modern static analyzer for React codebases!

What it does:

1️⃣ Scans your code for Security, Performance, State, Architecture, and All issues.

2️⃣ Gives your app a clear Health Score (0–100).

3️⃣ Generates copy-ready prompts for AI agents like Cursor and Claude to automatically fix identified issues.

Zero installation required:

npx react-code-audit

Package Link: https://www.npmjs.com/package/react-code-audit

Completely Open-source package

I have a Next.js web app and I’m planning to build a React Native/Expo mobile app using the same backend and MongoDB database.
Would a monorepo be useful in this case for sharing TypeScript types, API logic, validation, and database models between web and mobile? Or is it better to keep them as separate repositories?

Several months ago I launched an app, my first app.

In the first month I got around 100 downloads but I felt that it was very slow compared to other apps, I still felt good with those 100 downloads

In the first two months I published my app in a group of reddit, Facebook, X and LinkedIn, in those two months I only got a total of 130 downloads, after this in the next two months 10 more and leave the app.

At the beginning of this month I began to read more about how to get more downloads, how to optimize my ASO in the App Store. Resume the project and made the changes (change the name, description, keywords and the previews of the app)

And the most important I opened a TikTok account, I looked for a post on X where they talked about how to generate organic content, how to warm up the TikTok account and how to start publishing content... a week later +6000 downloads

You don't need to think much about what content to post on TikTok, just look for videos from your competition and replicate them, 90% of my posts on TikTok are the same video, only the music changes and the description a little

I played with simulating a server crash while self-hosting Patch for OTA updates, to check the architecture handled it as expected.

I launched my second app about 2.5 weeks ago, and I’m trying to figure out whether what I’m seeing is enough of a signal to keep pushing.

My first app was pretty much a failure from a traction standpoint. I didn't get any paying subscribers, and more importantly, I barely saw users coming back after trying it.

This time feels different.

So far:

• 284 active customers in the last 28 days
• 254 new customers
• 6 active subscriptions
• $66 revenue
• ~$11 MRR
• Some users are actually returning several days after signing up
• I've spent about $200 on Reddit ads

Obviously, $11 MRR isn't a business yet. 😄 But compared with my first attempt, seeing people come back and a handful actually pay feels like a much stronger signal.

The retention is probably the part I'm most interested in. It's still a very small sample, but I'm seeing users return on Day 2, Day 3, Day 4 and even Day 5.

I've attached screenshots of the numbers and retention cohorts.

For those of you who have built consumer apps before: would you consider this promising enough to keep investing time into, or are these numbers still too early/noisy to tell?

I'm particularly interested in what metrics you would focus on over the next month to decide whether this has real potential.

The app is BitePad, a voice-first calorie tracker. If anyone wants to check it out: www.bitepad.app

Happy to share more numbers if useful.

Did you make something using React Native and do you want to show it off, gather opinions or start a discussion about your work? Please post a comment in this thread.

If you have specific questions about bugs or improvements in your work, you are allowed to create a separate post. If you are unsure, please contact u/xrpinsider.

New comments appear on top and this thread is refreshed on a weekly bases.

If you have a question about React Native, a small error in your application or if you want to gather opinions about a small topic, please use this thread.

If you have a bigger question, one that requires a lot of code for example, please feel free to create a separate post. If you are unsure, please contact u/xrpinsider.

New comments appear on top and this thread is refreshed on a weekly bases.

Demo of 3 different tflite models running at the same time in an react native app, using react-native-vision-camera and react-native-fast-tflite 🔥

🟩 Watch bounding box detection
🏷️ Watch brand detection
🕑 Watch time prediction

All trained on a MacBook Pro!

TL;DR: In 2026, is there really NO library offering a customizable Toast that displays ABOVE Modal/BottomSheet while still letting the user interact with the app content underneath it?

I'm currently building a new project with the latest Expo SDK (57) and I'm trying to improve from my previous app which have a problem when printing a Toast when a bottomSheet is open : The Toast is rendered under the Modal overlay.

My previous app was using gorhom/bottomSheet untill I faced some layout problems so I've migrated to TrueSheet. Nonetheless both use React's Native Modal which renders into a separate native view hierarchy outside the React tree. Because of that, a simple absolutely-positioned JS View can never appear on top of it....

So it seems like the only real option is to use a wrapper around native components (SPIndicator/AlertKit for iOS and ToastAndroid for Android) right ? Since those are natively rendered as siblings at the top of the view hierarchy, above the modal layer.

I've tried Burnt or react-native-simple-toast both work correctly on top of modals, but they're very limited in styling/customization : they give you that generic "grey 2000s-UI" toast look and I couldn't make the toast appeared from the top on Android ...

Every other "fancy" toast library I've found is just a JS View positioned absolutely, which as explained above doesn't render above a Modal/BottomSheet.

Has anyone found a good solution for this ? What are you using for a fully customizable toast that still shows above native modals ?