However, if using something like native navigation, where view controllers and their life cycle get handled by iOS then it will correctly end an animation.
I have no idea if this is true for Android. But I have witnessed it on iOS and fixed this issue in react-native apps on quite a few occasions.
The ultimate downside to frameworks like this is they imo, don’t know enough about the content they’re showing to make great choices for users. But at the same time, it’s not fully desirable to attempt to assume. That’s the platforms job. And that’s an obvious catch-22. How should you know this if you aren’t a native app builder?
It greatly augments your ability to write elegant solutions to hard problems.
Some argue this is a large cost to bear - however I'd say it's one that is very reasonable to acquire. Having experience and knowledge in several languages/frameworks helps make one stronger engineer.
My impression has been that to use RN well you need to mostly think like and have the knowledge of someone who is a native app developer. You just get some benefit of sharing UI across platforms, but still need to do many things you would for native.
I haven't used RN, just saw my friend who uses give a talk on it. So I certainly may not understand exactly how much native code you can or can't write while also using RN.
The non-obvious one is why is the framework consuming any CPU time at all on something not visible? When an element tries to animate, and the whole element is covered/offscreen, the framework should simply pause the animation. When the element becomes visible again, it's simple to calculate how long the element has been invisible, and fast-forward the animation to that frame.