App crashes on startup with: [Worklets] Tried to synchronously call a non-worklet function addListener on the UI thread when upgrading to Expo sdk 55.

[miguelartazos]

Environment

• react-native-reanimated: 4.2.2
• react-native-worklets: 0.7.3
• Expo SDK: 55
• React Native: 0.83.2
• Platform: iOS (simulator)
• Architecture: New Architecture (Fabric)

Root cause (investigation)

We traced the crash to createMapperRegistry().start() in mappers.ts calling sv.addListener() on shared values that were serialized field-by-field instead of via the __init → legacy_makeMutableUI path. As a result, addListener becomes a RemoteFunction stub and throws when called on the UI thread.

Hypothesis: serializableMappingCache is split between two implementations:

• serializableMappingCache.ts — NOOP stub (set does nothing, get returns null)
• serializableMappingCache.native.ts — real WeakMap

If Metro resolves Reanimated’s mutables.ts to the NOOP cache and Worklets’ serializable.native.ts to the real cache, then:

1. makeMutableNative writes to the NOOP cache (no-op)
2. createSerializable reads from the real cache (empty)
3. Cache miss → clonePlainJSObject → addListener becomes RemoteFunction → crash

Diagnostic evidence:

• sv.addListener has isRemote: true at the crash site
• createSerializable ran before mutables.ts loaded in our tests (load order)

Workaround

Using a global singleton for the cache fixes the crash:

// serializableMappingCache.native.ts and serializableMappingCache.ts
const cache = ((globalThis as any).__workletsSerializableCache ??= new WeakMap());

[tjzel]

Hi @miguelartazos. I don't think that serializableMappingCache.ts should ever be picked in favor of serializableMappingCache.native.ts during native development - it seems like a problem with your Metro/Expo configuration.

I'm strongly against the global singleton - the point of .native.ts and .ts implementations are to prevent such anti-patterns in the codebase and ensure proper encapsulation.

[miguelartazos]

Hi Tomasz, thank you so much for your response. My Metro configuration is standard Expo SDK 55 + Sentry + Uniwind — no custom resolver modifications that would affect .native.ts resolution. The platforms config is set correctly by Expo. The issue isn't that Metro picks the wrong file systematically. It's that the library ships a NOOP .ts alongside a real .native.ts, and any Metro cache/fast-refresh edge case that loads both creates a silent cache coherency failure → crash. The NOOP's set() being a no-op and get() returning null! means there's zero fault tolerance. The global singleton via globalThis ensures both files share the same WeakMap regardless of which gets loaded. This isn't an anti-pattern — it's a defensive fix for a library design that assumes Metro will never resolve the wrong file, which isn't guaranteed. Do you have any idea of what else could be causing this error? Thank you again this issue has been annoying me for the past 2 days.

…

On Fri, Feb 27, 2026 at 12:25 PM Tomasz Żelawski ***@***.***> wrote: Hi @miguelartazos <https://github.com/miguelartazos>. I don't think that serializableMappingCache.ts should ever be picked in favor of serializableMappingCache.native.ts during native development - it seems like a problem with your Metro/Expo configuration. I'm strongly against the global singleton - the point of .native.ts and .ts implementations are to prevent such anti-patterns in the codebase and ensure proper encapsulation. — Reply to this email directly, view it on GitHub <#9023 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUCMS75QWIVNFLPKDBHWEUL4OCDZ3AVCNFSM6AAAAACWBUDF3KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJUHE4TANQ> . You are receiving this because you were mentioned.Message ID: <software-mansion/react-native-reanimated/repo-discussions/9023/comments/15949906 @github.com>

[tjzel]

any Metro cache/fast-refresh edge case that loads both
creates a silent cache coherency failure → crash.

There's no reason that Metro should pull both .native.ts and .ts implementations. It's clearly an error.

[tjzel]

Feel free to open an issue with a working reproduction, we'd be happy to investigate that.

[ntphu1808]

I'm also running into the same issue here but the op's workaround couldn't fix mine. I've been migrating my bare react native app to expo 55 and struggling with this one for a week. One thing I did notice here is these lines in metro.config.js

const { getDefaultConfig } = require("expo/metro-config"); const { mergeConfig } = require("@react-native/metro-config");

if I use getDefaultConfig from expo/metro-config, I'll get the error, while using getDefaultConfig from @react-native/metro-config won't face the issue. But doing so will compromise my intent to migrate fully to expo.

[ntphu1808]

hey, I don't know if you OP here has react-native-dotenv installed in your project, but replacing react-native-dotenv by react-native- config fixed the issue for me.

[aleksey-mukho]

I fixed this issue when removed react-native-dotenv library from my project

[lptn]

✅ UPDATE — found the trigger in our case (and a fix)

Follow-up with what resolved it for us. The culprit was a second Babel plugin in the Metro transform pipeline: babel-plugin-transform-inline-environment-variables in babel.config.js. Removing it fixes the crash — the Release build no longer SIGABRTs; the app boots and renders normally (verified on the iPhone 17 Pro simulator, dev=false).

This lines up with the reports here that switching react-native-dotenv → react-native-config fixes it. Both react-native-dotenv and transform-inline-environment-variables are Babel plugins that participate in the transform/module pipeline, whereas react-native-config is a runtime native module with no Babel footprint. The extra Babel transform appears to perturb how Metro resolves/instantiates the worklets serialization layer (serializableMappingCache), which is what yields the field-by-field shared-value clones whose addListener/removeListener become RemoteFunction stubs.

TL;DR for anyone hitting this: check babel.config.js for env-inlining Babel plugins (react-native-dotenv, transform-inline-environment-variables, …) and remove them (move env to react-native-config / expo-constants). It's not the env values — it's the extra Babel plugin in the pipeline. In our case the plugin was also vestigial (process.env.* unused in app code).

It still looks like an underlying worklets fragility (a benign-looking Babel plugin shouldn't be able to break shared-value serialization), so a proper upstream fix would be making that serialization robust to transform-pipeline ordering — but the above is a reliable workaround.

---

Original report (environment, crash stack, things ruled out)

Still reproducing on Expo SDK 55 / RN 0.83.6 — and fatal in Release

Hitting the same family on a bare Expo SDK 55 workflow: RN 0.83.6, React 19.2, react-native-reanimated@4.4.1 + react-native-worklets@0.9.1 (matched pair), Hermes. Posting a detailed breakdown in case it helps pin the root cause, because the behavior differs between dev and release:

Dev: the app boots past worklets init and reaches app render, but logs ~85× (non‑fatal LogBox):
[Worklets] Tried to synchronously call a Remote Function. Called "removeListener" on the UI Runtime.
(OP sees addListener; we see removeListener from mapper teardown — same family.)

Release / production: the same condition is fatal. The app runs ~6–15s, then SIGABRT. Symbolicated crash stack (from the .ips):

abort  ←  std::__terminate  ←  __cxa_throw
hermesvm: HermesRuntimeImpl::throwPendingError()
hermesvm: HermesRuntimeImpl::call(...)
worklets::WorkletRuntime::runSync(SerializableWorklet)
worklets::scheduleOnUI(...)
worklets::UIScheduler::triggerUI()
worklets::IOSUIScheduler::scheduleOnUI(...)
libdispatch: _dispatch_main_queue_drain

i.e. a worklet scheduled on the UI runtime throws the RemoteFunction guard and, with no LogBox in Release, it terminates the process.

Things we tried — all still crash:

• Bumping off the SDK‑55 pin (4.2.1 / 0.7.4) to the latest stable matched pair 4.4.1 / 0.9.1 — clears the startup addListener crash, but the above remains.
• The nightly react-native-reanimated@4.5.0-nightly + react-native-worklets@0.10.0-nightly — crashes differently (an Obj‑C exception rethrown through ObjCTurboModule::performVoidMethodInvocation), also fatal.
• Patching serializableMappingCache to a globalThis‑backed singleton (the cache‑split fix discussed here) — identical crash. In our bundle only the real serializableMappingCache.native variant is present (the NOOP .ts variant is absent), so the NOOP/real module split does not apply in our case.
• --reset-cache, clearing watchman.
• We already use react-native-config (not react-native-dotenv).

Not an app‑usage issue: no module‑scope shared values, idiomatic useSharedValue/useAnimatedStyle/Gesture API, react-native-worklets/plugin auto‑added by babel-preset-expo (single, not double). Stubbing individual animated components (custom drawer, splash overlay) does not help — the UI scheduler aborts while running the mapper system regardless of which component renders, so it's systemic, not component‑specific.

The signature matches the OP's diagnosis (shared values reaching the UI runtime serialized field‑by‑field, so their listener methods become RemoteFunction stubs), but it is fatal in Release rather than just a dev warning. Happy to share the full .ips or put together a minimal repro if that helps.

[tjzel]

Fixed in #9703