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