Troubleshooting
Initialization issues
Reanimated has four core components that compose its code:
- C++,
- Java,
- JavaScript,
- Reanimated Babel plugin.
All of them are supposed to work correctly only within the same minor version. Therefore, having any of those pieces in your code - directly or indirectly - separate from react-native-reanimated
, especially having any code transpiled with a different version of the aforementioned plugin will result in undefined behavior and errors.
Failed to create a worklet
Problem: This usually happens when Reanimated is not properly installed, e.g. forgetting to include the Reanimated Babel plugin in babel.config.js
.
Solution: See installation docs at https://docs.swmansion.com/react-native-reanimated/docs/fundamentals/getting-started/#step-2-add-reanimateds-babel-plugin for more information.
Native part of Reanimated doesn't seem to be initialized
Problem: This issue happens when Reanimated fails to initialize its native side from JavaScript.
Solution:
- If you recently installed or upgraded Reanimated, make sure to rebuild your app.
- Check if your platform is supported by Reanimated. Currently we support:
- Android
- iOS
- macOS
- Web
- If you are using Reanimated in a brownfield app, make sure to initialize the native library manually.
Unknown version of Reanimated Babel plugin
Problem: This happens when JavaScript side of Reanimated fails to get Reanimated Babel plugin version.
Solution:
- Part of your code might be transpiled with an outdated version of Reanimated Babel plugin. See Mismatch between JavaScript code version and Reanimated Babel plugin version.
- You use release bundle with debug build of the app. This is not supported. See Using dev bundle in release app build is not supported for more information.
Mismatch between JavaScript code version and Reanimated Babel plugin version
Problem: This can happen when you use code that was transpiled with an outdated version of Reanimated Babel plugin.
Solution: Try resetting your Metro bundler cache with yarn start --reset-cache
, npm start -- --reset-cache
or expo start -c
and run the app again.
If this didn't help, you probably have a dependency that contains already transformed worklets bundled with an outdated version of the Reanimated Babel plugin. You can find the offending code that was given alongside the error to find that dependency.
Using dev bundle in a release app build is not supported
Problem: This happens when you use a release build of your app with a development JavaScript bundle.
Solution: See this post for more information.
Couldn't determine the version of the native part of Reanimated
Problem: This happens when Reanimated fails to determine the version of its native part.
Solution: Check if you have rebuilt your app after upgrading react-native-reanimated
. If you use Expo Go, you must use the exact version which is bundled into Expo SDK.
Mismatch between JavaScript part and native part of Reanimated
Problem: This happens when Reanimated has different versions of its JavaScript and native parts.
Solution: Check if you have rebuilt your app after upgrading react-native-reanimated
. If you use Expo Go, you must use the exact version which is bundled into Expo SDK.
C++ side failed to resolve JavaScript code version
See Couldn't determine the version of the native part of Reanimated and Unknown version of Reanimated Babel plugin.
Mismatch between C++ code version and JavaScript code version
See (Mismatch between JavaScript part and native part of Reanimated)[#mismatch-between-javascript-part-and-native-part-of-reanimated] and (Mismatch between JavaScript code version and Reanimated Babel plugin version)[#mismatch-between-javascript-code-version-and-reanimated-babel-plugin-version].
C++ side failed to resolve Java code version
Problem: This happens when Reanimated fails to determine the version of its Java part - most likely because Java part hasn't rebuilt after an upgrade.
Solution: Make sure to rebuild your app and see if the problem persists. If it does, feel free to create an issue on our GitHub.
Mismatch between C++ code version and Java code version
Problem: This happens when Reanimated has different versions of its C++ and Java parts.
Solution: See Native side failed to resolve Java code version.
Java side failed to resolve C++ code version
Problem: This happens when Reanimated fails to determine the version of its C++ part - most likely because for some reason C++ part hasn't rebuilt after an upgrade.
Solution: See Native side failed to resolve Java code version.
Mismatch between Java code version and C++ code version
Problem: This happens when Reanimated has different versions of its Java and C++ parts.
Solution: See Native side failed to resolve Java code version.
Multiple versions of Reanimated were detected
Problem: This error usually happens when in your project exists more than one instance of Reanimated. It can occur when some of your dependency has installed Reanimated inside their own node_modules
instead of using it as a peer dependency. In this case two different versions of Reanimated JavaScript module might try to initialize its native part. You can check which libraries are using Reanimated e.g. with yarn why react-native-reanimated
or npm ls react-native-reanimated
.
Solution: Modify your package.json
file accordingly:
- if you use
yarn
, you should addresolution
property:
"resolutions": {
"react-native-reanimated": <Reanimated version>
}
- if you use
npm
, you should addoverrides
property:
"overrides": {
"react-native-reanimated": <Reanimated version>
}
After that make sure to run your package manager again, either yarn
or npm install
.
Another instance of Reanimated was detected
See Multiple versions of Reanimated were detected.
Outdated version of React Native for New Architecture
Problem: Reanimated supports New Architecture (Fabric) only on the latest minor release of React Native.
Solution: Please upgrade to a newer version of React Native or downgrade to an older version of Reanimated. See the compatibility table for a full list of supported versions of React Native.
Warnings
Reduced motion setting is enabled on this device.
Problem: This warning is displayed to avoid confusion that could arise when Reduced motion is enabled.
Solution: Do nothing, this warning is safe to ignore as it is only displayed in development mode to avoid confusion. If you wish to disable it, you can add the following line to your project's root file:
LogBox.ignoreLogs([
'[Reanimated] Reduced motion setting is enabled on this device.',
]);
See the accessibility overview to learn more about Reduced Motion.
Tried to modify key of an object which has been converted to a shareable.
Problem: This warning is displayed to inform the user that a shared value should be used or an object used in a worklet should be accessed more granularly.
1. Not using shared values.
You might get this warning when you do something along the lines of:
const obj = { prop: 1 };
function worklet() {
'worklet';
console.log(obj.prop);
}
runOnUI(worklet)();
obj.prop = 2; // Warning: Tried to modify key `prop` of an object which has been already passed to a worklet.
runOnUI(worklet)();
and expect the results to be 1
and 2
. However, the results will be 1
and 1
because obj
is not a shared value and is only copied to UI runtime once. Therefore, in development builds, we make the object immutable and add this warning after copying it to signal that it's not a valid use of Reanimated. To fix this, you should use a shared value instead:
Solution:
-const obj = { prop: 1 };
+const sv = useSharedValue({ prop: 1 });
function worklet() {
'worklet';
- console.log(obj.prop);
+ console.log(sv.value.prop);
}
runOnUI(worklet)();
-obj.prop = 2; // Warning: Tried to modify key `prop` of an object which has been already passed to a worklet.
+sv.value = { prop: 2 }; // Everything is fine here.
+// Keep in mind that you cannot modify the property directly with `sv.value.prop = 2` unless you use the `modify` method.
runOnUI(worklet)();
2. Not accessing object properties granularly.
When you access an object property in a worklet, you might do something like this:
const obj = { propAccessedInWorklet: 1, propNotAccessedInWorklet: 2 };
function worklet() {
'worklet';
console.log(obj.propAccessedInWorklet);
}
runOnUI(worklet)();
obj.propNotAccessedInWorklet = 3; // Warning: Tried to modify key `prop` of an object which has been already passed to a worklet.
The warning is displayed due to the mechanism explained in the previous case. Since we copy the whole object obj
instead its accessed properties, it's immutable.
Solution:
Assign accessed properties to variables beforehand and use those in the worklet:
const obj = { propAccessedInWorklet: 1, propNotAccessedInWorklet: 2 };
+const propAccessedInWorklet = obj.propAccessedInWorklet;
+
function worklet() {
'worklet';
- console.log(obj.propAccessedInWorklet);
+ console.log(propAccessedInWorklet);
}
runOnUI(worklet)();
-obj.propNotAccessedInWorklet = 3; // Warning: Tried to modify key `prop` of an object which has been already passed to a worklet.
+obj.propNotAccessedInWorklet = 3; // Everything is fine here.
Threading issues
Tried to synchronously call a non-worklet function on the UI thread
Problem: This can happen when you try to call a function that is not marked as a worklet from a worklet. E.g.:
function callee() {
console.log('hello');
}
function caller() {
'worklet';
callee(); // <- this will throw in `runOnUI`
}
runOnUI(caller)();
In this example, callee
cannot be called from a worklet ran on UI thread because there is no corresponding UI function for callee
.
Solution:
- If you want to synchronously execute this method, mark it as a worklet using
worklet
directive:
function callee() {
+ 'worklet';
console.log("hello");
}
- If you want to execute this function on the JS thread, wrap it using
runOnJS
:
function caller() {
'worklet';
- callee();
+ runOnJS(callee)();
}
Check this page to learn more about Reanimated and its worklets.