> since Apple does not allow JITted code apparently (not sure how React Native gets around this then)
With React Native you have two options. Use Apple's own JavaScriptCore engine which has special JIT permissions, or use Meta's Hermes engine which runs as a bytecode interpreter.
In either case you can always drop down to native code (Swift/Objective-C (iOS), Kotlin/Java (android), or C/C++ (any platform)) which can be used for anything compute heavy.
No, the ability to JIT is not per framework (I'm unsure how that would work?), it's per process. Using JSC doesn't give you a JIT - now the JSC interpreter is very fast, so it's possible claims that they "need JIT" are incorrect (back when I worked on JSC it was a common belief from people that the JITs were magic fairy dust, and so would come in to anything with a data-less assumption that a JIT was needed), it's also possible that "react native" is using wkwebview in which case the content would be running in a separate web content process with a jit.
I don't think React Native is using WkWebView. But that the introduction of WkWebView which allows JIT was the source of my confusion. I was under the impression that JIT was enabled for any uses of JSC in iOS at that time. But it seems that is not the case.
So the situation with React Native is that you can either use JSC, Hermes (or I believe V8 in jitless mode). All of which are interpreters. On Android you can of course use JIT (with either JSC or V8).
With React Native you have two options. Use Apple's own JavaScriptCore engine which has special JIT permissions, or use Meta's Hermes engine which runs as a bytecode interpreter.
In either case you can always drop down to native code (Swift/Objective-C (iOS), Kotlin/Java (android), or C/C++ (any platform)) which can be used for anything compute heavy.