So, I spent some time debugging and gathering more information and I realized that after the app becomes active we are calling a JS function stored as a JSValue in our native side. I guessed the JSValue may had been deallocating and thus the crash. So, I reviewed the documentation and decided to use and store a JSManagedValue instead. It seems that the crash is not happening anymore, but the JSManagedValue::value is deallocated even more often than before, making value to be nil and forcing us to skip the call. I'm not trying to understand why the JSValue is not retained properly: We are calling addManagedReference:withOwner: to retain the object manually. As owner, we are providing a native object that has visibility in the JS environment and it's in fact stored in window.something after it's created. At no point we call removeManagedReference:withOwner: to release the object It's always happening after the app becomes active again, so I guess something gets deallocated while the app is the background. What am I missing that makes the JSValue function to get released?

Thanks for the above answer. I think my options here are very little then. My business relies a lot on Crashlytics, we can track bugs very easily and the alert system is a must for us. Unfortunately, I can't just disable it :(. This is also happening randomly to any user, so I can't even disable it on a reduced audience. Something we could do is to disable Crashlytics for a few seconds when app moves back to the foreground (when the crash is occurring), but I don't know if that disables Crashlytics completely to prevent Apple crash reports to get disrupted. Maybe my next question would be: Is really Crashlytics the problem here or actually the fact that we have two tools bothering each other?